napisał: Kalumet
postów: 36
 umieszczony:
2 października 2007
21:49
|
|
Nie ma sprawy, naprawdę. Nic się nie stało. Jestem Ci wdzięczny za ciekawy udział w dyskusji i... za ten ostatni post. A że czasem ludzie się trochę miną, nie do końca zrozumieją, to normalne, zdarza się.
Pozdrawiam
Piotr Marcin |
|
|
napisał: LAnd
postów: 107
umieszczony:
2 października 2007
21:18
|
|
Nie miałem skąd dowiedzieć się dokładniej ani czegokolwiek o twojej wiedzy informatycznej. To nie była szpila tylko jak zauważyłes bardzo uproszczony i niekoniecznie dokładny skrót pewnej idei. Nie chciałem Cię urazić
Andrzej |
|
|
napisał: Kalumet
postów: 36
umieszczony:
2 października 2007
20:54
|
|
L.And.!
"Gdyby temat zdarzeń, których reprezentantami są Exit, Enter, przy użyciu których Ty się kurczowo upierasz, czy użytym przeze mnie jako przykład BeforeUpdate (równie dobry reprezentant jak użycie jakiegokolwiek innego zdarzenia
powodującego omawiany problem wielokrotnego niezrozumiałego generowania już wywołanego zdarzenia) był prosto
rozwiazywalny informatycy powszechnie używaliby tych zdarzeń do sprawdzania poprawności danych.
A jednak tego nie robią ?"
Tak, wiem już od jakiegoś czasu, że uważasz mój pomysł za kiepski, niepraktyczny, trudny do wykonania i generalnie przez nikogo nie stosowany  . Pewnie masz rację. Ale warto było (i jest) "kurczowo się upierać", choćby i dla tej fajnej i momentami bardzo pouczającej (przynajmniej dla mnie) dyskusji, która się tutaj wywiązała, i która chyba w końcu doprowadziła do sukcesu (przynajmniej w kwestii zastosowań praktycznych). Przepraszam, że tak opędzam się od zdarzenia BeforeUpdate. Nie wiedziałem, że przywołujesz je jako przykład analogiczny, a nie jako propozycję rozwiązania problemu.
"w sprawie Tab Shift+Tab, TabStop i Enabled nie zrozumiałeś intencji informacji"
Rzeczywiście, w sprawie Tab i TabStop nie zrozumiałem Twoich intencji. Napisałeś dość skrótowo i odczytałem to dokładnie tak jak napisano, stąd mój błąd. No cóż, nie reprezentuję najwyraźniej Twojego poziomu znajomości tematu i to też jest przyczyna. Natomiast w sprawie Enabled: początkowo to odrzuciłem, ale wróciłem do pomysłu i dopiero kod nadesłany przez jotaad przerwał moje eksperymenty.
Rozważania o możliwych przyczynach problemu z SetFocus oraz symulacja Udaje_Exit() - bardzo ciekawe, choć momentami poza moim poziomem znajomości zagadnień programowania.
Natomiast "krótki wykład o procesach"... No cóż, wyobraź sobie, że wiem co to są procesy, gdzie ich szukać, itd. Trochę to wyglądało jak taka szpila w... dla nieposłusznego lamera. Ale niech i tak będzie. Może mi się należało?
Pozdrawiam
Piotr Marcin |
|
|
napisał: Kalumet
postów: 36
umieszczony:
2 października 2007
20:33
|
|
jottad!
Witaj, dzięki za zainteresowanie i pomysł.
"Stany nieustalone". Też niezłe określenie. Coś jak "kaskada zdarzeń". Ale do rzeczy. Otóż zaproponowany przez Ciebie kod zastosowany w moim konkretnym przypadku daje rezultaty, jak dotąd, najbliższe oczekiwaniom! I nawet jeśli jest to iluzja, nie oglądam "stosu wywołań po kilku alertach z procedur zdarzeniowych", żeby to zdemaskować Zdublowane MsgBox-y nie występują przy żadnej z trzech metod przechodzenia między formantami: ani przy kliku myszą, ani przy Tab-ie, ani przy Enter-ze. Właśnie tak to miało być. Przy tym kod jest dość prosty. Niezły pomysł! Owszem, jest tam jeszcze coś do poprawienia, a mianowicie kursor powinien lądować spowrotem w kontrolce, która została zweryfikowana negatywnie. Ale to - mam nadzieję - powinna być już tylko kosmetyka. Czyli w sensie praktycznym mój cel został prawie osiągnięty. Pozostają do rozważania dziwne przypadłości niektórych zdarzeń, jak w Twoim drugim poście. Nawiasem mówiąc, też bardzo ciekawym.
Dzięki! Pozdrawiam
Piotr Marcin |
|
|
napisał: Kalumet
postów: 36
umieszczony:
2 października 2007
20:20
|
|
r_c!
"Kontrolki (nie wszystkie) mogą zachodzić na siebie. Wykorzystując tę możliwość można ukryć dodatkową kontrolkę, której jedynym zadaniem bedzie przechwycenie nadmiarowego zdarzenia Enter()."
No cóż, osobliwe rozwiązanie. Ale jakoś mało prawdopodobne wydaje mi się, żeby taka przyczajona kontrolka była w stanie zapobiec "kaskadzie". Spróbowałem nawet coś takiego sklecić, ale miałem bardzo mało czasu na eksperymenty, więc nie wykluczone, że jakby się lepiej przyłożyć, to efekty byłby lepszy.
Pozdrawiam
Piotr Marcin |
|
|
napisał: Kalumet
postów: 36
umieszczony:
2 października 2007
20:15
|
|
Trebor!
A jednak! Nie poddałeś się. Fajnie. Co do rozwiązania, no cóż, dość... oryginalne. I rzeczywiście, raczej takie cokolwiek siłowe. Zaraz je sprawdzę "w praniu". I niepotrzebnie tak się sam skrytykowałeś . W końcu jest to (chyba) jakieś rozwiązanie i w dodatku inne niż pozostałe.
Pozdrawiam
Piotr Marcin |
|
|
napisał: jottad
postów: 118
umieszczony:
2 października 2007
15:01
|
|
Land, wydaje mi się, że jest to jakiś bug, bo focus jest przenoszony właściwie, natomiast procedura zdarzenia Enter jest wykonywana dla niewłaściwej kontrolki. Podejrzewam, że jakieś zmienne wewnętrzne nie są ustawiane właściwie i stąd problemy. Zauważ, że np. taki kod:
Private Sub cmbKategoriaNowegoTowaru_Enter()
If Me.txtNazwaNowegoTowaru.Value = "" Then
MsgBox "formant pusty"
ChangeFocusTo Me.txtNazwaNowegoTowaru
End If
End Sub
Private Sub cmbGrupaNowegoTowaru_Enter()
If Me.txtNazwaNowegoTowaru.Value = "" Then
MsgBox "formant pusty"
ChangeFocusTo Me.txtNazwaNowegoTowaru
Exit Sub
End If
If Me.cmbKategoriaNowegoTowaru.Value = "" Then
MsgBox "formant pusty"
ChangeFocusTo Me.cmbKategoriaNowegoTowaru
End If
End Sub
Private Sub ChangeFocusTo(ctrl As Object)
ctrl.SetFocus
Me.Hide: Me.Show
End Sub
teoretycznie będzie działał poprawnie, ustawiając fokus we właściwych kontrolkach i o jego błędnym działaniu można sie przekonać po obejrzeniu stosu wywołań po kilku alertach z procedur zdarzeniowych. |
|
|
napisał: LAnd
postów: 107
umieszczony:
2 października 2007
13:23
 edytowany:
2 października 2007
13:38
|
|
wiedza z
R. Wacławek: Windows od kuchni. Poradnik programisty, HELP, Warszawa 1993
Trubo Pascal
po zatrzymaniu programu na If JestemZajęta Then Exit Sub przy ponownym wejściu do Udaję_Exit sprawdzić
View -> Call Stack z memu edytora VBA |
|
|
napisał: LAnd
postów: 107
umieszczony:
2 października 2007
12:07
edytowany:
2 października 2007
12:33
|
|
Gdyby temat zdarzeń, których reprezentantami są Exit, Enter , przy użyciu których Ty się kurczowo upierasz, czy użytym przeze mnie jako przykład BeforeUpdate ( równie dobry reprezentant jak użycie jakiegokolwiek innego zdarzenia
powodującego omawiany problem wielokrotnego niezrozumiałego generowania już wywołanego zdarzenia ) był prosto
rozwiazywalny informatycy powszechnie używaliby tych zdarzeń do sprawdzania poprawności danych.
A jednak tego nie robią ?
Do objaśnienia problemu jest niezbędna niezła wiedza o sposobie komunikowania się systemu Windows z uruchomionymi
procesami (jakie procesy ? zobacz -> Ctrl-Alt-Del, wybrać -> Menedżer zadań , zakładka -> Procesy )
W bardzo wielkim uproszczeniu :
pod nadzorem systemu Windows, system do procesów i\lub procesy do systemu wysyłają Komunikaty (message komunikaty zawierają
- informację ( np. wprowadzono znak - proces obsługi klawiatury, opuszczenie okienka ,słynne Exit, ale tego
nie jestem pewien, może system interpretując mysz lub klawiaturę każe okienku uruchomić takie zdarzenie ? )
- żądanie wykonania jakiejś usługi ( odczyt z dysku , podania danych o innym procesie )
- polecenie np. system do procesu : zamknięcia okienka , uruchomienie, wstrzymanie, zakończenie procesu
itp itd
komunikaty są wstawiane przeważnie na koniec kolejki i najczęściej są po kolei przetwarzane przez system ( wyjątek :
proces modalny ).
Większość elementów każdego języka jest mniej lub bardziej szczegółową ( opuszczenie niektórych właściwości )
implementacją funkcji, procedur, obiektów Windows API ( Application Programming Interface ), VBA jest wersją
wyspecjalizowaną (obsługa Office ) i ubogą ( wystarczy porównać z VB )
Obecnie w API jest ok. 5-6 tysięcy obiektów, funkcji i procedur a stałych i struktur powyżej 55000
w sprawie Tab Shift+Tab, TabStop i Enabled nie zrozumiałeś intencji informacji
napisałeś Klawisz Tab ma właśnie przenosić fokus na następną kontrolkę
ale pod warunkiem, że kontrolka docelowa może być poddana edycji !!!!!!!!!!!!!
z mojej propozycji wynika, że sterując odpowiednio właściwosci TabSop i\lub Enabled, możesz sterować dostępem do
edycji danych w kontrolkach ( nie domyślam się jak zinterpretowałeś moją propozycję ) blokując w kodzie dostęp do kontrolek które nie mogą być edytowane lub zezwalając na dostęp
Wyeliminuje to użycie SetFocus.
Chyba to polecenie sprawia kłopot
Sytuacja jest taka :
System nie otrzymał od opuszczanego okienka informacji o zakończnieu procesu EXIT
Polecenie SetFocus wstrzymuje zakończenie obsługi zdarzenia Exit i przesłanie informacji do systemu przez aktywne ,
z punktu widzenia systemu, okienko.
Więc polecenie SetFocus jest wysłane z okienka, które wg systemu POSIADA FOCUS, co generuje informację dla systemu, że to okienko z nie zakończoną procedurą EXIT ( AKTYWNE ) nie jest opuszczone i rekurencyjne wywołanie procedury EXIT
a to symulacja wyżej opisanej sytuacji i demonstracja zastosowania zmiennej statycznej Static -> uruchomić krokowo
Udaję_Exit
Sub Udaję_Exit()
Static JestemZajęta As Boolean
If JestemZajęta Then Exit Sub
JestemZajęta = True
If ZmieńFokus Then
Udaję_Exit ' to wywołanie funkcji zakończy się na If JestemZajęta Then Exit Sub
End If
JestemZajęta = False
End Sub
Function ZmieńFokus() As Boolean
ZmieńFokus = True
End Function |
|
|
napisał: jottad
postów: 118
umieszczony:
2 października 2007
11:15
|
|
Proponuję obejść "stany nieustalone" kontrolek.
W module formularza:
Private Sub cmbKategoriaNowegoTowaru_Enter()
If Me.txtNazwaNowegoTowaru.Value = "" Then
MsgBox "formant pusty"
Application.OnTime Now, "NazwaSetFocus"
End If
End Sub
Private Sub cmbGrupaNowegoTowaru_Enter()
If Me.txtNazwaNowegoTowaru.Value = "" Then
MsgBox "formant pusty"
Application.OnTime Now, "NazwaSetFocus"
Exit Sub
End If
If Me.cmbKategoriaNowegoTowaru.Value = "" Then
MsgBox "formant pusty"
Application.OnTime Now, "KategoriaSetFocus"
Exit Sub
End If
End Sub
W module standardowym:
Sub NazwaSetFocus()
UserForm1.txtNazwaNowegoTowaru.SetFocus
End Sub
Sub KategoriaSetFocus()
UserForm1.cmbKategoriaNowegoTowaru.SetFocus
End Sub
Powinno działać. |
|
|
napisał: r_c
postów: 38
umieszczony:
2 października 2007
11:05
|
|
| Cytat:
Propozycji zmiany kolejności tabulacji zupełnie nie rozumiem ...
Kontrolki (nie wszystkie) mogą zachodzić na siebie. Wykorzystując tę możliwość można ukryć dodatkową kontrolkę, której jedynym zadaniem bedzie przechwycenie nadmiarowego zdarzenia Enter(). Przyznam, że tego rozwiązania nie testowałem. Wieczorem się pobawię.
pozdrawiam r_c |
|
|
napisał: Trebor
postów: 1209
umieszczony:
2 października 2007
08:47
|
|
Jeśli już mowa o rozwiązaniach siłowych to można coś takiego
Dim znak As Date
Private Sub txtNazwaNowegoTowaru_Enter()
If Now - znak < TimeValue("0:0:01") Then cmbKategoriaNowegoTowaru.SetFocus
If znak = 0 Then znak = Now
End Sub
Private Sub cmbKategoriaNowegoTowaru_Enter()
If Me.txtNazwaNowegoTowaru.Value = "" Then
If Now - znak > TimeValue("0:0:1") Then MsgBox "formant txtNazwaNowegoTowaru": znak = Now
Me.txtNazwaNowegoTowaru.SetFocus
End If
End Sub
Private Sub cmbGrupaNowegoTowaru_Enter()
If Me.txtNazwaNowegoTowaru.Value = "" Then
If Now - znak > TimeValue("0:0:1") Then MsgBox "formant pusty Txt": znak = Now
Me.txtNazwaNowegoTowaru.SetFocus
Exit Sub
End If
If Me.cmbKategoriaNowegoTowaru.Value = "" Then
If Now - znak > TimeValue("0:0:1") Then MsgBox "formant pusty Kategoria": znak = Now
Me.cmbKategoriaNowegoTowaru.SetFocus
Exit Sub
End If
End Sub
Aby szybki użytkownik się nie irytował należałoby skrócić sprawdzany czas poniżej sekundy.
Rozwiązanie raczej kiepskie. |
|
|
napisał: Kalumet
postów: 36
umieszczony:
2 października 2007
00:44
|
|
Ależ dyskusja się rozwinęła! W najśmielszych oczekiwaniach nie spodziewałem się takiej.
No cóż, nie miałem możliwości odniesienia się do kilku ostatnich postów - znowu byłem daleko. Pozwólcie, że teraz, jako sprawca całego zamieszania i choć zapewne bardzo daleko mi do prezentowanego przez Was poziomu znajomości VBA, krótko odniosę się do Waszych postów. Zrobię to po kolei, począwszy od pierwszego, który opublikował r_c, po moim ostatnim poście.
r_c - Określenie "kaskada zdarzeń" jest doskonałe! Wyśmienicie pod względem rzeczowym i bardzo efektownie określa problem, o którym mowa. Szkoda tylko, że określa - wydaje się - nierozwiązywalny problem, słabość VBA, zamiast jakiegoś efektownego "tipa" albo "triku". Co do meritum, nie wiem, wątpię, że to właśnie SetFocus jest odpowiedzialny za "kaskadę", ale być może. Co do proponowanego fragmentu kodu, eleganckie, podręcznikowe "flagowanie". Piszę tak bez złośliwości, bo w moim wykonaniu wyglądało to znacznie bardziej kulawo. I wszystko byłoby pięknie, gdyby nie to, że "flagowanie" w tym przypadku ma sens tylko wtedy, kiedy uda nam się przy powrocie do pierwszego (lub ostatniego weryfikowanego formantu) tą "flagę" wyzerować, innymi słowy ustawić na wartości wyjściowej. Niestety, wykorzystywana do przeniesienia fokusu metoda SetFocus działa tak ułomnie, że nie wywołuje procedury zdarzenia Enter dla formantu, do którego fokus przenosi. Wykonałem niezliczone próby i jestem tego prawie pewien. Co do propozycji zabawy z procedurą Initialize formularza. No cóż, być może jest to rzeczywiście jedyny sposób na wyzerowanie "flagi" wobec słabości metody SetFocus? Tylko, że to jest rozwiązanie jakieś takie mało finezyjne, bardziej na zasadzie "brutalnej siły" Propozycji zmiany kolejności tabulacji zupełnie nie rozumiem. Jaki miałoby to mieć wpływ na "kaskadę". Poza tym przyjmując, że użytkownik końcowy będzie operował raczej "z klawiatury", czyli Tab lub Enter, zmiana TabOrder zupełnie to sparaliżuje.
L.And. - Klawisz Tab ma właśnie przenosić fokus na następną kontrolkę. Podany przez Ciebie link do podobnego przypadku jest bardzo ciekawy, ale... Kurczowo trzymasz się procedury zdarzenia BeforeUpdate, a to w tym przypadku zdarzenie całkiem nieprzydatne. Bowiem nie zachodzi wcale dla kontrolki, w której nic nie wprowadzono. Ale nawet gdyby było inaczej, zdarzenie to działało by w tym przypadku analogicznie jak zdarzenie Exit. A to dla mnie nie do przyjęcia, zważywszy choćby na przycisk natychmiastowego zamknięcia formularza (na zasadzie "krzyżyka") i niepotrzebne w momencie jego naciśnięcia komunikaty ostrzegawcze. Bo Exit-y wkonają się raczej przed Click-iem przycisku, prawda? Trochę nie rozumiem uwag o modalności okan MsgBox. Czy ono w ogóle może nie być modalne? Rozważania o komunikatach obsługi klawiatury generowanych przez Windows nie trafiających do właściwych okienek (zmienia się aktywne Okno w Windows), to już raczej nie mój poziom wiedzy, więc się nie wypowiadam.
r_c - "Wydaje sie, że połączenie SetFocus z pustym formantem powoduje wywołanie zdarzenia ENTER() dla wszystkich formatek." No właśnie. Dlaczego? To chyba pozostanie tajemnicą twórców. Zaczynam nabierać przekonania, że SetFocus to kompletnie nieprzydatna metoda, w zasadzie niemożliwa do jakiegoś logicznego zastosowania zgodnie z zamiarem jej powstania i nazwy.
L.And. - Jeśli chodzi o ten temat z forum Ozgrid, no cóż, bardzo obszerny, zawile omawiany i doskonale rozumiem człowieka, bo widzę, że cierpiał dokładnie z takim samym problemem jak ja. Niestety, w końcu został "porzucony" przez innych z nierozwiązanym do końca problemem. A fragment kodu, to znowu przykład "flagowania", w zasadzie taki sam jak zaproponowany przez r_c, tylko trochę mniej przejrzysty.
Reasumując: winną wszystkiego zła jest ta nieszczęsna metoda SetFocus, która w najważniejszych momentach nie działa tak jak powinna i nie generuje pozostałych, wydawałoby się logicznych w następstwie zdarzeń.
Wydaje się, że doszliśmy do ściany. Chyba, że Trebor po długim zastanowieniu i licznych eksperymentach zaproponuje coś zaskakującego, o czym do tej pory nie pomyśleliśmy. Jeśli oczywiście jest wciąż tym jeszcze zainteresowany
Tak czy owak, dziękuję wszystkim za zainteresowanie i pomoc
Pozdrawiam
Piotr Marcin |
|
|
napisał: LAnd
postów: 107
umieszczony:
1 października 2007
14:30
|
|
Cytat:
i jeszcze
http://www.ozgrid.com/forum/showthread.php?t=45988
oraz proponowane tam rozwiązanie
Private Sub SBMonthDay_Exit(ByVal Cancel As MSForms.ReturnBoolean)
Static blnExiting As Boolean ' < to zapobiega kolejnym wywołaniom , po ustawieniu na True
If blnExiting Then Exit Sub
Debug.Print "SBMonthDay_Exit Begin"
If ISLIKE(tbMonthDay.text, "####") _
And ISLIKE(tbYear.text, "####") Then
blnExiting = True
tbTime.SetFocus
Else
blnExiting = True
tbYear.SetFocus
End If
blnExiting = False
Debug.Print "SBMonthDay_Exit End"
End Sub |
|
|
napisał: r_c
postów: 38
umieszczony:
1 października 2007
14:23
|
|
LAnd.
Zamiast Msgbox'a Debug.Print. Wydaje sie, że połączenia SetFocus z pustym formantem powoduje wywołanie zdarzenia ENTER() dla wszystkich formatek.
r_c |
|
|
napisał: LAnd
postów: 107
umieszczony:
1 października 2007
14:09
|
|
| Cytat: |
|
|
napisał: LAnd
postów: 107
umieszczony:
1 października 2007
13:53
|
|
aby klawisz Tab (Shift+Tab) nie przenosił Focus'a na kontrolkę należy jej właściwość :
TabStop Property - ustawić na False
lub
Enable - ustawić na False
podaję link do podobnego problemu
BeforeUpdate Event triggers twice
http://microsoft-personal-applications.hostweb.com/TopicMessages/microsoft.public.excel.programming/955689/1/Default.aspx
zauważyłem, że w obu przypadkach podwójne wystąpienie ma miejsce po uruchomieniu modalnego okna MsgBox
być może Komunikaty obsługi klawiatury generowane przez Windows nie trafiają do właściwych okienek ( zmienia się aktywne Okno w Windows ) |
|
|
napisał: r_c
postów: 38
umieszczony:
1 października 2007
13:46
|
|
...SetFocus czyli przeniesienie ogniska zaznaczenia formantu jest odpowiedzialny za dwukrotne wywołanie komunikatu dla formatek ze zdarzeniem Enter(): nazwałem to "szumnie" kaskadą zdarzeń.
Jeżeli koniecznie musi być Enter() to propuję :
Private Sub cmbKategoriaNowegoTowaru_Enter()
If Me.txtNazwaNowegoTowaru.Value = "" Then
MsgBox "formant pusty"
cmbGrupaNowegoTowaru.TabStop = False
Me.txtNazwaNowegoTowaru.SetFocus
Else
cmbGrupaNowegoTowaru.TabStop = True
End If
End Sub
Private Sub cmbGrupaNowegoTowaru_Enter()
cmbGrupaNowegoTowaru.TabStop = True
' .... itd
End Sub
i podobnie dla pozostałych formantów.
Pobaw się trochę, pamiętaj, że UserForm posiada zdarzenie Initialize, zmień kolejność tabulacji (Tab Order) 
r_c |
|
|
napisał: Kalumet
postów: 36
umieszczony:
1 października 2007
00:37
|
|
Witaj r_c!
Dziękuję za zainteresowanie.
Pomysł ze zdarzeniem Exit pojawił się w moim projekcie zanim jeszcze rozpocząłem ten wątek tutaj. Pytałem o to na grupach, ale ponieważ nie spotkałem się z zainteresowaniem, dałem spokój.
Jeśli zaś chodzi o samą procedurę zdarzenia Exit, chętnie bym ją wykorzystał, bo wydaje sie logiczniejsza, jeśli chodzi o weryfikację danego formantu (w końcu wiąże się z nim, nie z następnym), ale jest pewnien problem. Nie wspominałem o tym do tej pory, ale oprócz trzech formantów, które są w załączniku, są jeszcze przyciski (zamykające formularz, dodające rekord do bazy). Ich istnienie i działanie koliduje z procedurami Exit. Najlepszym przykładem jest przycisk Zakończ, który (w założeniu) powinien działać analogicznie jak "krzyżyk" formularza, czyli bezwarunkowo zamykać go, bez MsgBox-ów, nawet jeśli byłyby one uzasadnione. Wszystkie procedury Exit będą z nim kolidować. Chyba, że powrócimy do koncepcji "flag" True/False. Czyli do punktu wyjścia Bo ciągle nie wiem, jak skutecznie zmieniać stan flagi, skoro metoda SetFocus jakoś tak dziwacznie przenosi fokus do formantu, że nie wywołuje jego procedury zdarzenia Enter.
Natomiast w Twoim poście zaciekawiło mnie określenie "kaskady zdarzeń". Gdybyś zechciał to jakoś bliżej wyjaśnić, bo ja nadal nie rozumiem, dalczego po wykonaniu procedury Enter danego formantu zostaje potem automatycznie wykonana procedura Enter następnego formantu? Przecież ja, póki co, wcale do tego kolejnego formantu się nie odnoszę! Dowód, w moim załączniku. W dodatku dzieje się tak tylko przy "przejściu" Tab-em lub Enter-em.
Pozdrawiam
Piotr Marcin |
|
|
wszystkich stron: 2
|
|
