Newsgroup: it.comp.lang.visual-basic
Titolo: [VB6] Elaborare più file ascii

Ciao a tutti,
ho un programmino con una filelistbox che elenca tutti i file di testo 
che devono essere elaborati uno per volta e poi eliminati. Finora non mi 
è mai capitata una situazione di dover leggere più file: come posso 
gestirla?
 
In pratica sul form c'è questa filelistbox e c'è il pulsante "leggi da 
file..." che, una volta premuto, chiama la sub LeggidaFile(nomeFile), 
che legge il file (uno per volta), fa quello che serve a me e poi una 
volta terminata la lettura deve passare al file successivo.
Eventualmente una volta terminata la lettura si può eliminare il file di 
testo sorgente
 
Un grazie a tutti in anticipo per l'aiuto
Francesco


Qual'è esattamente la tua esigenza?
 
Devi elaborare contemporaneamente più file in maniera autonoma (quindi chiamare più volte la routine LeggidaFile, passando un singolo nome), oppure devi fare una sola chiamata alla routine, ma dandole in input più file insieme?

 gestirla?
 
Parola magica
 
MULTISELECT
 
una volta abilitata potrai scegliere più voci della listbox che ti 
troverai dentro un array
 
 
UN ESEMPIO COMPLETO
qui
http://www.vbexplorer.com/VBExplorer/vb_feature/june2000/june2000.asp
 


Ciao a tutti, in realtà ciò che serve a me è la lettura dei file uno per 
volta. Spiego in pseudocodice
 
Leggo quanti file ci sono nella fileListBox
 
Inizio ciclo
Apro il file in input
 
	Chiamo la procedura LeggidaFile(nomeFile)
	Controllo eventuale presenza di errori
 
Chiudo il file di input (ed eventualmente lo cancello qui)
 
Passo alla lettura del file successivo
Ripeto finchè ci sono file da elaborare
 
Ora quello che so fare è aprire il file di input, lanciare LeggidaFile e 
chiudere il file di input...è tutto il resto dello pseudo-codice che mi 
è...oscuro :)
 
Francesco
 

 Francesco
 
- Cicli sulla listbox per prendere i nomei dei file
     * Leggo il pathFile
     * Se LeggiDaFile(pathFile) ha esito positivo
          Elimino il file
       Altrimenti
          ' Gestisci l'ipotesi
 
La Open devi farla all'interno del metodo/Funzione LeggiDaFile la quale 
dovrà ritornare un valore per indicare che l'operazione è andata a buon 
fine.
Ovviamente si tratta di conoscere un po' di sintassi di VB6 che credo tu 
conosca già :)
 


ANDEM BEN!
UN ciclo
DA la posizione 0 ossia primo elemento della listbox
A conta quanti elementi ci sono -1 (-1 perchè parti da zero)
 
Una cosa del tipo
in un bottone evento CLICK
 
 
For I = 0 To List1.ListCount - 1
	NomeVocelistbox=List1.list(I)
	ValoreAssociato=List1.itemdata(I)'casomai ti servisse
 
	LeggidaFile(nomeVocelistbox)
 
 
Next
 
dovrebbe funzionare.....vado a spanne...chissà se mi son ricordato la 
sintassi giusta!VB6 oramai è nei ricordi!
 
 
 
 

 
 
Torna a VB6 :D
 


Neanche morto.... solo per soldi lo farei!
potrei tornarci solo se mi dassero un lavoro per vb6! :P
 

 è...oscuro :)
 
E' un banale ciclo sugli elementi del FileListBox, che come ti hanno suggerito prima, basta impostare a MultiSelect.
 
Dim i As Long
 
For i = 0 To File1.ListCount - 1
    If File1.Selected(i) Then 'E' evidenziato?
        'arrivati qui File1.List(i) rappresenta un singolo file
        'selezionato, fai quello che fai di solito
    End If
Next

Francesco Tattoli ha scritto...

Private Sub CmdLeggidaFile_Click()
    For n = 0 To File.ListCount - 1
        If LeggidaFile(File.List(n)) Then Kill File.List(n)
    Next n
End Sub
Private Function LeggidaFile(ByVal Fl As String) As Boolean
    On Error GoTo Errore
 
    'Qua devi inserire la tua routine
 
    LeggidaFile = True
Errore:
End Function 
 

 ha scritto:

Magari aggiungi un Exit Function dopo LeggidaFile = True 
 
:D
 

 :D
zitto....zitto non glielo dire che s'arrabbia!
 
...c'ha lo snippet copiaincollato male nel suo db!!!!
 
:oD
 
 

 
 
ROTFL! :D
 

 End Function
 
Magari aggiungi un Exit Function dopo LeggidaFile = True
 
In questo caso ï¿œ superfluo dato che dopo "Errore:" non c'ï¿œ nient'altro se 
non l'uscita!!! :D 
 

 non l'uscita!!! :D 
 
OMG! :O
 

Visto che credi tanto in Dio... va a pregare che qualcuno non si accorga 
delle cagate che ti escono dalla bocca!!! Rifletti prima di scrivere... non 
cercare errori negli altri, cercali in te stesso!!! 
 

 cercare errori negli altri, cercali in te stesso!!! 
 
Ahahaah prenderla bene :D
Prenditi una camomilla! Offro io.
 

hahahahah
Fa una cosa... prenditene due tu e siamo a posto!
:D


....Rilancio di 4 camomille!
Vedi?
 

 Vedi?
 
Azz se non fosse così caldo..... vabbhè dai una camomilla in compagnia si beve
sempre con piacere :)
 

Se c'è una cosa che odio è la camomilla... da me solo caffè!
 
Le critiche sono sempre le benvenute quando sono motivate!!!
Quando sono gettate lì giusto per dire qualcosa...
...fanno solo incazzare!!!
 
Alla salute... :) 
 


Perchè te john e l'idiota di questi giorni siete dei VERI incazzini 
.....altro che io...sono un ragazzo al confronto!
 
Quello di cui trattiamo è codice, lavoro....non sentimenti, passioni!
Sul lavoro ci sta di fare giusto e essere cazziati...ci sta di fare 
sbagliato ed essere premiati!
Viviamo in un mondo imperfetto!
Bisogna imparare a dire "è solo lavoro" "son solo parole"...resistere ed 
avere il nostro buen retiro altrove!!!
Io ce l'ho nella mia famiglia e nei miei hobby (che ovviamente...siccome 
importanti davvero PER ME...mai mischierò col lavoro e con i vari NG!)
 
...ovviamente ....
bisogna avere queste valvole di sfogo....
 
se non ci sono...eh beh! L'idiota lo dimostra!
 
 
Nello specifico
HAI SBAGLIATO
 
NON LO DICE....ma desumilo dal contesto....colui che chiede..è 
QUANTOMENO inesperto! Parecchio inesperto!
Forniscili se vuoi farlo in maniera davvero "alla community" un aiuto 
DIDATTICAMENTE VALIDO...tradotto: INSEGNALI!
 
Inutile ce tu gli insegni le scorciatoie se non sa nemmeno che sentiero 
imboccare!!!
On Error GoTo Errore
 
    'Qua devi inserire la tua routine
 
    LeggidaFile = True
Errore:
 
è sbagliato!...tu lo sai che è l'ultima istruzione ed è 
ininfluente....tu credi che questo tizio sia così esperto da averlo capito?
Sei sicuro che in situazioni analoghe ma più complesse metta l'exit?
 
Il dare TIP "esperte" ad inesperti imho è sbagliato...e' come dare una 
motosega con il freno d'emergenza disattivato ad un bambino.....la 
daresti a tuo figlio/nipote?
 
Sempre e soltanto imho ovvio!!!
fare un copiaincolla di uno snippet e dire arrangiati è più facile....
ok...ma a che serve se non fare alzare il numero di post mensili?
 
mi rimane difficile sempre capire l'incazzatura da primadonna offesa!!!
Ma oramai si incazzano tutti....dal bidello al primario!!!

Vedi... quello che anche altri cercano di far capire a te e a qualche altro, 
è che i punti di vista sono diversi e tutti ugualmente  validi. Io rispetto 
il tuo punto di vista, ma se permetti preferisco il mio.
Non è una scorciatoia!!! Sbagli di grosso... è una stesura essenziale senza 
fronzoli, senza cose inutili... non l'aveva richiesto, ma c'è anche un 
minimo di controllo degli errori... il tutto in una manciata di righe di 
codice che si può divertire a studiare se vuole imparare... altrimenti che 
faccia pure come gli pare! I comandi si usano quando servono... non per fare 
gassosa!!! Ha chiesto un aiuto, un frammento di codice... e questo ha avuto! 
 


La mia intenzione non era quella di scatenare un flame o di aprire un 
dibattito fra voi che sicuramente siete frequentatori più assidui di 
questo NG...non pensavo davvero si arrivasse a questo.
Ciò che avevo chiesto nell'aprire il thread era una mano, sotto 
qualsiasi forma essa sia pervenuta, a risolvere il mio problema. Poi se 
nella risposta avessi incontrato qualche riga di codice o comando a me 
ignoto avrei chiesto ulteriori spiegazioni, oppure faccio come faccio 
sempre col mio amico google.
Spero che questa diatriba sia "amichevole", nel senso che spero non ci 
siano conseguenze, perchè ripeto, non era nelle mie intenzioni.
Intanto comunque vi posso ringraziare perchè grazie a tutti i vostri 
consigli il problema è stato risolto. Ne sono sorti altri minori che ho 
provveduto a risolvere da solo
 
Vi devo una birra...Peroni, naturalmente!!
 
Francesco
 

Sono contento che hai risolto,
per quanto riguarda le polemiche qui è all'ordine del giorno!
 
Io sono del parere che se uno vuole intervenire,
interviene come meglio crede...
...nel senso vivi e lascia vivere!
 
Ognuno ti dona la propria esperienza,
e qui tutti abbiamo esperienze diverse.
 
De gustibus non disputandum est 
 

 De gustibus non disputandum est 
 
Tu però te la prendi solo perchè una persona ti fa notare che c'è un problema
"logico" in quello che hai scritto. 
Se poi ritieni che quello che scrivi debba per forza essere preso per
buono....bhè...abbiamo (hai) un problema.
 

buono....bhè...abbiamo (hai) un problema.
 
Sei proprio ignorante di tuo... o c'hai lavorato sopra per diventarlo?
Ancora insisti con questa tua logica sballata e demotivata?
 
Ti faccio fesso e contento...
 
Private Sub CmdLeggidaFile_Click()
    For n = 0 To File.ListCount - 1
        If LeggidaFile(File.List(n)) Then Kill File.List(n)
    Next n
End Sub
Private Function LeggidaFile(ByVal Fl As String) As Boolean
    On Error GoTo Errore
 
    'Qua devi inserire la tua routine
 
    LeggidaFile = True
    Exit Function
Errore:
    msgbox err.description
End Function
 

Siccome probabilmente ancora non ti è chiaro il concetto,
te lo chiarisco ulteriormente:
 
Private Sub CmdLeggidaFile_Click()
    if dir(app.path & "\log.txt") = "log.txt" then kill app.path & 
"\log.txt"
    For n = 0 To File.ListCount - 1
        If LeggidaFile(File.List(n)) Then Kill File.List(n)
    Next n
End Sub
Private Function LeggidaFile(ByVal Fl As String) As Boolean
    On Error GoTo Errore
 
    'Qua devi inserire la tua routine
 
    LeggidaFile = True
    Exit Function
Errore:
    ff=freefile
    open app.path & "\log.txt" for append as #ff
        print #ff, err.description
    close #ff
End Function 
 

Certo queste due modifiche così complicate poteva tirarle fuori anche un 
genio informatico del tuo calibro!!!
Com'è che ti sei passato? 
 

 Com'ï¿œ che ti sei passato? 
 
Sei in pieno furore. Calmati.
 
Mi spieghi perchï¿œ te la prendi tanto? :O
 
Non continuerï¿œ a replicare a questo trhead non ha senso.
 

Ragazzi,
temo il caldo faccia brutti scherzi: fatevi una doccia fredda no!? :-)
L'80% degli ultimi thread è costituito da anatemi vari, piuttosto che da lieta convivenza.
Siete tutti valenti professionisti. Personalmente preferisco leggervi con la serenità che vi si addice.
Buona camomilla!

Lo so che non ha senso...
 
...però l'hai aperto!!!
 

E come se io avessi detto: "Andiamo al cinema!"
 
E tu avessi replicato con tono seccato: "Se ci metti un 'NOI' forse è 
meglio!!!"
 
Perchè se non lo metto il senso cambia???
 
Voglio dire... sempre al cinema andiamo!!!
 

Tiscali ha scritto:

Così hai corretto un errore logico che in neffetto poteva
essere poco influente, e ne hai inserito un altro molto
peggiore... lo sai, vero ?
 
Bye, G.

Bye, G.
 
Tipo? 
 

 Bye, G.
 
eh eh eh
rischi dello snippettamento selvaggio!!!!

 Tipo?
 
Tipo che se si verifica un errore di accesso al disco
(diritti mancanti, disco pieno, disco remoto disconnesso
o un'altra dozzina di possibilità), quello che dovrebbe
essere un controllo di errore va in loop e pianta il
programma: cerca anche lui di scrivere il log sul disco,
va in errore, e cerca di scriverlo nel log e va in
errore e... SBONK ! non esce più dal loop.
 
Te lo dico perché è una cappella che ho fatto anch'io
in un sorgente che postai qualche tempo fa, e me la
fece notare Lokar, che ancora ringrazio.
E te lo dico anche perché, lavorando come fai tu con
una listbox, cancellando i file nello stesso loop,
rischi... anzi, no: sei certo! che la situazione
nella listbox non sia più coerente con quella reale
nella directory; questo è uno dei motivi per cui la
listbox non andrebbe usata per queste cose: è più
semplice, leggero, veloce e meno rischioso usare
solo codice, con un loop di dir$(). Esempio:
 
Dim NomeDiFile As String
Dim PercorsoDeiFile As String
  PercorsoDeiFile = "C:\Prove\"
  NomeDiFile = Dir$(PercorsoDeiFile & "*.txt")
  Do While NomeDiFile <> ""
    SubOFunctionCheFaQualcosaSulFile PercorsoDeiFile & NomeDiFile
    NomeDiFile = Dir$()
  Loop
 
La scrittura dell'ErrorLog dovrebbe andare in una routine
separata, poi questa deve avere un proprio gestore
di errore, che però deve limitarsi ad un messaggio
all'utente tipo MsgBox, che non coinvolga operazioni
su disco.
 
A proposito: un'altra cosa che fece notare lo stesso
Lokar in quell'occasione è che se c'è una Open nella
routine di cui stai gestendo l'errore, e la Open è
andata a buon fine e l'errore si verifica successivamente,
nella gestione d'errore va inserita la corrispondente
Close per evitare che rimangano file "appesi", cioè
aperti e mai chiusi.
 
Bye, G.

Bye, G.
 
Ovviamente era solo un punto di partenza
 
A questo punto però si può buttare giù un'altra versione più articolata!
 
Private Sub CmdLeggidaFile_Click()
    If Dir(App.Path & "\log.txt") = "log.txt" Then Kill App.Path & 
"\log.txt"
    PercorsoDeiFile = "C:\Prove\"
    NomeDiFile = Dir$(PercorsoDeiFile & "*.txt")
    Do While NomeDiFile <> ""
        If LeggidaFile(PercorsoDeiFile & NomeDiFile) Then Kill 
PercorsoDeiFile & NomeDiFile
        NomeDiFile = Dir$()
    Loop
End Sub
Private Function LeggidaFile(ByVal Fl As String) As Boolean
    On Error GoTo Errore
 
    'Qua devi inserire la tua routine
 
    LeggidaFile = True
    Exit Function
Errore:
    LogErrori Err.Description
End Function
Private Sub LogErrori(ByVal Desc As String)
    On Error GoTo Errore
    Set fso = CreateObject("Scripting.FileSystemObject")
    If fso.FileExists(App.Path & "\log.txt") Then
        ff = FreeFile
        Open App.Path & "\log.txt" For Append As #ff
            Print #ff, Desc
        Close #ff
    End If
    Exit Sub
Errore:
    MsgBox Err.Description
    Close
End Sub
 

     If fso.FileExists(App.Path & "\log.txt") Then <<<<<-------
 >         ff = FreeFile
 >         Open App.Path & "\log.txt" For Append As #ff
 >             Print #ff, Desc
 >         Close #ff
 >     End If
 >     Exit Sub
 > Errore:
 >     MsgBox Err.Description
 >     Close
 > End Sub
 
"Mi consenta..." (cit.) Non capisco il senso di quella If.
Se non esiste già il file log, che fai: non lo scrivi mai ?
Poi tutta la If è inutile anche in un altro senso: visto
che lo apri in Append, se non esiste già viene creato,
quindi non vedo che scopo abbia controllarne l'esistenza.
 
Poi: perché farti del male creando un oggetto e chiamando
un controllo esterno come FSO anziché fare una normalissima Dir$ ?
 
If Dir$ (App.Path & "\log.txt") <> "" Then
 
Terzo punto: una Close senza parametri chiude *tutti* i file
aperti di *tutto* il programma. Non mi pare che sia il caso, no ?
 
Bye, G.

 aperti di *tutto* il programma. Non mi pare che sia il caso, no ?
EH NO CARO MIO E QUI PROPRIO TI SBAGLI
....non potrà mai darti ragione....perchè comporta ammmettere di aver 
sbagliato!!!
 
Poi dicono che faccio il filosofo...qui ci vorrebbe lo psicologo altro 
che melanzane!!!
 
 

aperti di *tutto* il programma. Non mi pare che sia il caso, no ?
 
Il programma è tutto qui, al limite ci sarà una routine che apre i files li 
elabora e li cancella.
Però se non è possibile scrivere il file di log, in ogni caso vanno chiusi 
tutti i files!!!
 
L'unica cosa che manca al limite è la creazione del file di log vuoto a 
inizio procedura!!!
Tutto qui...
 

 chiusi tutti i files!!!
 
In quel caso anche la Close ti darebbe un errore...
e sei punto e a capo in un Loop. In questo caso, se
proprio vuoi chiudere tutti i file aperti dall'interno
di una routine di gestione degli errori, dovresti come
minimo metterci una On Error resume next. Che andrebbe
anche in una normale uscita dalla routine, detto per
inciso, in caso di ritorno da una routine esterna di
gestione errori centralizzata.
 
 
 > Il programma ï¿œ tutto qui, al limite ci sarï¿œ una routine
 > che apre i files li elabora e li cancella.
 
Il problema ï¿œ proprio nel limitarsi al caso specifico.
Guarda, mi autocito; ho scritto pochi giorni fa in
un altro NG queste cose:
 
**********************
"scrivere quattro righe in croce che, in ben precise
condizioni, facciano un determinato lavoro, di solito ï¿œ
abbastanza facile. Scrivere del codice abbastanza robusto
da non piantarsi quando le condizioni al contorno cambiano
inaspettatamente, abbastanza flessibile che possa adattarsi
a necessitï¿œ un tantino diverse senza doverne riscrivere la
metï¿œ ogni volta, e fare questo senza che diventi lento
come un TIR in salita, non ï¿œ altrettanto facile.
Analisi, precisione e ancora analisi. Verifiche, controlli e
uso intensivo del "cannone a merda"... e poi di nuovo analisi,
modifiche, ricontrolli e altre cannonate.
 
Ma per fare tutto questo ci vuole soprattutto *tempo*."
**********************
 
Bye, G.

>**********************
 
Pienamente d'accordo, e mi sembra che di tempo io e te su questa cosuccia ne 
abbiamo già speso fin troppo...
 

On 28/06/2012 21:55, Paperino wrote:
zac
 
ai tempi dei tempi
se volevo sanitizzare
 
inizio roba critica
on error resume next
 
 
 
if err qualcosa then
qui qualcosa...es scrivi nella status bar...in una textbox....salva un 
record di log (comodo con un db di adesso)...scrivi nell'event log
endif
 
on error goto 0
 
oggi è più semplice
 
try
smsmsmssm
catch....
 
end try
 
Lo svantaggio è un appesantimento delle prestazioni (anche in vb6 anche 
se si nota meno)...quindi NON infarcite di try catch tutto il codice 
vb.net
!
 
PERO' la logica è sempre la solita...ed ha ragione Paperino quando 
afferma che è COSA BUONA E GIUSTA
ottimizzare...pensare....pianificare...PERDERCI TEMPO

 nota meno)...quindi NON infarcite di try catch tutto il codice 
vb.net
!
 
non condivido molto l'approccio del try/catch, o meglio è fondamentale 
infarcire il codice critico di try/catch ed è fondamentale fregarsene 
delle prestazioni della costruzione dello StackTrace (e della gestione 
dello stack in generale) perché un'eccezione deve essere una cosa 
eccezionale e non la norma per gestire il flusso applicativo.
 
Ritengo quindi sbagliato, anche perché poco performante, la logica del 
tipo: "provo a fare questa cosa se ho una exception allora faccio altro 
perché applicativamente significa che..."
Questa è logica di business e *non* deve essere gestita con le 
eccezioni (o costrutti simili) in nessun linguaggio.
 
Ergo il mio compito è scrivere tutto il codice possibile per far si che 
l'eccezione non ci sia mai e mettere in un blocco try/catch per gestire 
i soli scenari che non ho modo di gestire in altro modo (o che in 
quanto eccezionali non ha senso gestire in altro modo); è *tipicamente* 
doveroso che a seguito di un'eccezione l'applicazione semplicemente 
crashi, è troppo rischioso avere uno stato inconsistente, la gestione 
delle eccezioni serve per far crashare l'applicazione in maniera 
"gracefull" e non brutale con "Dr. Watson" che ci salta addosso :-)
 
my 2 cents ;-)
.m
 
-- 
blog @ //
milestone.topics.it
 
 
 

 Ciao,
aggiungo a quanto hai detto
un altro scenario:
 
Porca l'oca c'è da fare la presentazione del lavoro al cliente....cazzo 
ma se non funziona nulla....
e te mettici un resume next(trycatch) a raffica.....qualcosa bisogna 
fargli vedere!!!
 
Peccato poi che il cliente sia contento....alla swhouse scade "il 
progetto" del programmatore...ed i sw vada in produzione ...così!!!
 
:O) ....eh beh!