Eventi su cambio stato o click dei componenti (es. TCheckBox)

[DragoRosso]

Ciao, apro questo topic per segnalare sopratutto a quelli alle prime armi con Lazarus (ma non solo ...) alcuni comportamenti "singolari" dei componenti standard com TCheckBox, TRadioGroup, ....

Come esempio porto la TCheckBox, anche se io non la uso e ne ho costruita una mia a causa della impossibilità di modificarne le dimensioni (almeno sotto Windows).

Per questo componente vengono sempre generati gli eventi OnChange e OnClick (se dichiarati ovviamente), quindi in generale non ha molto senso dichiararli entrambi.

Se assegniamo gli eventi OnChange e OnClick  (o a designtime o a runtime) al nostro componente, questi eventi verranno chiamati quando clicchiamo sopra il componente (sia con il mouse che con la barra spaziatrice), ma non solo ... anche quando andiamo ad  assegnare a runtime la proprietà "Checked" del componente.
Oltretutto questi eventi vengono chiamati anche se il componente non è abilitato (Enabled = false) e settiamo sempre a runtime la proprietà Checked.

Attenzione: gli eventi vengono chiamati con il TRUE o il FALSE della proprietà Checked (quindi a Runtime) solo se il valore che andiamo ad assegnare è diverso da quello attuale.

Se all'interno del evento OnChange volete che il vs. componente non cambi stato, ad esempio perchè non è consentito in un particolare frangente, non utilizzate la proprietà "Checked" !!!, usate la proprietà State che può assumere uno questi valori cbUnchecked, cbChecked, cbGrayed.

Se cambiate la proprietà Checked nell'evento rischiate di generare un loop infinito, perchè verranno generati ulteriori eventi a catena.

La proprietà State non genera eventi, e può anche assumere il valore cbGrayed.

Fate attenzione sopratutto quando dovete settare il  valore dei componenti in fase di costruzione (nel metodo Create), ricordatevi che se usate un proprietà per impostare un componente questa assegnazione può scatenare degli eventi, che in alcune occasioni provocano anomalie poi rintracciabili con fatica.

Il tipico esempio è alla partenza del programma, quando i singoli moduli vengono "istanziati" e può capitare che nel settare le proprietà a runtime (come quando si usano le "ricette" in campo industriale) si richiami qualche cosa, tramite eventi secondari, che non è ancora istanziato proprio perchè non si è previsto che nell'evento quel "qualcosa" non esista. Molte volte questo porta a degli errori non visibili (perchè nascosti dai try except) e a coseguenti inconsistenze.

Saluti

[xinyiman]

Io per questo motivo uso un barbatrucco

Dichiaro una variabile globale nella form dove uso il componente. Ipotizziamo un

Checkbox1        : TCheckBox;
Checkbox1_run  : boolean; //nella form create la imposto a false

Poi nell'evento onchange del componente faccio

if not Checkbox1_run then
begin
        Checkbox1_run :=  true;
        //il mio codice
        Checkbox1_run := false;
end;

[DragoRosso]

Si si, corretto. Più che barbatrucco è un must, sopratutto perchè non è saggio usare la proprietà di un componente grafico in giro per il programma.
Ricordo che l'accesso alle proprietà di un componente grafico può essere eseguito solo dal thread principale, in quanto normalmente i componenti grafici non sono "multithread proved".

Correggetemi se dico qualche fesseria, riporto nozioni stranote nell'ambito della programmazione, ma magri in Lazarus è tutto multithread ready.

Il dettaglio è sempre quello di riallineare il componente (la visualizzazione) allo stato reale, indipendentemente se lo stato reale sia giusto o meno.

Mi è capitato con diversi prodotti commerciali che ciò non avvevniva, graficamente era una cosa ma l'elaborazione era un'altra.

Altra cosa, io non faccio uso praticamente mai di variabili globali. A meno di cose eccezionali.

Le motivazioni sono varie, ma ne parleremo in un altro post... ora vado a pranzo. 

Saluti ........

Aggiornamento:

Ehhp, causa cali di zuccheri avevo letto male il tuo codice, ora con la pancia piena ....

Quello che fai in realtà non servirebbe in termini generali, perchè l'evento viene gestito dalla coda dei messaggi nel thread principale, quindi non può essere che l'evento venga chiamato più volte senza che la precedente esecuzione non sia terminata, a meno di magheggi strani tipo Application.ProcessMessage, chiamata diretta all'evento da piu thread, uso del Journal, uso di Hack, etc .... CHE NON SI DOVREBBERO FARE.

Sei fai una prova vedrai che se cambi la proprietà nell'evento, la nuova successione di eventi (generata dal cambio della proprietà) verrà scatenata solo dopo che viene terminata la sequenza originaria, quindi in genere proteggere internamente non serve in caso di evento.

Anticipo perchè uso le variabili locali alle procedure (metodi, funzioni, etc ...): perchè così ad ogni chiamata anche "sovrapposta" si è già fatto un passo verso il thread safe. Di fatto facendo così viene creato ad ogni chiamata un nuovo stack che non interferisce con quello "già esistente" consentendo già all'interno della funzione di usare altre tecniche se necessarie per il threading (la più antica i semafori, la più moderna le operazioni atomiche).
 
C'è uno scotto da pagare, si c'è uno scotto: possibile incremento sull'uso della memoria, leggerissimo decremento di prestazioni per la creazione / liberazione della finestra di stack e della memoria relativa.

Alla prossima.