Evento LostFocus in Combobox

[Picavbg]

Mi sono trovato davanti ad una sorpresa inaspettata: per individuare l'appartenenza della Combobox1.text ad un gruppo di stringhe già presenti nella Combobox1.list, subito dopo l'avvenuta selezione di una stringa già presente o di una digitazione, quindi dopo che l'utente ha deciso di passare alla casella di input successiva della form attiva, ho pensato di sfruttare l'evento "LostFocus". Ma ahimè ho scoperto che l'evento viene schedulato nel momento in cui vado a cliccare col mouse sul quadratino grigio, posto al margine destro della combobox, cioè già nel momento in cui comando l'apertura della tendina che mi permette di vedere il contenuto della relativa lista di stringhe per operare la scelta che mi interessa. Forse non ho capito, ma l'evento lostfocus non dovrebbe manifestarsi quando la Combobox perde il focus? Se é così come credo, perché la Combobox perde il focus già al click che permette di scorrere il contenuto della lista contenente le stringhe da esaminare? :-o
In VB si poteva utilizzare l'evento validate che in Gambas non é disponibile e che permetteva di eseguire del codice di controllo prima di permettere il rilascio del focus. Esiste un evento corrispondente in Gambas? :-?
Inserire il controllo nell'evento "change" che viene schedulato per ogni carattere inserito, mi sembra pesante, mentre il controllo sulla stringa già completa mi sembra che si attui nel momento opportuno. Cosa mi consigliate?
 :ciao:

[leo72]

Non ho capito bene il problema. Cmq puoi usare l'evento Click() del Combobox, che viene sollevato quando l'utente seleziona fisicamente una voce cliccandoci sopra e non quando clicca sulla frecciolina per far apparire/scomparire il menu oppure sulla barra di scorrimento.

[giulio]

Ciao. Mi sa che casualmente hai trovato un bug. Leo, vedi se ti pare il caso
di segnalare. Quello che dice pica è che l'evento LostFocus nell'oggetto ComboBox
viene rilevato quando si apre il menu a tendina del comboBox, il che è un po' innaturale essendo la tendina parte del Combobox. In più ho scoperto che con le
librerie gb.gtk l'evento LostFocus non viene rilevato (Bug?).
Allego un piccolo esempio per testare il bug. Se si usano le gtk l'evento lostfocus non viene rilevato, se si usano le qt l'evento viene rilevato troppo presto (o in modo errato)
all'apertura della tendina.

@pica per risolvere potresti mettere un booleano dentro la chiamata dell'evento
LostFocus che annulli l'evento se non sei nella condizione desiderata.

[leo72]

Ho riletto la documentazione originale del componente. Ecco cosa si legge:

EVENT LostFocus ( )

Raised when the control has lost the focus.


This event is defered.
This event is always raised before the control getting the focus raised its GotFocus event.

Evento LostFocus.
Sollevato quando il controllo ha perso il focus.

Questo evento è procrastinato.
Questo evento è sempre sollevato prima che il controllo prenda il focus sollevato dal suo evento GotFocus.

Sempre nella documentazione ufficiale, si legge a proposito del significato di Defered:

A defered event is an event that is not sent immediately, but at the beginning of the next event loop.

Un evento procrastinato è un evento che non è inviato immediatamente ma all'inizio del prossimo ciclo dell'evento.

Quindi parrebbe quasi una scelta strutturale del componente quella di far eseguire l'evento LostFocus non immediatamente ma solo prima che riprenda nuovamente il focus. Resta da capire il perché di questa scelta.

[giulio]

Leo, ci siamo capiti male. Il problema è che l'evento LostFocus è intercettato _troppo presto_, cioè quando non dovrebbe. Se apro il menu a tendina del ComboBox sotto qt, il ComboBox perde il focus. La domanda di pica a questo punto è: perché perde il focus aprendo il menu a tendina che fa parte del ComboBox?
Seconda questione: rimane il bug nelle gtk. Se provi il mio esempio sotto gtk,
e passi dal combo alla textbox, vedrai che l'evento LostFocus non è intercettato. Ciao.

[Picavbg]

@ Leo:
mi rendo conto che a furia di scrivere per spiegare il problema ho reso difficile da comprendere un concetto che praticamente é molto semplice. In realtà in prova pratica si capisce molto meglio che non a parole. Avrei fatto meglio ad allegare un esempio, ma quando ho pensato di scrivere il post era molto tardi ed evidentemente avevo cominciato a chiudere la saracinesca delle idee. Ho imparato la lezione  per un'eventuale altro stop. :oops:

giulio ha scritto:
per risolvere potresti mettere un booleano dentro la chiamata dell'evento
LostFocus che annulli l'evento se non sei nella condizione desiderata.

Si, in effetti, nonostante fosse forte il desiderio di prendere sonno, l'inghippo mi ha messo addosso un pò di  tensione e, ragionando sull'eventuale soluzione da prendere, anch'io ho pensato ad una soluzione del genere  "switch booleano"; funzionerebbe come un semaforo da fare diventare rosso nel gotfocus della combobox per concedere il via libera al lostfocus solo quando, da ,operatore deciderò di passare dalla combobox ad una casella successiva. Ciò mi comporterà perciò di andare a testare l'ultimo tasto pressato ("Enter", "tabulazione avanti o indietro" o il tasto sinistro del mouse), e... spero bene. Grazie! :ciao:  :ciao:

[giulio]

Leo, avverto che ho segnalato la cosa a Benoit, onde evitare doppia segnalazione. Vediamo cosa risponde. Saluti.

[leo72]

Ho capito il problema.
Tutto si riallaccia a ciò che spesso Benoit dice sulla mailing-list a proposito dei componenti qt e gtk. A livello di libreria ci sono diversità per cui anche le implementazioni in Gambas "ereditano" tali differenze, con il risultato che il componente gb.gtk non si comporta esattamente come quello gb.qt.

Ora ho fatto qualche prova con l'esempio allegato (modificando /usr/local/bin con usr/bin perché su Ubuntu lì non c'è niente ;-)) ed ho notato che sembra che il widget ComboBox sia in realtà costituito da 2 parti differenti a livello di libreria. Se notate, cliccando sulla voce visualizzata, si vede il rettangolino colorato del focus sulla parte testuale ma cliccando sulla frecciolina il rettangolino del focus va a circondarla scomparendo dal primo. Che poi l'evento LostFocus venga intercettato troppo presto con le Qt è da capire perché così come è da capire perché con le gtk non venga proprio intercettato. Appena posso segnalerò la cosa sulla m-l ufficiale.

[leo72]

Ah, ok. Allora non lo faccio io.

[Fabrizio]

Non va nemmeno il lost_focus dai container. Ho provato a mettere la combo in un panel e in un hbox e provare a gestire il lost_focus di quelli, ed ovviare al problema, ma nulla.

bye

[giulio]

Tra i suoi mille impegni, Benoit ha risposto. Riporto la mia segnalazione in spaghetti english
e la sua risposta. In pratica ha risolto il bug di gb.qt ma deve ancora riolvere quello di gb.gtk.

> Hi, Benoit.
>
> Please, run the attached example.
>
> 1 - bug) It seems that ComboBox control doesn't  raise
> LostFocus event when using gb.gtk component.
> Try the little example, put the focus on the TextBox
> and see.
>
> 2 - question) Switching the same example to gb.qt I noticed a little
> problem. The LostFocus event is raised when I put the focus on the
> TextBox. That's ok, but there's a strange thing.
> If I drop down the ComboBox list, the LostFocus event is raised,
> but I'm still working on the ComboBox! Why Combobox loses focus
> when I drop down _its_ list? Is it normal or is it wrong?
>
> Gambas 2.12
> qt: 3.3.8b
> gtk: 2.12.12
> Slackware 12.2

I fixed the inaccurate LostFocus/GotFocus in gb.qt, but there is a bug in GTK+
that prevents from easily getting focus events in ComboBox widgets.

So, be a little more patient!

Regards,

--
Benoît