Newsgroup: it.comp.lang.visual-basic
Titolo: URLDownloadToFile

Ho un file di log  che viene scritto tramite l'api WritePrivateProfile String, che poi viene inviato a intervalli 
regolari in uno spazio ftp. Da qui viene prelevato da un un altro programma tramite l'api URLDownloadToFile per essere 
ulteriormente processato.
 
Facendo un controllo mi sono accorto che il file quando viene scaricato perde tutti i ritorni a capo e rimane su 
un'unica riga. Però se apro il file con FTP un attimo prima che venga scaricato i ritorni a capo ci sono.
 
La stranezza non incide sulla funzionalità delle cose, ma solo per capire, perchè si perde il ritorno a capo nel 
download e come potrei fare per mantenerlo? Grazie e buon anno a tutti
 
-- 
Greg

Dopo dura riflessione, Greg ha scritto :

Succede se hai la connessione ftp con un serfver *nix in modalità testo
e passi un file txt, il sender ti tratterà come un terminale e (vado a
memoria) cambierà i CR in LF; impostando la connessione come  binary
dovresti risolvere, oppure cambia l'estensione del file in modo che NON
sia .txt, in questo modo il sender non dovrebbe pasticciarlo.
 
come estrema soluzione puoi scansionare il file e cambiare tutti i
caratteri LF in CRLF.
 
(codice a braccio)
 
open "filericevuto.txt" for input as #1
open "fileconvertito.txt" for output as #2
dim stringa as string
 do until eof(1)
   input #1, stringa
   replace(stringa,VBLF,VBCRLF)
   print #2, stringa
loop
close #2
close #1

 caratteri LF in CRLF.
 
 'dwType = FTP_TRANSFER_TYPE_ASCII
  dwType = FTP_TRANSFER_TYPE_BINARY
 
Ho cambiato la connessione come suggerito ma senza ritultati.
E allora, siccome il file lo apro col programma di default (Notepad) ho provato a vedere come lo visualizza Notepad++ e 
ho scoperto che lo visualizza bene, si vedono anche i simboli di ritorno a capo. Ho provato allora con altri programma 
presenti sul pc, Word e WordPad, e anche questi visualizzano il file correttamente con i ritorni a capo. Solo Notepad 
lo vede in altro modo.
Strano, no?
 
-- 
Greg


Gli editor complessi intervengono nel rendering dei dati; le prove 
empiriche servono a poco.
 
Dovresti aprire il file di testo con un editor esadecimale e vedere se 
le linee finiscono con 0D o con 0D0A. In tutti i casi utilizzando la 
WritePrivateProfileString non puoi farci nulla.
 
Piuttosto... Perché la WritePrivateProfileString. Una open > write > 
close non bastava?
 
 
-- 
gio

 Ho cambiato la connessione come suggerito ma senza ritultati.
 
anche quando il file viene scritto ?

Il 10/01/19 16:00:00 Franz_aRTiglio ha scritto:

si
 
-- 
Greg

 Piuttosto... Perché la WritePrivateProfileString. Una open > write > close non bastava?
 
Ai tempi per scrivere un file di configurazione con delle chiavi prestabilite era comodo usare quell'api
 
-- 
Greg


Ho appena provato la WritePrivateProfileString e le righe sono terminate 
con 0D 0A (usata millemila volte per file ini e simili).
 
Non so cosa dire se non che non credo che il problema sia quella stupida 
API.
 
 
Option Explicit
 
Private Declare Function WritePrivateProfileString Lib "kernel32" Alias 
"WritePrivateProfileStringA" (ByVal lpApplicationName As String, ByVal 
lpKeyName As Any, ByVal lpString As Any, ByVal lpFileName As String) As Long
 
Private peRC As String
 
Private Sub Form_Load()
 
     peRC = App.Path
     If Right(peRC, 1) <> "\" Then peRC = peRC & "\"
 
     Dim x As Long
 
     '-------------
     x = WritePrivateProfileString("TEST1", "Test Param1", "pippo 
pippo", peRC & "test.ini")
     x = WritePrivateProfileString("TEST1", "Test Param2", "peppo 
peppo", peRC & "test.ini")
     x = WritePrivateProfileString("TEST2", "Test Param1", "pappo 
pappo", peRC & "test.ini")
 
     MsgBox "done!"
     Unload Me
 
End Sub
 
 
 
 
 
-- 
gio

 Non so cosa dire se non che non credo che il problema sia quella stupida API.
 
io continuo a sospettre che sia l'host a pasticciare il file, la prova
che farei a 'sto punto e' di scrivere IN LOCALE un file con estensione
"non di testo" in modo che quando lo si trasferisce non venga
pasticciato dall'host, inoltre se fosse l'host a cambiare i CRLF in LF
si dovrebbe adderittura notare un decremento di dimensione.

Il 11/01/19 18:09:34 Franz_aRTiglio ha scritto:

E lo credo anche io
Ho fatto questa altra prova:
creo il file e lo apro con l'editor esadecimale: a fine riga contiene OD OA
Lo carico e lo scarico (via codice) e lo ricontrollo di nuovo con l'editor: contiene solo gli 0A.
Gli 0D sono spariti
 
-- 
Greg

Greg scriveva il 11/01/2019 :

hai provato in modalità binary usando un'estensione tipo XXX ZZZ o
qualunque altra cvhe non lasci intendere che sia un file di testo ?

 qualunque altra cvhe non lasci intendere che sia un file di testo ?
 
Aspetta un attimo che provo....
 
si, anche con estensione xxx spariscono gli OD
 
-- 
Greg


 
:/

Il 12/01/19 20:39:06 Franz_aRTiglio ha scritto:

:) :)
Ciao, Buon Anno :)
 
-- 
Greg

Il 12/01/19 20:39, Franz_aRTiglio ha scritto:

Ne posso aggiungere io un'altra?
Lo nascondi dentro un file ZIP.
Ciao
 
-- 
Gulp®
--
"Partimque figuras retulit antiquas, partim nova monstra creavit."
(La Metamorfosi - Ovidio)

 Ciao
 
Grazie ma non occorre, tutti gli editor lo leggono bene, tranne Notepad. Esa solo una curiosità
 
-- 
Greg