Dans mon dernier message, j'ai indiqué l'inconvénient d'avoir affaire à un
fichier txt où la marque de paragraphe compte pour deux caractères.
J'ai donc essayé de former des chaînes multilignes où un seul caractère
marque la fin d'une ligne (paragraphe si on préfère).
Avec Chr(13), le résultat est mauvais : si on applique Print à une chaîne
multiligne où la fin de ligne est marquée uniquement par Chr(13) et qu'on
ouvre le fichier comme txt, le Chr(13) ne provoque pas de passage à la
ligne.
Avec Chr(10) (non accompagné d'un Chr(13), le résultat est bon : il y a un
passage à la ligne à l'écran, et si on sélectionne l'unique caractère en
question, Len(Selection.Text) renvoie 1, comme dans un document Word, et
conformément à l'attente.
Malheureusement, quand on demande à Print d'écrire une chaîne multiligne,
elle insère cette chaîne (correctement), mais lui ajoute encore une marque
de fin de ligne qui est du type vbCrLf (autrement dit 13/10) et qui donne 2
quand on lui applique Len(Selection.Text).
On obtient donc un fichier hybride, qui provoquera de nouveau un bug si on
veut lui appliquer la macro qui utilise Len(Selection.Text) en s'attendant à
ce que les choses se passent comme avec un document Word.
On pensera peut-être à convertir le fichier de txt vers doc, mais bon, on
préférerait l'éviter.
Il n'y aurait pas de problème si Print n'ajoutait pas d'office Chr(13) &
Chr(10).
Ma question est donc : peut-on l'éviter ? Y a-t-il une autre fonction que
Print qui écrit exactement ce qu'on lui demande d'écrire ? (Write est encore
pire, je crois : elle ajoute des guillemets.)
