Newsgroup: it.comp.lang.delphi
Titolo: Come fare per sapere se un form è aperto?

Vorrei sapere come fare per sapere se un form è già in esecuzione.
Insomma esiste una sorta di istruzione:
if not form1.inEsecuzione then form1.show
Come fare?
PS:
delphi 6 

assigned
AS

Questa funzione dovrebbe fare al caso tuo
function Tform1.IsFormOpen(FormName: string): Boolean;
// PARAMETRI
// FormName: stringa con il nome della finestra la cui apertura è da
verificare
// VALORE RESTITUITO
// la funzione rende False se la finestra non è stata ancora creata,
altrimenti restituisce True
var
  Index: Integer;
begin
  Result := False;
  for Index := 0 to (Screen.FormCount - 1) do
    if (CompareText(Screen.Forms[Index].Name, FormName) = 0) then
    begin
      Result := True;
      Break;
    end;
end;
bye

e funziona anche se il programma è aperto da due computer diversi?
ma che in rete utilizzano lo stesso database?
"Gamius" <Massimili...@SoftWay.it> ha scritto nel messaggio 
news:1128689202....@o13g2000cwo.googlegroups.com...


hai fatto la domanda sbagliata.
AS

Fulvio ha scritto:

Dipende da ciò che intendi per "in esecuzione"; ti riferisci al fatto 
che sia visibile oppure al fatto che esso sia semplicemente creato e 
presente in memoria?
Per verificare se un form è visibile, ti basta utilizzare la proprietà 
/Showing/, comune a tutti i controlli.
Se intendi invece verificare se una form è stata creata, supponendo che 
il riferimento all'oggetto Form in quanto tale venga memorizzato da 
qualche parte al momento della creazione, ad esempio in una variabile o 
in un campo, è possibile testare se quel campo è assegnato con la 
funzione *Assigned* oppure verificando che sia diverso da *nil*.
Ovviamente, per essere attendibile, occorre instaurare un meccanismo per 
cui tale riferimento viene ripristinato a *nil* quando il form relativo 
viene "distrutto".
Ciao,
   Marco.
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)

Allora mi spiego meglio.
Tale programma funziona in rete tra 2 computer,
quindi vorrei fare in modo che se ComputerA sta
lavorando tramite il Form1, allora tale Form1 non
sia apribile da ComputerB il quale potrà lavorare
solo sul Form2 fino a quando ComputerA non
smette di lavorare sul Form1?
Spero di essermi fatto capire
;) 

 ha scritto nel messaggio 
news:43466d3b$0$20501$4faf...@reader4.news.tin.it...


> assigned
Puo essere istanziata ma non visibile
Bye,
Raktzo

Devi usare qualche sistema di messaggistica su rete.
tipo mailbox, sistema server/client UDP/TCP o roba del genere
Bye,
Raktzo

 smette di lavorare sul Form1?
In tal caso, come ti è stato già suggerito, l'ideale sarebbe instaurare 
un meccanismo di comunicazione interprocessuale via rete, ad esempio un 
protocollo TCP personalizzato da usare con i componenti Indy per 
consentire alle due applicazioni di colloquiare e di conoscere quali 
elementi dell'interfaccia vanno resi agibili e quali no in base ai 
criteri che stabilirai in totale libertà. :-/
Il sito ufficiale dei componenti Indy è:
http://www.indyproject.org
Ci troverai anche esempi e documentazione, nonchè la versione più 
recente se desideri sostituirla a quella installata di default in Delphi 
(anche se non conosco la versione di cui disponi).


Fulvio ha scritto:

Devi gestirti un semaforo su file system.
Nella più semplice delle ipotesi su un server tieni un file di pochi 
byte che, ad ogni apertura delle form andrai ad aprire in modalità 
esclusiva e chiuderai alla chiusura del form (oppure sarà chiuso in 
automatico qualora l'applicazione dovesse bloccarsi).
Il primo form che viene eseguito esegue l'apertura ed il lock, attivando 
il semaforo. Gli altri non riusciranno ad aprire il file e quindi potrai 
intervenire di conseguenza.
Un'altra ipotesi è quella di effettuare il lock direttamente su una 
tabella/pagina/record del tuo database, ma le modalità dipendono dal db 
stesso.
Ciao,
Gianluca.

> protocollo TCP personalizzato da usare con i componenti Indy per
In UDP sarebbe meglio, più veloce(non hai i ritardi per
connessione/disconnession), un po meno affidabile(ti devi gestire la
mancata ricezione del pacchetto)
Bye,
Raktzo

 mancata ricezione del pacchetto)
Siccome è possibile una mancata ricezione del pacchetto, non c'è il 
rischio che le due applicazioni ricevano dati errati rispetto a quelli 
che si aspettano?
Sto realizzando un'applicazione che fa uso di questa tipologia di 
comunicazione e vengono scambiati comandi e parametri: se uno di questi 
arriva non corretto, potrebbe provocare un pochino di caos. :-/


 arriva non corretto, potrebbe provocare un pochino di caos. :-/
Potrebbe se non hai un meccanismo che ti assicuri che il pacchetto è stato
ricevuto.
Hai vantaggi nel senso che in TCP hai
Connessione  ->
     <- ACK
trasmissione ->
     <- ACK
disconnessione ->
     <- ACK
 
mentre in UDP avresti(con adeguato meccanismo di ACK)
trasmissione ->
    <- ACK
tutto il resto te lo risparmi.
Il TCP ti è molto più utile nelle connessioni stabili.
E non farmi l'esempio del HTTP che lavora in TCP! :-)
Bye,
Raktzo

Ho risolto in un'altra maniera, molto più spartana.
Ho creato una tabella con dentro dei campi booleani,
che diventano true quando il form è aperto e ridiventano
false quando il form si chiude.
Così posso avere anche 10 programmi aperti contemporaneamente,
ho appena provato, ma nussuno apre form al momento apeerti da altre parti.
Così evito qualsiasi casino.
;) 

 Ho risolto in un'altra maniera, molto più spartana.
La soluzione è infatti molto semplice e immediata, ma non sono sicuro 
che non possa comportare qualche effetto collaterale in futuro, oltre al 
fatto che le performance non sono forse ottimali, ma magari mi sbaglio.


Fulvio ha scritto:

Puoi avere problemi di Deadlock.
Se ad esempio, subito dopo aver aperto il form ed impostato il semaforo 
a True, il PC si blocca e viene riavviato, nessuno ti garantisce che 
quest'ultimo sia tornato a false.
Devi trovare una soluzione che ti garantisca il rilascio della risorsa 
qualsiasi cosa accada.
Ciao,
Gianluca.

 criteri che stabilirai in totale libertà. :-/
A mio avviso la soluzione è poco scalabile.
Se un domani le installazioni dell'applicazioni dovessero diventare tre 
o piu, sorgerebbe il problema di dover "andare in giro" per la rete a 
chiedere a tutte le istanze aperte quale form hanno aperto.
Ciao,
Gianluca.

Se ti crasha la form prima di resettare il flag sul DB che succede?
Bye,
Raktzo

 chiedere a tutte le istanze aperte quale form hanno aperto.
La soluzione proposta era orientata al caso specifico di due applicazioni.
Per renderla scalabile, basta designare un'applicazione che faccia da 
server e giri su una macchina specifica che verrà contattata dalle 
applicazioni "satelliti" per sapere a quali funzionalità possono 
accedere nel momento specifico.


Oppure una configurazione tipo NetBEUI, il primo che parte si comporta da
master e lo resta fino a quando non va giu. Da quel momento qualcun altro
prende il posto del master e si va avanti.
Nulla di complesso.
Oppure un semplice messaggio in broadcast
"chi c'è in giro?"
se qualcuno risponde non si avvia il form.
Bye,
Raktzo

E' da ieri che faccio prove e non ha avuto alcun problema.
Ogni volta che apro un form (tramite il relativo pulsante):
- attivo la tabella semaforo
- imposto il volore boolean
- disattivo la tabella semaforo
Ogni volta che premo il bottone per aprire un form:
- attivo la tabella semaforo
- controllo il volore boolean
- se ok apro sennň non posso
- disattivo la tabella semaforo
Cosě non ho accavallamento di apertura sulle stesse tabelle.
Alla chiusura del programma reimposto tutti
i valori bollean al valore di partenza. 

 E non farmi l'esempio del HTTP che lavora in TCP! :-)
Non ho capito cosa volevi dire, ma quoto il tuo ultimo messaggio 
riguardo il protocollo UPD per segnalare un articolo pubblicato proprio 
oggi su "About Delphi Programming" che parla dell'argomento:
http://delphi.about.com/od/adptips2005/qt/udpvstcp.htm
Non so quanto possa essere effettivamente utile ai fini della 
discussione specifica, poichè l'autore del thread ha già risolto con un 
database ma...non si sa mai, nel caso che cambi idea... :-)


 i valori bollean al valore di partenza.
Ecco, ti crasha l'applicazione prima della chiusura o caduta di
alimentazioni, reset accidentale, varie ed eventuali, cosa accade?
In pratica, se per qualsivoglia sfigata motivazione non riesci a resettare i
booleani, che fai?
Bye,
Raktzo

 database ma...non si sa mai, nel caso che cambi idea... :-)
E' usa soluzione che implica un rischio particolare, vediamo se l'ha
considerato quel caso. Ma da come mi sta rispondendo...credo di no.
Bye,
Raktzo

Ma qual'è il problema se il programma dovesse crashare?
Ad ogni avvio del programma faccio fare i dovuti controlli,
e se nessuno sta utilizzando il programma a quel momento
(me ne accorgo perchè il database MDB non ha ancora creato il
suo file temporaneo) allora resetto la tabella semaforo.
Alle persone che utilizzano il programma dirò che se
non riescono a aprire alcune finestre, basta che tutti
chiudano il programma e poi il primo che lo riapre
rimette tutto apposto.
Lo so che non è il massimo, ma so anche che tale programma viene
utilizzato da due sole persone ed in futuro so per certo che
sarà utilizzato al massimo da tre persone (tutte nella stessa stanza).
Comunque con tale stratagemma evito semplicemente che alcuni form
vengano aperti in modo tale che le persone non facciano casini
accedendo contemporaneamente alle stesse informazioni.
Anche se tale programma volesse essere utilizzato da 10 persone, devono
solo sapere che se non riescono a aprire alcune finestre, basta che tutti
chiudano il programma e poi il primo che lo riapre rimette tutto apposto. 

Contento tu e contenti loro, contenti tutti.
Personalmente non mi sembra una buona soluzione, specialemente dire "se non
va, chiudete tutti e poi ripartite"...
Ma ripeto, sei tu che valuti le premesse e le conseguenze. Se la soluzione è
per te un buon compromesso, allora OK.
Bye,
Raktzo

 va, chiudete tutti e poi ripartite"...
Sono anni che Bill Gates dice questo ... ed è diventato l'uomo più
ricco del mondo!
-- 
ACSH
[D4]
Chi fa da se', fatica il doppio

 ricco del mondo!
Ecco perchè da anni non uso più win
Bye,
Raktzo