Newsgroup: it.comp.programmare.win32
Titolo: Problema con input da file

Sto cercando di gestire il messaggio WM_INITDIALOG di una finestra. Al suo
interno carico delle informazioni da un file esterno all'applicazione e le
dovrei inserire all'interno di una listbox. Questo è quello che ho scritto:
case WM_INITDIALOG:
{
  char sItem1[30];
  char sItem2[30];
  char sItem3[30];
  char sItem[60];
  ifstream file("list.txt", ios::in);
  while(!file.eof())
  {
    // Getting the string from the file
    file >> sItem1 >> sItem2 >> sItem3;
    strcpy(sItem, sItem1);
    strcat(sItem, sItem2);
    strcat(sItem, sItem3);
    // Adding the string to the listbox
    SendMessage(GetDlgItem(hwnd, IDC_LISTBOX_COLORS),
                          LB_ADDSTRING, 0, (LPARAM)sItem);
  }
  file.close();
  break;
}
Il tutto funziona perfettamente se il file esiste e contiene informazioni,
ma chiude il programma se il file non esiste o è vuoto. Ho provato a fare un
debug ed ho notato che anche se il file non esiste il programma entra
all'interno del ciclo while. Poi andando avanti da un messaggio con scritto
"unhandled exception in nomefile.exe..." e poi da degli indirizzi di
memoria. Secondo voi cosa c'è di sbagliato? Oltre tutto se c'è una voce
all'interno del file allora lui invece che scriverla una volta la trova due
volte.
Grazie e ciao a tutto l'ng.
Luca

 Luca
Prego, alla prossima

 Prego, alla prossima
Grazie.
Luca

 ifstream file("list.txt", ios::in);
Prova a mettere il tuo codice in un blocco try...catch. Forse l'assenza
del file genera un'eccezione e se non la catturi il compilatore la
considera un errore "critico" e fa terminare il programma.
Non ti so dire di piu`, non uso la STL del C++.
--
Lorenzo

 Non ti so dire di piu`, non uso la STL del C++.
Non conoscevo cosa fosse questa struttura try...catch, me la sono andata a
studiare. Poi l'ho applicata ma pare che nessuna eccezione venga generata.
Facendo un debug ed andando avanti riga per riga pare che entri nel try,
esca dal try e non entri all'interno del catch. Il problema rimane il fatto
che lui trova sempre una riga in piů, una riga che non c'č. Ora funziona
tutto, il programma non si chiude (si chiudeva per via dell'array troppo
piccolo), ma trova sempre una riga in piů. Se c'č una riga nel file lui la
trova e poi ne trova una con tutte delle i maiuscole. Se non c'č niente
trova solo quelle I, se ci sono 10 voci all'interno lui le trova e poi mette
quelle I. Come mai secondo voi?
Grazie.
Luca

 Grazie.
Le I (scommetto che sono accentate) sono (sospetto) una lettura dopo l'EOF
del file.
infatti le I (accentate) corrispondono al -52 (di valore), che viene messo
quando non c'e' dati, in un vettore di char (lo fa anche la recv() per le
socket, quando non e' bloccante).
Evidentemente stai debordando con una variabile di indicizzazione della
lettura.
Non so se dipende solo dall'ottimizzazione del compilatore, ma queste I
accentate appaiono normalmente sotto un programma compilato in versione
"debug".
Un programma in release, invece, ho visto che si ritrova diversi problemi,
che ti possono incasinare parecchio...
Non so se poi e' una regola che sia cosi'. io l'ho osservata su un programma
che stavo facendo, non e' detto che  sia esattamente lo stesso caso.
ciau!
Joshi

 "debug".
-52 = 0xCC = INT 3!
La MS si deve essere chiesta: ehi raga, mettiamo uno 0, un 1, un -1 (0xFF)
oppure qualcos'altro???
E il genio parlò (no...Bill Gate in quel momento era al cesso): "mettiamoci
degli INT 3 così se sborda anche il codice lo trappiamo subito!"
Kiuhnm

 che stavo facendo, non e' detto che  sia esattamente lo stesso caso.
Mi era successa la stessa cosa programmando col Borland 5.02. Poi perň in un
altro programma sempre col Borland non era successo, pensai cosě di aver
commesso un errore nel programma precedente, invece evidentemente no. Cmq jo
risolto, in un modo o nell'altro. Non so neanche io quale sia la cosa che ha
risolto, penso la gestione del carattere \n. Era quello penso che creava
problemi.
Vabbč, grazie cmq a tutti.
Luca