Italian community of Lazarus and Free Pascal

Magari potresti anche provare la classe TEventLog:

https://lazarus-ccr.sourceforge.io/docs/fcl/eventlog/teventlog.html

Volendo potresti cancellare solo quei due file.
Se il compilatore ti indica form8 e quella variabile non esiste più, magari è un'altra la unit che non viene aggiornata. Per il "refactory" in genere si usa il Crtl+Shift+E . Ci pensa lazarus a cambiare i nomi delle classi/variabili per te e le dovrebbe modificare tutte. Uso "dovrebbe" perché ogni tanto mi scazza.
Prendi i file intermedi (o e ppu) e cancellali tutti. Così sei sicuro che non ci siano problemi.
Tanto il compilatore li ricrea in poco tempo.


Giusto per fare la prova.


Stilgar.

@slapshot
[/size]
Pompa dei messaggi è il mio modo di descrivere il meccanismo che permette di inviare messaggi alle applicazioni.
Come sistema operativo e anche come applicazione.


Il sistema operativo conosce le finestre che ha visibili.
Se nascondi tutte le finestre e liberi il desktop, poi selezioni l'applicazione che ti interessa, il sistema operativo manda dei messaggi per riattivare le finestre che devono essere visualizzate.
Lazarus rimappa questi messaggi, nel caso d'esempio LM_SHOW (vado a memoria, potrei ricordare male la costante)
Internamente viene fatto il routing del messaggio verso la finestra interessate che riceva il messaggio. TForm gestiste tutto questo in modo trasparente.
Se crei la finestra fuori dal contesto applicativo, hai si la form attiva e visibile, ma in caso di "Update" o metodi legati ai messaggi da so/app, potresti avere comportamenti non attesi. Devi controllare tutto tu. Anche l'aggiornamento.


E' corretto, lecito e intelligente, non creare 150 form, di cui al massimo solo 1 o due sono attive contemporaneamente, 150 sono veramente tante. Basta creare e distruggere in modo corretto le istanze. Stiamo parlando di un caso limite però.


Lazarus creata di default tutte le form. Quando crei una nuova form dal designer, aggiunge il codice per la creazione. Il pattern comportamentale proposto è questo.


Le TForm sono classi "particolari" che hanno bisogno di qualche attenzione in più. 


Il design a messaggi, è utilizzato anche da SDL (videogiochi/multimediale). Giusto per non sembrare Winzozo oriented.


Stilgar.

Ciao Slapshot.Ni, messa così è possibile che la pompa dei messaggi non riesca ad inviare le notifiche alla form create come istanza di un oggetto generico.
Bisogna passare per forza attraverso l'aggancio all'istanza di Application. Il createForm serve a quello. Far sapere all'applicazione quali form deve controllare e utilizzare per l'invio delle notifiche dei messaggi. (La sto riducendo all'osso, scorticandolo)

Diciamo che il metodo classico, prevede che la form di attesa venga creata e nascosta.
Al momento del bisogno la si porta in primo piano visibile e poi la si nasconde nuovamente quando non è più utile.

In questo modo si evita qualche casino.

Grazie, confesso che i miei ricordi mi dicono che la pratica di creare automaticamente le form all'avvio del software non era proprio ideale. Ad esempio, creare 150 form all'avvio dell'applicazione soltanto per visualizzarle in caso di necessità da parte dell'utente era una prassi da sconsigliare. Molto meglio istanziare l'oggetto a partire dalla classe necessaria quando se ne aveva bisogno per poi distruggerlo al termine del suo utilizzo. Poi se assegnare o meno un owner era da verificare in base alle esigenze del software.

La questione della pompa dei messaggi non riesco bene a comprenderla, ovvero: quale sarebbe il vantaggio di ricevere messaggi dalla coda di TApplication per form che sono inerti e che devono essere attivate ? Sicuramente ce ne sono, è per capire più a fondo.

Grazie mille @Stilgar !