Newsgroup: it.comp.lang.visual-basic
Titolo: [DEBUG] Monitoraggio file aperti

E' possibile, in modalità debug, monitorare quali files sono aperti e con
quale id? Ho già provato ad aggiungere un controllo su #1, ad esempio, ma
non me lo piglia! Il problema è il seguente: ho fatto una applicazione che,
ad intervalli regolari, apre un file di log, e ci scrive un po' di roba.
Ovviamente mi premuro sempre di chiudere il file tramite l'istruzione Close
#1. Nonostante ciò, in taluni casi, mi viene segnalato un errore perchè il
file risulta già aperto!
--------------------------------
Inviato via 
http://usenet.libero.it


e fa bene!
se apri e chiudi file spesso!
#1 NO NO NO NONO NO NO MOOOO BUUUUU
ce sta freefile apposta!
E cchecavolo!
Programmatore niubbo?
No problem ...premi il dito su F1 "freefile"
e metti una var!
Non sei un niubbo???
Beh allora!...una svista????
--
Il Wodkino Nazionale è a : 
www.martek.it
Pagina Vb/Bestiario/Lamer Experience :
http://www.martek.it/go.asp?portamia=2
 Quotefix e altro:
http://www.martek.it/go.asp?portamia=4
Usr: ICLVB Pw: amici

 Beh allora!...una svista????
Niubbo... Puň darsi!
Ma scusa, io in una funzione faccio
 
   Open ... as #1
   ...
   Close #1
l'Id #1 non dovrebbe essere, a questo punto, libero?
Se non fosse cosě, mi verrebbe da pensare che alla lunga si saturerebbero
tutti gli id!
A questo punto, dimmi dove sbaglio....
Grazie!


 ha scritto nel messaggio
news:194Z243Z137Z67Y...@usenet.libero.it...


 saturerebbero tutti gli id!
Ci sono due problematiche:
1) se c'è un errore e tu lo hai gestito con un on error, potresti aver
saltato il close.
Al giro dopo, #1 è ancora aperto.
2) il close può richiedere un po' di tempo. Al giro dopo, potrebbe essere
ancora in uso per una frazione di secondo.
Se cambi #, ed usi freefile, sei sicuro di usarne uno libero.
Quando #1 sarà effettivamente chiuso, al giro dopo sarà proprio #1 ad essere
assegnato da freefile.
Comunque, se i file di testo che usi sono solo uno, puoi anche usare, a
scanso di equivoci, Close senza parametri, così chiudi tutto e buonanotte.
Ciao
Alberto

 ancora in uso per una frazione di secondo.
Questa mi pare una cosa sensata, tantopiù che il problema si verifica solo
in una condizione particolare (non sto a darti i dettagli, sarebbe troopo
lunga!!!)
Comunque grazie infinite!!!!
Ciao


 Grazie!
Sbagli nell'usare #1
non sempre le operazioni sui file (ANZI MAI) sono veloci!
Veloci rispetto alla esecuzione del programma!
Li HD si son evoluti...ma la memora ram č ancora moooooooooolto piů veloce!
Considera poi che tutto va in maniera asincrona....il programma non aspetta
la fine della scrittura del file per andare avanti!
Se scrive un solo dato puň darsi che tutto vada ancora bene!
ma se scrivi su un file una sequenza di caratteri lunghi....puň darsi SE usi
#1
che tu fai
OPEN#1
PRINT#1 roba lunga
CLOSE#1
....qualcosa
e poi OPEN #1
beh qui il tuo HD (non parliamo di floppy o zip poi!)potrebbe sempre stare a
scrivere....e/o non avere ancora rilasciato #1
se lo riusi....lui si incazza e ti dice
"A coso! nun posso aprě du vorte la solita porta! E damme respiro!"
Il respiro č propro FREEFILE
Echecaz! ;-)
Ma sta roba la trovi scritta su MSDN eh!
Ciao!
--
Il Wodkino Nazionale č a : 
www.martek.it


 ha scritto nel messaggio
news:194Z243Z137Z67Y...@usenet.libero.it...

** Articolo inviato tramite i servizi gratuiti di 
www.x-privat.org
 **

 l'operazione di apertura...scrittura....chiusura threadsafe.
No, le scritture vengono fatte tutte in modo "sequenziale" (nel senso che
non ci possono essere più attività di scrittura contemporanea). Il problema
risiedeva efettivamente nei tempi di apertura e chiusura, come indicato da
Wodka e Albe.
Comunque ancora grazie a tutti!
