Newsgroup: it.comp.lang.delphi
Titolo: Form

Salve, provengo dal buon vecchio pascal :)
Conosco un pochino l'OPascal e sto inizando a pastrocchiare in delphi... è
da un po' che traffico ma mi son arreso e vi chiedo stupidamente come faccio
ad aprire una nuova form da menu o da clic su bottone..
prendete come esempio l'about box :))
Grazie x la pazienza :PP

 wrote

per aprire una nuova Form nel tuo programma ( a run - time ) devi creare la
form partendo dalla variabile che la identifica e dalla classe.
Quindi se il tuo programma ha due form, la prima ti compare automaticamente
all'avvio, la seconda non compare.
Per farla comparire, puoi dichiarare l'unit della seconda form nella lista
delle uses della tua prima form ( quella che ti compare all'avvio )
Fatto ciò, nel metodo ( procedura associata al click sul bottone ) puoi
scrivere:
Form2:=TForm2.Create(nil);
Form2.ShowModal;
Form2.Free;
tu dirai: e dov'è la variabile ? La variabile Form2 è dichiarata nell'unit
della form che devi creare e visualizzare.
Comunque voglio precisare una cosa, anzi due.
Il fatto della creazione e visualizzazione sono due cose completamente
diverse.
La creazione usa il costruttore della classe TForm o magari un costruttore
ridefinito dall'utente, mentre la visualizzazione fa riferimento al metodo
Show ( non modale ) o ShowModal ( modale ) che tra l'altro caratterizza pure
il comportamento di questa seconda form nei confronti della prima.
Fai qualche prova.
Un'ultima cosa importante.
Nel progetto, puoi impostare ( tramite le Options ) l'autocreazione di una
certa form del tuo programma.
In questo modo ti basterà solo il metodo "Show" o "ShowModal" per
visualizzarla e "Hide" per nasconderla senza quindi usare il costruttore
"Create" ed il distruttore "Free".
Se fai riferimento alle tre righe di codice che ti ho scritto, se cambi la
seconda riga con "Form2.Show", devi eliminare la riga che segue e fare la
distruzione in altro modo. ( provare per credere ) Vabbè, ora mi fermo quì.
Ciaoooo !!!!1
Antonio Tarolla

 Form2.Free;


Infatti, se non cambi quello che fa lui di sui se le crea in modo automatico
e tu le devi solo visualizzare
ciao

 ha scritto:

ciao, io preferisco
Application.CreateForm(TForm2, Form2);
secondo me e' sconsigliabile usare Create(nil),
ovvero senza owner, se non liberi la form espicitamente
ti restera' in memoria
Ciao,
Alan Solo

 ti restera' in memoria
In linea di massima sarei d'accordo sul fatto che è meglio poter designare
un owner per ogni oggetto (componente)... però stavolta non ha molto senso:
[ipotesi di base: _non_ liberiamo la memoria della form esplicitamente]
- mettiamo come dici tu di avere l'application come owner: quando
l'applicazione termina la tua form viene liberata in quanto owned da
application e poi il processo termina.
- mettiamo invece che  la form non sia owned: cmq quando chiudi
l'applicazione (chiudi il processo) la memoria di tutto il processo viene
liberata...
Fortunatamente con Win32 un processo non può lasciare "rimasugli" di sè in
giro dopo essere stato terminato...
:-)
--
Andrea Magni
E-Mail: 
ama...@interac.it

 in giro dopo essere stato terminato...
cado dalle nuvole, veramente? 8) (adesso non posso ma provero' ;))
...una volta avevo fatto un prova un po' stupida, se vogliamo,
controllavo se l'evento OnDestry / OnClose veniva eseguito se non aveva
l'owner, ma adesso che mi ci fai pensare quei due eventi sono propri
della VCL e non hanno niente a che fare con il SO, giusto?
Quindi in questo caso si puo' anche usare nil, e non ci sono problemi di
memoria (come erroneamente ho detto) sempre sulla fiducia... ;)
anche dopo la correzione continuo pero' a preferire l'uso di un owner
perche' vengono gestiti correttamente gli eventi (l'owner richiama i
metodi e gli eventi degli oggetti "posseduti", le proprieta'
component e componentcount, ecc...)
ma adesso mi viene un altro dubbio, ma il garbage collector (che delphi
non ha) allora servirebbe solo in fase di runtime, giusto? Cioe' se
l'applicazione viene chiusa *tutta* la memoria allocata durante il
processo viene liberata dal SO automaticamente?
Altra domanda. Ma i profiler (di cui ne ho solo sentito parlare)
a cosa servono allora?
Ciao... e grazie ;)
Alan Solo

 a cosa servono allora?
Non sono molto ferrato sui profilers ma credo che servano "durante"
l'esecuzione dell'applicazione...
Per esempio con oggetti che istanzi + volte mantenendo lo stesso puntatore e
senza liberare la memoria:
var s:TstringList;
begin
  s := TStringList.Create;
  s.Add( 'uno' );
  s.Add( 'due' );
  s := TStringList.Create;
  s.Add( 'tre' );
  s.Free;
end;
così hai un "lack of memory" (perdita di memoria, sullo heap).
Il profiler dovrebbe segnalartelo ( ***in teoria*** lo dovresti vedere pure
col monitor di sistema di Win ma non per oggetti troppo piccoli [come nel
mio esempio] in quanto la memoria viene caricata a pagine di qualche Kb...
dovresti eseguire il codice qui sopra un migliaio di volte e allora (forse)
lo vedresti...)
Ps: il mio messaggio di risposta era lungo circa 3 volte tanto ma la mia
gatta mi ha simpaticamente premuto il tastino "Reset" proprio mentre stavo
per cliccare su "Invia"... ;-)
Ora scappo a studiare 'chè domani mi crocifiggono in sala mensa...


a cosa servono allora?
A stabilire le performance ?
--
Andrea Laforgia (ICQ 87230455)
http://www.geocities.com/AndreaLaforgia
"ci sono tre tipi di persone nel mondo : quelli che
 sono bravi in matematica e quelli che non lo sono."

 mi crocifiggono in sala mensa...
he he, non ti preoccupare, mi hai fatto chiarezza cmq :)
Ciao,
Alan Solo

 A stabilire le performance ?
non so, e' una domanda-domanda o una domanda-affermazione? 8)
Ciao,
Alan Solo

non so, e' una domanda-domanda o una domanda-affermazione? 8)
E se fosse una domanda retorica ?


 li "richiama"
No, che c'entra? I messaggi vengono postati alla finestra...
Il sistema di ownernship è uno dei modi per gerarchizzare gli oggetti fra
loro, in genere non implica (o almeno, non dovrebbe implicare) problemi al
(o alterazioni nel) funzionamento del singolo oggetto...
Ciao


 (o alterazioni nel) funzionamento del singolo oggetto...
io intendevo gli eventi della vcl,anche se sono in risposta ai messaggi,
mi *sembra* che non vengono eseguiti
avevo fatto un "test" molto idiota... avevo messo un "beep"
nell'ondestroy di una form
se la form aveva un owner (Application) si sentiva, altrimenti no 8)
adesso non l'ho piu' verificato, ma mi sembra proprio che e' cosi'...
... questo perche' penso che avendo Application come owner, questo si
preoccupa di richiamare il free degli oggetti "posseduti" (come tutti gli
owner)
Ciao,
Alan Solo

 owner)
Certo, ma ricorda che se un oggetto non ha owner _devi_ liberarlo tu (al
momento giusto)...


 momento giusto)...
infatti, per questo preferisco usare un owner, anche se ora so, grazie a
te, che la memoria viene cmq liberata dal SO a fine processo (ho
verificato e in effetti e' proprio cosi' 8)... Bill mi stupisce ;)
... quello che non mi piace pero' e' che la cosa viene fatta all'insaputa
degli oggetti VCL, ovvero, la memoria viene si' liberata, ma in modo
"duro", saltando gli eventi VCL... o ho sbagliato qualcosa (non ci sto
piu' dentroooo!!!! :)
Ciao,
Alan Solo

 piu' dentroooo!!!! :)
Dipende da come chiudi l'applicazione...
Se chiami "Application.Terminate" l'oggetto Application libera tutti i
componenti (fra cui le forms) di cui č l'owner richiamandone il metodo Free
che scatena la distruzione dell'oggetto.
Se perň l'oggetto non č owned di TApplication la situazione cambia
completamente: visto che l'applicazione termina quando la
mainform (e il suo thread) viene chiusa (nel senso di distrutta) chiudere la
mainform [cosa che probabilmente fai tu quando fai le prove di cui sopra]
implica terminare l'applicazione ===> il che significa _stroncare_
l'esistenza
delle form non-owned ma a loro _totale insaputa_! (vengono spazzate via
dalla memoria senza che nessuno glielo dica --> niente eventi
OnClose/OnDestroy)
Sta di fatto che questo non dovrebbe succedere (dovresti programmare in modo
"pulito" ovvero liberare la memoria che allochi, non un bit di meno).
'azz che mega-post... ! ;-)


 'azz che mega-post... ! ;-)
'azz mi sa che forse, pur non essendo OT stiamo un po' rompendo, o no?
boh... ;-)
Ciao,
Alan Solo