* * * *

Privacy Policy

Forum ufficiale

Se non siete riusciti a reperire l'informazione che cercavate nei nostri articoli o sul nostro forum vi consiglio di visitare il
Forum ufficiale di Lazarus in lingua inglese.

Lazarus 1.0

Trascinare un file nel programma
DB concetti fondamentali e ZeosLib
Recuperare codice HTML da pagina web
Mandare mail con Lazarus
Stabilire il sistema operativo
Esempio lista in pascal
File INI
Codice di attivazione
Realizzare programmi multilingua
Lavorare con le directory
Utilizzare Unità esterne
TTreeView
TTreeview e Menu
Generare controlli RUN-TIME
LazReport, PDF ed immagini
Intercettare tasti premuti
Ampliare Lazarus
Lazarus e la crittografia
System Tray con Lazarus
UIB: Unified Interbase
Il file: questo sconosciuto
Conferma di chiusura di un applicazione
Liste e puntatori
Overload di funzioni
Funzioni a parametri variabili
Proprietà
Conversione numerica
TImage su Form e Panel
Indy gestiore server FTP lato Client
PopUpMenu sotto Pulsante (TSpeedButton)
Direttiva $macro
Toolbar
Evidenziare voci TreeView
Visualizzare un file Html esterno
StatusBar - aggirare l'errore variabile duplicata
Da DataSource a Excel
Le permutazioni
Brute force
Indy 10 - Invio email con allegati
La gestione degli errori in Lazarus
Pascal Script
Linux + Zeos + Firebird
Dataset virtuale
Overload di operatori
Lavorare con file in formato JSON con Lazarus
Zeos ... dietro le quinte (prima parte)
Disporre le finestre in un blocco unico (come Delphi)
Aspetto retrò (Cmd Line)
Lazarus 1.0
Come interfacciare periferica twain
Ubuntu - aggiornare free pascal e lazarus
fpcup: installazioni parallele di lazarus e fpc
Free Pascal e Lazarus sul Raspberry Pi
Cifratura: breve guida all'uso dell'algoritmo BlowFish con lazarus e free pascal.
Creare un server multithread
guida all'installazione di fpc trunk da subversion in linux gentoo
Indice
DB concetti fondamentali e connessioni standard
Advanced Record Syntax
DB concetti fondamentali e DBGrid
DB concetti fondamentali e TDBEdit, TDBMemo e TDBText
Advanced Record Syntax: un esempio pratico
Superclasse form base per programmi gestionali (e non)
Superclasse form base per programmi gestionali (e non) #2 - log, exception call stack, application toolbox
Superclasse form base per programmi gestionali (e non) #3 - traduzione delle form
Superclasse form base per programmi gestionali (e non) #4 - wait animation
Un dialog per la connessione al database:TfmSimpleDbConnectionDialog
Installare lazarus su mac osx sierra
immagine docker per lavorare con lazarus e free pascal
TDD o Test-Driven Development
Benvenuto! Effettua l'accesso oppure registrati.
Aprile 12, 2021, 11:34:11 pm

Inserisci il nome utente, la password e la durata della sessione.

56 Visitatori, 0 Utenti

Autore Topic: Eventi su cambio stato o click dei componenti (es. TCheckBox)  (Letto 123 volte)

DragoRosso

  • Jr. Member
  • **
  • Post: 66
  • Karma: +2/-0
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
« Ultima modifica: Marzo 25, 2021, 06:14:17 pm da DragoRosso »
:) Ogni alba è un regalo, ogni tramonto è una conquista :)

xinyiman

  • Administrator
  • Hero Member
  • *****
  • Post: 3008
  • Karma: +9/-0
Re:Eventi su cambio stato o click dei componenti (es. TCheckBox)
« Risposta #1 il: Marzo 26, 2021, 11:39:24 am »
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;
Ieri è passato, domani è futuro, oggi è un dono...

DragoRosso

  • Jr. Member
  • **
  • Post: 66
  • Karma: +2/-0
Re:Eventi su cambio stato o click dei componenti (es. TCheckBox)
« Risposta #2 il: Marzo 26, 2021, 11:59:09 am »
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.  ;D

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.
« Ultima modifica: Marzo 26, 2021, 03:07:35 pm da DragoRosso »
:) Ogni alba è un regalo, ogni tramonto è una conquista :)

 

Recenti

How To

Utenti
  • Utenti in totale: 707
  • Latest: panfra
Stats
  • Post in totale: 14624
  • Topic in totale: 1828
  • Online Today: 60
  • Online Ever: 900
  • (Gennaio 21, 2020, 08:17:49 pm)
Utenti Online
Users: 0
Guests: 56
Total: 56

Disclaimer:

Questo blog non rappresenta una testata giornalistica poiché viene aggiornato senza alcuna periodicità. Non può pertanto considerarsi un prodotto editoriale ai sensi della legge n. 62/2001.