Stop Event in LostFocus

[Picavbg]

Mi sto trovando di fronte ad una necessità, quella di non uscire dal controllo TextBox, qualora, dopo la pressione del tasto TAB o dopo il click su un oggetto diverso della Form, si riscontrino errori rilevabili non durante la digitazione (es. incompatibilità con altri valori presenti in una diversa TextBox). Ho pensato di riconoscere gli eventuali errori dentro l'evento LostFocus della TextBox corrente e stoppare l'uscita dalla TextBox col comando STOP EVENT .
Ebbene, ho scoperto che il comando "STOP EVENT" non stoppa per niente il passaggio del controllo all'oggetto successivo. Probabilmente ciò succede perché quando si manifesta l'evento LostFocus il controllo del programma é già uscito dalla TextBox.
Ci sarebbe un'altra possibilità: il comando dovrebbe funzionare comunque, ma Gambas contiene un'anomalia a quel punto.
Completo il mio ragionamento col mio codice di esempio:

Codice: gambas [Seleziona]

PUBLIC SUB SpeCoPre_LostFocus()
  IF NOT b_SwErro          'cioé FALSE
      TestEUR_SCP     'testa la intercompatibilità nei contenuti fra 'EUR.Text' e  'SpeCoPre.Text' e in caso di errore  pone b_SwErro   =TRUE
  ENDIF 
  IF b_SwErro          'cioé TRUE
      STOP EVENT 
  ENDIF 
END

Sbaglio io o no?
    

[Picavbg]

Ho trovato una soluzione pratica alternativa, abbandonando il comando STOP EVENT e richiamando al suo posto la proprietà SetFocus. Perciò il codice ora é:

Codice: gambas [Seleziona]

PUBLIC SUB SpeCoPre_LostFocus()
'------------------------------------------
  IF b_SwChange      'viene posto a TRUE dentro l'evento change ed ha lo scopo di eseguire il test solo se viene immesso nella TextBox un crt.
      b_SwChange = FALSE
      IF NOT b_SwErro          'cioé FALSE
          TestEUR_SCP     'testa la intercompatibilità nei contenuti fra 'EUR.Text' e  'SpeCoPre.Text'
      ENDIF 
      IF b_SwErro          'cioé TRUE
          EUR.SetFocus     'é una TextBox diversa il cui contenuto va combinato con quella corrente
''      STOP EVENT 
      ENDIF 
  ENDIF 
END

Così funziona tutto.
 
Ciao.

[md9327]

L'evento LostFocus viene attivato DOPO che l'oggetto ha perso il fuoco...

In effetti, in gambas, il numero di eventi è alquanto limitato, e in certe condizioni potrebbe servire un maggior controllo, ad esempio in PRE e un POST event...

[Picavbg]

L'evento LostFocus viene attivato DOPO che l'oggetto ha perso il fuoco...

Si, é vero, però, quando viene scatenato l'evento il LostFocus il Focus non dovrebbe ancora essere passato al successivo controllo previsto nell'ordine di gerarchia disegnato. Detto evento é pertanto agganciato al controllo appena terminato, perciò, dovrebbe permettere una gestione indolore di verifica di quanto digitato e comunicare a Gambas l'eventuale necessità di ricondurre l'utente all'area  di digitazione della TextBox per permettergli la correzione di quegli errori commessi durante la scrittura della stringa, errori rilevabili solamente dopo che l'utente abbia deciso di abbandonare la digitazione perché l'ha ritenuta conclusa.

ancora, da md9327:

In effetti, in gambas, il numero di eventi è alquanto limitato, e in certe condizioni potrebbe servire un maggior controllo, ad esempio in PRE e un POST event...

Ma l'evento LostFocus é, in un certo senso un POST event
Non capisco cosa intenda tu per post event, diverso da LostFocus. Credo che voglia riferirti ad una qualche procedura, che, a differenza del LostFocus, agisca prima che la TextBox(o altro controllo) corrente perda il Focus.

[md9327]

Il mio era un concetto logico, che esiste in svariati linguaggi, e comunque presente nelle librerie grafiche.

Ogni azione su un oggetto può scatenare almeno un paio di eventi, ovvero, uno prima che l'operazione venga effettuata, un'altro dopo che questa è terminata (ovviamente con esito positivo).

Con PRE e POST intendevo priprio questa logica, in cui l'applicazione reale può seguire nomenclature diverse. Nel tuo caso, LostFocus corrisponde appunto ad un POST event, ovvero dopo che l'azione è stata completata.

Se poi vuoi sapere se LostFocus venga attivato prima di un GotFocus sull'oggetto successivo, questo al momento non te lo sò dire... è da provare...

[Picavbg]

Il mio era un concetto logico, che esiste in svariati linguaggi, e comunque presente nelle librerie grafiche.

Ogni azione su un oggetto può scatenare almeno un paio di eventi, ovvero, uno prima che l'operazione venga effettuata, un'altro dopo che questa è terminata (ovviamente con esito positivo).

Con PRE e POST intendevo priprio questa logica, in cui l'applicazione reale può seguire nomenclature diverse. Nel tuo caso, LostFocus corrisponde appunto ad un POST event, ovvero dopo che l'azione è stata completata.

Se poi vuoi sapere se LostFocus venga attivato prima di un GotFocus sull'oggetto successivo, questo al momento non te lo sò dire... è da provare...

L'evento LostFocus viene attivato senz'altro prima del GotFocus relativo all'oggetto gerarchicamente successivo; te lo posso dire per certo perché ho avuto modo di appurarlo personalmente. Il guaio é però rappresentato dal fatto che l'utilizzo della proprietà SetFocus scombina la sequenza logico-gerrachica di Gambas, come già ho citato più volte in questa ed altre discussioni, per cui, a volte viene schedulato l'evento LostFocus relativo ad oggetti già superati in base all'ordine gerarchico corrente, provocando ripetizioni di percorsi e quindi di istruzioni che portano ad effetti indesiderati e a volte anche errati. Per rendere inefficaci tali percorsi io inserisco  dentro gli eventi LostFocus semafori logici che gestisco per mantenere il corretto comportamento del programma. Certamente non é bello né lineare da leggersi, ma non posso farne a meno. La mia speranza é che la versione 3.0 di Gambas abbia raggiunto un livello di maturità tale da non inciampare nelle suddette vecchie problematiche. Per saperlo dovrei passare alla suddetta versione 3.0, ma non mi sento di farlo prima del rilascio ufficiale.
Ciao.