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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Geo
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.
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.
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...
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'en pense-ton ?
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+
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.
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.
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...
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'en pense-ton ?
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.
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.
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.
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...
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'en pense-ton ?
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+
Mersenne
Merci de répondre.
"Geo" a écrit
A noter que la fin de ligne dans word c'est 11.
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, 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...
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.
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..
Qu'en pense-ton ?
Geo a répondu :
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.
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.
Merci de répondre.
"Geo" a écrit
A noter que la fin de ligne dans word c'est 11.
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, 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...
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.
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..
Qu'en pense-ton ?
Geo a répondu :
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.
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.
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, 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...
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.
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..
Qu'en pense-ton ?
Geo a répondu :
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.
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.
Anacoluthe
Bonjour !
'Mersenne' nous a écrit ...
cela me semble montrer qu'il y a là un bug.
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
Bonjour !
'Mersenne' nous a écrit ...
cela me semble montrer qu'il y a là un bug.
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
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
Mersenne
"Anacoluthe" 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
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.
"Anacoluthe" 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
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 ?
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
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.
Mersenne
"Anacoluthe" a écrit
Bonjour !
'Mersenne' nous a écrit ...
cela me semble montrer qu'il y a là un bug.
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
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.
"Anacoluthe" a écrit
Bonjour !
'Mersenne' nous a écrit ...
cela me semble montrer qu'il y a là un bug.
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
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.
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
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.
Clément Marcotte
Quand on "imprime" un fichier texte avec Print #1, la fin de ligne est ajoutée automatiquement. Donc, quand le programme(ur) en ajoute un autre, c'est juste normal qu'il y en ait 2. Cela donne donc un PEBKAC.
"Mersenne" a écrit dans le message de news:
"Anacoluthe" a écrit
Bonjour !
'Mersenne' nous a écrit ...
cela me semble montrer qu'il y a là un bug.
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
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.
Quand on "imprime" un fichier texte avec Print #1, la fin de ligne est
ajoutée automatiquement. Donc, quand le programme(ur) en ajoute un autre,
c'est juste normal qu'il y en ait 2. Cela donne donc un PEBKAC.
"Mersenne" <fa602502@skynet.be> a écrit dans le message de news:
eNLnXgxOGHA.3196@TK2MSFTNGP09.phx.gbl...
"Anacoluthe" a écrit
Bonjour !
'Mersenne' nous a écrit ...
cela me semble montrer qu'il y a là un bug.
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
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.
Quand on "imprime" un fichier texte avec Print #1, la fin de ligne est ajoutée automatiquement. Donc, quand le programme(ur) en ajoute un autre, c'est juste normal qu'il y en ait 2. Cela donne donc un PEBKAC.
"Mersenne" a écrit dans le message de news:
"Anacoluthe" a écrit
Bonjour !
'Mersenne' nous a écrit ...
cela me semble montrer qu'il y a là un bug.
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
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.
Clément Marcotte
Ça c'est maintenant moins sur, mais bon...
"Clément Marcotte" a écrit dans le message de news:
Quand on "imprime" un fichier texte avec Print #1, la fin de ligne est ajoutée automatiquement. Donc, quand le programme(ur) en ajoute un autre, c'est juste normal qu'il y en ait 2. Cela donne donc un PEBKAC.
"Mersenne" a écrit dans le message de news:
"Anacoluthe" a écrit
Bonjour !
'Mersenne' nous a écrit ...
cela me semble montrer qu'il y a là un bug.
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
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.
Ça c'est maintenant moins sur, mais bon...
"Clément Marcotte" <clement.marcotte@sympatico.ca> a écrit dans le message
de news: uHLYAWyOGHA.3360@TK2MSFTNGP09.phx.gbl...
Quand on "imprime" un fichier texte avec Print #1, la fin de ligne est
ajoutée automatiquement. Donc, quand le programme(ur) en ajoute un autre,
c'est juste normal qu'il y en ait 2. Cela donne donc un PEBKAC.
"Mersenne" <fa602502@skynet.be> a écrit dans le message de news:
eNLnXgxOGHA.3196@TK2MSFTNGP09.phx.gbl...
"Anacoluthe" a écrit
Bonjour !
'Mersenne' nous a écrit ...
cela me semble montrer qu'il y a là un bug.
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
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.
"Clément Marcotte" a écrit dans le message de news:
Quand on "imprime" un fichier texte avec Print #1, la fin de ligne est ajoutée automatiquement. Donc, quand le programme(ur) en ajoute un autre, c'est juste normal qu'il y en ait 2. Cela donne donc un PEBKAC.
"Mersenne" a écrit dans le message de news:
"Anacoluthe" a écrit
Bonjour !
'Mersenne' nous a écrit ...
cela me semble montrer qu'il y a là un bug.
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
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.
