Len(Selection.Text) dépend du type de document
Le
Mersenne
C'est de nouveau moi.
J'ai donc créé un fichier de sortie en y écrivant des chaînes multilignes à
l'aide de Print.
Dans ces chaînes multilignes, j'ai mis vbCrLf (autrement dit Chr(13) &
Chr(10) ) comme marque de fin de ligne.
La macro donne à ce fichier un nom qui finit par .txt et je l'ouvre comme
fichier de pur texte.
Si je sélectionne une marque de fin de ligne et que je fais afficher
Len(Selection.Text), le message est 2.
Cela provient sans doute du fait que ce sont deux octets qui marquent la fin
de la ligne.
Si maintenant, j' "enregistre sous" comme document Word, que je ferme le
document ainsi obtenu, puis ouvre de nouveau le document Word et que je fais
afficher Len(Selection.Text), toujours avec pour partie sélectionnée une
marque de fin de ligne, j'obtiens 1.
(A toutes fins utiles : je me sers du Word 2002.)
A mon avis, le résultat "2" est incorrect, car Selection.Text est, disons,
une fonction d'écran, or à l'écran, la marque de fin de ligne ne compte
visiblement que comme un caractère : on l'efface tout entière par une seule
utilisation de la touche de suppression, on la franchit en une fois par une
touche fléchée
Toujours est-il qu'une macro que nous avons toujours appliquée jusqu'ici à
des documents Word est sabotée si on l'applique à un txt (je l'ai vérifié).
J'aurais donc tendance à penser qu'il vaut mieux ne pas utiliser deux octets
comme marque de fin de ligne, mais un seul. Pour la compatibilité avec Unix,
je choisirais Chr(10) mais les macros faites sur base de documents Word
supposent plutôt Chr(13).
Qu'en pense-ton ? Merci d'avance pour les réponses.
Mersenne.
J'ai donc créé un fichier de sortie en y écrivant des chaînes multilignes à
l'aide de Print.
Dans ces chaînes multilignes, j'ai mis vbCrLf (autrement dit Chr(13) &
Chr(10) ) comme marque de fin de ligne.
La macro donne à ce fichier un nom qui finit par .txt et je l'ouvre comme
fichier de pur texte.
Si je sélectionne une marque de fin de ligne et que je fais afficher
Len(Selection.Text), le message est 2.
Cela provient sans doute du fait que ce sont deux octets qui marquent la fin
de la ligne.
Si maintenant, j' "enregistre sous" comme document Word, que je ferme le
document ainsi obtenu, puis ouvre de nouveau le document Word et que je fais
afficher Len(Selection.Text), toujours avec pour partie sélectionnée une
marque de fin de ligne, j'obtiens 1.
(A toutes fins utiles : je me sers du Word 2002.)
A mon avis, le résultat "2" est incorrect, car Selection.Text est, disons,
une fonction d'écran, or à l'écran, la marque de fin de ligne ne compte
visiblement que comme un caractère : on l'efface tout entière par une seule
utilisation de la touche de suppression, on la franchit en une fois par une
touche fléchée
Toujours est-il qu'une macro que nous avons toujours appliquée jusqu'ici à
des documents Word est sabotée si on l'applique à un txt (je l'ai vérifié).
J'aurais donc tendance à penser qu'il vaut mieux ne pas utiliser deux octets
comme marque de fin de ligne, mais un seul. Pour la compatibilité avec Unix,
je choisirais Chr(10) mais les macros faites sur base de documents Word
supposent plutôt Chr(13).
Qu'en pense-ton ? Merci d'avance pour les réponses.
Mersenne.
Poser une question
Sans doute parce que Word a traduit ces deux caratères par une fin de
paragraphe (13) lors de l'enregistrement, mais avait gardé les deux
avant.
A noter que la fin de ligne dans word c'est 11.
ce n'est pas si simple, un "caractère" ne tient pas forcément sur un
"octet" l'UTF-8 permet jusqu'à 6 octets pour un caractère.
Quand on est en txt c'est un pour un.
Qu'il faut essayer de rester au plus simple.
la question de départ concernait des fichiers en texte, il vaut mieux
rester dans le périmètre tant qu'on peut, surtout si l'ordre de lecture
permet lui-même de traiter les variantes.
Pour voir les valeurs des codes dans word, voir l'excellente macro de
Guy qui doit être en télé-chargement dans la faq.
--
A+
"Geo" a écrit
Soit. Le "passage à la ligne forcé", dans Word, c'est 11.
Parlons de fin de paragraphe si vous voulez, mais ça me gêne un peu quand il
s'agit de txt, car un paragraphe, c'est déjà du formatage.
A mon avis, il faut distinguer entre ce qui se passe "sous le capot" et ce
qui se passe à l'écran.
Peu importe ce qu'est un caractère sous le capot, on se comprend quand on
parle d'un caractère à l'écran.
Exemple : si vous demandez la longueur d'une chaîne sélectionnée à l'écran
et que, plus tard, vous mettez le curseur juste à gauche de la zone qui
était sélectionnée et que vous faites avancer le "point d'insertion"
("curseur") autant de fois qu'il y a d'unités dans le nombre que vous aviez
obtenu comme longueur, vous devriez arriver juste à droite de la zone qui
était sélectionnée (à condition, bien sûr, que le document n'ait pas été
modifié dans cette zone).
Sinon, il y a quelque chose d'incohérent dans, disons, l'interface. Et cette
incohérence a bien lieu dans les txt : si le curseur est jute à gauche d'une
marque de paragraphe, Selection.MoveRight Count:=2 ne se contente pas de
franchir la marque de paragraphe, elle franchit encore le "caractère"
(comment dire autrement ?) qui se trouve après..
J'ai fait un nouveau sujet, parce qu'il me semble qu'il s'agit d'un autre
problème : une incohérence dans les fonctions d'interface écran quand on
traite des fichiers txt.
Que des macros aient le comportement attendu quand le document affiché est
un doc et ne l'aient pas quand c'est un txt, cela me semble montrer qu'il y
a là un bug.
Mersenne.
'Mersenne' nous a écrit ...
hihihi faut pas voir des bugs là où il n'y en a pas !
Vous appliquez à un document Word les principes logiques
d'un document TXT alors que c'est deux choses différentes !
Lors de votre test quand vous aviez Len(Selection.Text) qui donnait 2
mais vous avez aussi Selection.Characters.Count qui donne 1 !!!
Dans votre logique à vous c'est totalement incohérent, non ?
Pourtant si vous regardez la structure d'un document Word
c'est parfaitement possible. Et sans bug :-p
Anacoluthe
« Ya comme un bug »
- François COINTE
Pouvez-vous m'expliquer ce qui, dans la documentation, permet de prévoir que
Len(Selection.Text) et Selection.Characters.Count ne renvoient pas la même
valeur ?
Merci d'avance.
Mersenne.
Complément à ma précédente réponse.
Enregistrez un fichier comme txt avec CR/LF comme marque de fin de ligne,
fermez-le et affichez-le (comme txt).
Si vous sélectionnez une marque de fin de ligne et demandez
Len(Selection.Text), vous obtenez 2.
Tapez maintenant Enter, sélectionnez la marque de fin de ligne que cela a
produite et demandez Len(Selection.Text) : vous obtenez 1.
Je serais vraiment curieux de connaître la logique et l'utilité de tout
cela.
A mon avis, il y a un mélange de l'interface et de l'arrière-cuisine.
Mersenne.