Newsgroup: it.comp.lang.delphi
Titolo: Chiudere una form a tempo ??

Ciao a tutti,
essendo alle prime armi con la prgrammazione in delphi chiedo aiuto per
risolvere un probelmino di questo tipo:
Ho realizzato un programmino composto da 3 form e adesso vorrei definirne
una nuova come form introduttiva, possibilmente senza la barra di titolo
superiore.
Vorrei inoltre che la form si chiudesse a tempo (5 secondi per eempio)  e
partisse quindi quella che è la principale.
Ho provato ad utilizzare la close form e la show, ma ho ottenuto solo la
chiusura a tempo dell'applicazione. Mi è stato suggerito che dovrei lavorare
nella parte di "project source", si va bene ma come ?
Grazie anticipatamente a chiuque possa aiutarmi.
ciaociao
    Roberto
Rober...@inwind.it

 nella parte di "project source", si va bene ma come ?
Per lavorare nel project source, devi scegliere dal menu Project -> View Source.
Dovresti anche creare un form dinamico (sai come si fa ?) che viene creato per
primo rispetto agli altri form e si libera prima del Run, ma se hai due form
vuoti ottieni solo un blip dello schermo perchè l'esecuzione è troppo veloce,
per quanto riguarda il form senza barra del titolo devi impostare la proprietà
BorderStyle = bsnone.
Massimo

BorderStyle = bsnone.
Credo che Roby volesse sapere un altra cosa.
Con BorderStyle=bsnone levi sģ la barra superiore ma levi anche la
cornice (e rendi quidni il form non piu' trascinabile e'
personalemente antiestetico).
Ora visto che la cosa servirebbe anche a me riamplifico la domanda
fatta:  come si puo' ottenere un form senza barra superiore? Bisogna
per forza crearsi un form da solo (con le Api e i vari CreateWindow)?
~Guybrush~

io fare in questo modo. E' un modo credo rozzo ma paraculo (vallo a
sapere poi se paraculo=bello=efficace).
Metterei nel form principale un Timer con intervallo molto basso
(interval=1)
e metterei
procedure TForm1.Timer1Timer(Sender: TObject);
begin
	Timer1.enabled:=false;
	FormdiPresentazione.ShowModal
end;
Cosi appena dopo la creazione (1 millisecondo) dei 3 form il programma
passa la parola al timer che richiama il form di presentazioni. Lo
showmodal blocca tutto finche' il formdipresentazioni non viene
chiuso.
Ora nel Form di presentazione aggiungerei un ulteriore Timer con
INTERVAL=5000 (i tuoi 5 secondi) e con la proprieta' ENABLED=FALSE
anche
 
procedure TFormdipresentazione.OnShow(Sender: TObject);
begin
	Timerdelformdipresentazione.enabled:=true
end;
e dentro l'Ontimer di quest'tultimo orologio metterei 
procedure TFormdipresentazione.TimerdipresentazioneTimer(Sender:
TObject);
begin
	close
end;
Questo fa si che la procedura venga chiamata dopo 5 secondi che il
FORM di presentazione sia presentato.
Sscusa per il poco rigore con cui ho definito le procedure ma ho
scritto al volo sul mio newsreader.
Oltretutto sono molto stanco, sara' probabile che mi sono scordato
qualcosa  ;-)
Ciao
~Guybrush~

Poi mentre magari sei li che scrivi il codice e ti va di aggiungere 
altri timer fai pure, tanto chissenefrega se il tutto poi non funziona, 
ma dico io che modo di programmare è ? Credo che hai ragione è proprio 
una soluzione paraCULA.
No comment.
Massimo

OK campione...dici tu come fare
~Guybrush~

OK campione...dici tu come fare
Calma. Eri molto stanco, ricordi ? quindi calma.
Massimo ha ragione.
E' chiaro che il nostro amico sta cercando di creare uno splash form,
quindi non vedo perche' bisogna mettere di mezzo timer e altre
stupidaggini varie. Basta che il form di splash si chiuda cinque
secondi dopo essere apparso.
x Roby :
http://www.geocities.com/AndreaLaforgia
C'e' un file che si chiama SplashForm.ZIP
--
Andrea Laforgia (ICQ 87230455)
"ci sono tre tipi di persone nel mondo : quelli che
 sono bravi in matematica e quelli che non lo sono."

>
http://www.geocities.com/AndreaLaforgia
By the way, dear Andrea mi spiegheresti una cosetta sul tuo prg
Splash?
-A cosa serve il boolean che hai introdotto per la chiusura del
SplashForm?
~Guybrush~

SplashForm?
A far si' che non si chiuda alla pressione di ALT+F4 se si sta
svolgendo un'operazione durante la visualizzazione dello splash form.
Si suppone, quindi, che il calcolo dell'intervallo avvenga tramite
GetTickCount e che ci sia un Application.ProcessMessages.


 C'e' un file che si chiama SplashForm.ZIP
io metterei anche un try finally (visto che lo splash e' anche senza
owner), e poi a me sinceramente lo sleep non mi piace preferisco un timer,
basta attivarlo nell'onshow dello splash e nell'OnTimer fare il close
Ciao,
Alan Solo

basta attivarlo nell'onshow dello splash e nell'OnTimer fare il close
A mio avviso non serve e i timer andrebbero usati il meno possibile.


 A mio avviso non serve e i timer andrebbero usati il meno possibile.
e' solo che lo sleep viene tradotto come una serie di NOP (credo)
e cmq occupa inutilmente la cpu, mentre con il timer e' tutto piu' leggero
ps: perche' "timer andrebbero usati il meno possibile"?
Ciao,
Alan Solo

ps: perche' "timer andrebbero usati il meno possibile"?
Perche' sono come mine vaganti nel codice. 
E poi anche perche' Windows ha un limite numerico nell'uso dei timer
(che non ricordo qual e' esattamente).


 (che non ricordo qual e' esattamente).
ok, anche se il numero in questo caso penso sia ininfluente (per 1 "una"
form di splash...)
e poi, visto che non te la voglio dar vinta ;), la sleep blocca il thread,
quindi il programma non fa niente, e, a mio avviso, uno splash che si
rispetti dovrebbe servire per "intrattenere" l'utetne mentre il programma
si sta caricando (un po' come fa lo stesso Delphi) mentre come fai tu
- fa federe lo splash
- aspetta tot secondi
- comincia a caricare
o non e cosi'? (scusami ma non ho la possibilitaà di provare al volo)
Ciao,
Alan Solo

o non e cosi'? (scusami ma non ho la possibilitaà di provare al volo)
Alan, devi considerare che il mio e' un programma di esempio che si
limita ad implementare cio' che chiedeva Roby.
Ti ho gia' specificato nell'altro messaggio che se si vuol fare
qualche operazione durante la visualizzazione del form di splash,
bisogna usare GetTickCount per il tempo e Application.ProcessMessages.


form di splash...)
Aggiungo che l'influenza o meno, deriva da quanti timer si usano nel
codice, non dal fatto che in questo contesto se ne usi uno solo.


 tempo e Application.ProcessMessages.
mi sembra una complicazione...
mi permetto di riutilizzare il tuo codice:
var MySplashForm : TSplashForm ;
begin
 try
  // creazione splash
  MySplashForm := TSplashForm.Create( nil ) ;
  MySplashForm.Show ;
  MySplashForm.Update ;
  // caricamento applicazione
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.CreateForm(TForm2, Form2);
  // distruzione splash  
  MySplashForm.SetCloseFlag( true ) ;
  MySplashForm.Close ;
 finally 
  MySplashForm.Free ;
 end;
 Application.Run;
end.
... e poi un timer in MySplashForm per chiudere la stessa
[rispecifico che non l'ho provato, ma l'idea e' quella]
Ciao,
Alan Solo

 codice, non dal fatto che in questo contesto se ne usi uno solo.
sinceramente non ho capito
...non ho proprio capito quello che vuoi dire 8)
(... sara' che e' mezzanotte passata...)
Ciao,
Alan Solo

basta attivarlo nell'onshow dello splash e nell'OnTimer fare il close
Ups...si parla di Timer  ;-))
~Guybrush~

... e poi un timer in MySplashForm per chiudere la stessa
Ribadisco : a me NON piace.
Punto e basta.
Poi fate come volete.


(... sara' che e' mezzanotte passata...)
Se Windows limita a 100 il numero di timer e nel mio programma ne uso
100, quello in piu' per lo splash form e' un problema.
E' questo che voglio dire.
In ogni caso, ribadisco : a me non piacciono i timer, non vedo perche'
devi a tutti i costi cercare di imporre questa soluzione.


 soluzione.
e poi non sto imponendo niente, secondo me e' la soluzioni piu' semplice
(ma non per questo meno efficace) e piu' RAD, piazzi il timer, setti
l'interval e nell'otimer metti "Close", mooolto ma mooolto piu' semplice
che usare Application.ProcessMessages e cose varie...
Ciao,
Alan Solo

> Ribadisco : a me NON piace. Punto e basta. Poi fate come volete.
... e a me non piace complicare le cose inutilmente
Alan Solo

... e a me non piace complicare le cose inutilmente
Quindi non usare i timer.
--
Andrea Laforgia (ICQ 87230455)
http://www.geocities.com/AndreaLaforgia


che usare Application.ProcessMessages e cose varie...
A mio avviso e' molto piu' semplice la mia soluzione, ma visto che non
voglio discutere su chi e' piu' intelligente, mi fermerei qui.
Considerato anche il fatto che uno splash come quello che e' stato
richiesto e' piuttosto raro da utilizzare, visto che quasi sempre si
imbottisce il tempo dalla visualizzazione alla scomparsa dello splash
con del codice da eseguire.
--
Andrea Laforgia (ICQ 87230455)
http://www.geocities.com/AndreaLaforgia


>piu' che sufficienti in questo caso, come nel 99% degli altri...
Peccato che siano la soluzione sbagliata.
"Caution: Limitations on the total number of timers system-wide are
system dependent." [Borland C++ Builder 5.0 Help File - TTimer].


 che usare Application.ProcessMessages e cose varie...
E' questo il problema, la soluzione più veloce, chi ha detto che la soluzione
più veloce sia anche la più performante ?
Tu "dovresti" essere così bravo da ottimizzare il codice affichè il tuo
programma sia più efficente e compatto possibile;
quindi alle volte è richiesto uno sforzo in più al programmatore, il che non
si sposa bene (non sempre) con soluzione più veloce.
Massimo

[...]
... io lo sapevo che dovevo stare zitto
rispondo ad entrambi:
vi ricordo che stiamo parlando di 1 ("uno" "one")
che lo si attiva, tot secondi dopo chiude la form
e poi lo si distrugge quando l'applicazione e' caricata,
quindi non da nessun problema di questo tipo
(anche se io ignoravo questi probabili problemi...)
[tra parentesi, mi fareste vedere come fareste a fare uno splash non
usando un timer, io ho delle idee, ma non mi piacciono, e poi trovo
giusto farmelo dire, visto che state sostenendo questa teoria...]
Ciao,
Alan Solo

giusto farmelo dire, visto che state sostenendo questa teoria...]
I timer non servono a nulla nella creazione degli splash form, per il
semplice motivo che uno splash form e' un form introduttivo, la cui
visualizzazione deve durare per tutto il tempo delle elaborazioni
iniziali. Prima delle elaborazioni viene creato e visualizzato, dopo
le elaborazioni (il piu' tardi possibile, quindi possibilmente come
ultima istruzione dell'OnShow del form principale) viene nascosto e
distrutto.
--
Andrea Laforgia (ICQ 87230455)
http://www.geocities.com/AndreaLaforgia


 distrutto.
Spiegazione inesauriente, molto simile invece ad una tautologia :
("I timer non servono a nulla nella creazione degli splash form perchè non
servono a nulla")
Grazie, Davide DG.

ai problemi.
aridaje....  :-)
Sempre riguardo al programma per lo SplashProgramm:
-qual'e' la differenza se creo il SplashForm da solo
(SplashForm:=Tfrom.Creat(nil)) e se inceve la lascio creare al
Compilatore ( Application.CreateForm(TForm1, Form1))?
-Che succede se inverto l'ordine dei vari
Application.CreateForm(TFormX, FormX) nel programma principale?
Grazie
P.s. Andre' scommetto che ha un FireWall da paura...  :-)))
~Guybrush~

 P.s. Andre' scommetto che ha un FireWall da paura...  :-)))
pufffh, non c'e' fuocomuro che tengaaaaa!! ;)))
Ciao,
Alan Solo

 istruzione dell'OnShow del form principale) viene nascosto e distrutto.
... e dove sono finiti gli Application.ProcessMessages, GetTickCount
ecc...? Vorrei vedere delle linee di codice tnx, e non castelli per aria
(ripeto io ho delle idee, ma non mi piaccono quanto quella semplice e
orribile, a quanto pare, di un timerino)
cmq sono daccordo che lo splash deve sparire quando terminato il
caricamento, io infatti di solito nell'onshow della form main distruggo
lo splash, me metti caso che qualcuno lo voglia far vedere per piu'
tempo, magari perche' il caricamento dura poco (come ad esempio winamp)
Ciao,
Alan Solo

 che usare Application.ProcessMessages e cose varie...
Mi sembra che tu stia facendo un calcolo di "quante righe devo scrivere?"...
In realtà solo per gestire il tuo timer sfrutti delle API di Win e devi
processare i messaggi WM_TIMER... direi minimo 20 righe di codice anche se
tu ti limiti ad aggiungere un oggetto, settare la prop. Interval e scrivere
una riga di codice...
Direi che la sleep (che è anch'essa una funzione dell'API di Win ma non ti
costringe [tu o il tuo framework] a gestire messaggi & simili) è di sicuro
più performante e più efficiente (a parità di risultato hai 1 riga di codice
contro [stima mia personale] 20 ...).
--
Andrea Magni
E-Mail: 
ama...@interac.it


wrote:

Cio che e' scritto nelle righe soprastanti vuol dire che un timer non
serve nella creazione dello splash form, perche' lo splash form NON e'
una finestra destinata a chiudersi a tempo prestabilito, ma la sua
visualizzazione deve occupare il tempo variabile, necessario per
eseguire le operazioni iniziali.
Se sei incapace di capire le parole degli altri, non liquidare il
tutto con un "spiegazione inesauriente".


tempo, magari perche' il caricamento dura poco (come ad esempio winamp)
E' appunto questo il caso in cui si dovrebbe utilizzare il
GetTickCount e il fetching forzato dei messaggi. Quando sei certo che
le elaborazioni iniziali durano sicuramente meno del tempo con cui
vorresti visualizzare lo splash.
In ogni caso, non ritengo questa soluzione una buona programmazione,
perche' non si puo' mai fare affidamento che una determinata
operazione duri "poco".


 tutto con un "spiegazione inesauriente".
Tsk... molto puerile... ma tanto non capirai o farai dinta di non capire,
come al solito...
D液

 orribile, a quanto pare, di un timerino)
Lo sport di Andrea : Arrampicata libera... sugli specchi!

 riga di codice contro [stima mia personale] 20 ...).
a parte che le linee di codice sono trascurabili (come lo sono il numero
limite dei timer) [ma ragazzi, avete il senso della misura??]
... e poi, ripeto, la sleep *blokka* il thread ed e' "impossibile" fare
uno splash che sia uno *splash*
Ciao,
Alan Solo

 determinata operazione duri "poco".
e perche'? In questo caso va piu' che bene, i motivi possono essere vari.
Io ad esempio voglio essere sicuro che lo splash sia visibile per un
tempo "umano" perche' voglio essere sicuro che vengano visualizzate
informazioni sul prodotto, su me stesso, sulla software house, sui
termini di licenza, le donnine nude ecc...
Ciao,
Alan Solo

> Lo sport di Andrea : Arrampicata libera... sugli specchi!
... dei castelli campati per aria! ;)

 non ti seguo...
ops ti ho "seguito" ora... scusa per il ritardo mentale 8)
ma questo nel caso in cui *alla partenza* partano 32000(??) timer...
stragulp! :)
Ciao,
Alan Solo

... dei castelli campati per aria! ;)
Ma non sai altro che dire ca..ate ? 
Ma forse è la sola che ti riesce bene, allora credo che hai sbagliato
NG, il tuo è it.rompere.cogxxioni.molto.spesso
Teh ! Fatte stà risata
Massimo
Ps. Quando hai imparato a programmare NON tornare; sai il nostro
castello è molto in alto e bisogna arrampicarsi bene.
Non ti disturbare a rispondere tanto lo ingnoro
----------------------------------------------------------
Il vero problema non è tanto sapere se le macchine pensano
bensì se gli uomini pensano. B.F. Skinner (1904-90)
----------------------------------------------------------

Ragazzi, ma parliamo di soluzioni veloci e performanti per una splash
form?!?!?!
Vabbè che non bisogna sprecare invano ma suvvia...
Ciao e buone feste a tutti
Simone Santarelli

come al solito...
Ecco un altro bimbo a cui hanno rubato la merendina.


termini di licenza, le donnine nude ecc...
Ti sto dicendo (e fammi il piacere di capire questa volta) che
un'operazione si puo' allungare per un certo tempo non prevedibile.
Nessuno ti assicura che questo tempo sia compreso in quello limite che
imponi. Nei programmi seri non si visualizzano informazioni su donnine
nude (nei tuoi forse si'), ma si tentano, ad esempio, connessioni a
database remoti, che potrebbero non rispondere in un tempo prefissato.


Lo sport di Andrea : Arrampicata libera... sugli specchi!
Mi limito a consigliarti di rileggere il thread.
Sono stanco di discutere con dei bimbi d'asilo su argomenti futili che
tutti dovrebbero conoscere. Rileggendo il thread capirai di cosa si
sta parlando e ti si apriranno gli occhietti.


... dei castelli campati per aria! ;)
...e di discussioni con persone buone a polemizzare ma non a offrire
soluzioni. Se non hai visto soluzioni da parte mia sul mio punto, io
non ho visto codice da parte tua sul TUO punto.
Io ho risposto proponendo la soluzione al problema iniziale.
Non voglio offrire soluzioni alternative perche' un certo "Alan Solo"
e' curioso di vedere come funzionano.
Se tale "Alan Solo" vuole, la prova se la fa da solo.
Ti ripeto che i castelli campati in aria sono tipici di un certo tipo
di programmatori al quale io non appartengo di certo.


Vabbè che non bisogna sprecare invano ma suvvia...
Difatti il livello delle discussioni qui dentro non si alzera' mai,
finquando ci sara' qualcuno che discutera' delle performance e
dell'uso o meno di "timer" (!) per la creazione di splash form.
Purtroppo c'e' gente che crede che i problemi *reali* siano questi.
Poveri noi !...


Ma non sai altro che dire ca..ate ? 
Lascia stare Max.
Questo riconferma la mia teoria sul grado di preparazione medio di
questo ng. Ricordi ? ROTFL ;)


 uno splash che sia uno *splash*
mai sentito parlare di multithreading ?
No, davvero, secondo me un bel thread che si gestisca lo splash sarebbe la
soluzione + pulita da un punto di vista teorico.
Sono conscio del fatto che è + dispendiosa (anche se non poi + di tanto) a
livello di sviluppo [e forse anche a livello di esecuzione] ma direi che
sarebbe corretta.
Ps: cmq non mi è mai capitato di stare a pensarci troppo su 'ste cose...
ecco, in linea di massima sono d'accordo con quello che ha scritto Andrea La
Forgia sul fatto che uno splash dovrebbe chiudersi appena il "programma
vero" è pronto a ricevere l'input dell'utente...
Ciao


> Ecco un altro bimbo a cui hanno rubato la merendina.
sì sì bluto cativo ! lidàmela altlimenti lo dico a la maestra!
--- fly down...

 database remoti, che potrebbero non rispondere in un tempo prefissato.
Definizione di programma "serio" ?   I programmi non sono solo
contabilità&Database... sveglia!

 database remoti, che potrebbero non rispondere in un tempo prefissato.
ma che ca...sipta centra??

 al quale io non appartengo di certo.
vedi sopra.

 "programma vero" è pronto a ricevere l'input dell'utente...
Su questo, ripeto, sono daccordo pure io
Ciao,
Alan Solo

 gente che crede che i problemi *reali* siano questi. Poveri noi !...
eh si', Poveri noi !...

 Non ti disturbare a rispondere tanto lo ingnoro
allora che cavolo hai postato a fare?