Newsgroup: it.comp.lang.visual-basic
Titolo: [BUG] Line Input

Ecco una bella chicca!
Ho notato che Line Input, in presenza di stringhe contenenti caratteri NULL
(chr$(0)) ha un comportamento anomalo (almeno nell'IDE). Infatti, alcune
volte questi caratteri vengono convertiti in spazi (chr$(32)), altre volte
vengono eliminati "accorciando" la stringa. Qualcuno ha avuto esperienze
simili ?
Ciao
Gian Michele Bertoni
--
Home Page: 
http://space.tin.it/computer/gbertoni

simili ?
E' sconsigliato leggere dei caratteri non testuali in modalità sequenziale a
causa della traduzione dei caratteri. Usa la modalità binaria con Put e Get.
Ciao Bruno

causa della traduzione dei caratteri. Usa la modalità binaria con Put e
Get.
Ti ringrazio per l'osservazione, ma, tuttavia, vorrei ribadire che il
comportamento apparentemente non deterministico della Line Input assomiglia
piu' a un malfunzionamento che a un limite della funzione. Infatti la
traduzione a volte avviene, a volte no.
E' ovvio che la soluzione, in casi analoghi, sta nel non usare Line Input.
Tuttavia, occorre definire cosa e' un file testuale e cosa non lo e': nello
specifico, avevo a che fare con un file composto interamente dai caratteri
nel range 0-127 (quindi puro ASCII). Il Notepad, p.e. apre il file e
sostituisce SEMPRE i caratteri NUL con spazi.
Potremmo quindi dire (ma mi riservo di fare prove esaustive in questo senso)
che Line Input funziona con i caratteri nel range 32-127 e con i caratteri
di controllo 10 e 13.
Infine, ho controllato su MSDN e, mi sembra, non vi e' cenno di limitazioni
o comportamenti di questo tipo.
Auguri
Gian Michele Bertoni
--
Home Page: 
http://space.tin.it/computer/gbertoni/

traduzione a volte avviene, a volte no.
Ho fatto un po di prove (print per scrivere e LineInput per leggere) ed il
risultato è stato sempre lo stesso, ossia chr$(0) non viene mai considerato.
Nel frattempo mi sono accorto che se inserisco il carattere chr$(26)
all'inizio della riga quando rileggo il tutto con LineInput raggiungo
immediatamente la fine del file, eppure i caratteri sono scritti
correttamente (ho verificato leggendolo in modalità binaria).
Conclusione:
In realtà raggiungo la fine del file quando controllo la condizione until
not eof(hFile), quindi Line Input è innocente, e sembrerebbe che il
comportamento anomalo è da rinvenirsi nella combinazione apertura
sequenziale ed eof.
Per scrupolo ho provato ad eseguire le stesso cidice anche con il VBA di
Word e il vomportamento è stato il medesimo.
A questo punto mi domando?
Anche ad altri succede lo stesso?
Come *lavora* effettivamente eof?
Se qualcuno dispone ancora di Win3.* potrebbe effettuare delle prove per
vedere se tale anomalo comportamento dipende dalla conversione UNICODE ->
ANSI ->UNICODE?
Io uso VB5+SP3 (inglese)+W98
Ciao Bruno

sequenziale ed eof.
Di questo posso darti una conferma indiretta: nella libreria standard del C
quando s'invoca la funzione fopen in modo testo, essa per prima cosa
verifica la presenza del carattere di fine file (Ctrl-Z o Chr$(26)). Anche
se non e' espresso chiaramente, quindi, l'apertura del file in questa
modalita' provoca una lettura anticipata almeno di una parte del contenuto
del file stesso permettendo il settaggio, eventualmente, della condizione di
EOF. La conversione ANSI-UNICODE non dovrebbe essere influente.
Mi sembra ci sia spazio per scrivere una classettina CStringIO per superare
questi limiti (IO binario, ma con traduzione -e non eliminazione- dei
caratteri di controllo).
Ciao
