Tout d'abord désolé pour les âneries et les autres conneries que j'ai dites
dans mes réponses a Mersemme, un peu plus/bas.
J'ai fini par faire ce que j'aurais de faire plus tôt.
J'ai réécrit mes macros de test, en faisant attention de mettre le même
nombre de caractères pour chaque ligne à l'écriture du fichier, et récupérer
le nombre de caracteres par ligne, à la lecture du fichier.
Sub LeBeauFichierTexte()
Dim ligne As String
Open "c:\LeBeauFichierTexte.txt" For Output As 1
Print #1, "Cette ligne n'a de saut de ligne ajouté par le programmeur"
Print #1, "Cette ligne a un saut de ligne ajouté avec vbnewline " &
vbNewLine
Print #1, "Cette ligne a un saut de ligne ajouté avec vbcrlf " &
vbCrLf
Print #1, "Cette ligne a un saut de ligne ajouté avec vbcr " &
vbCr
Print #1, "Cette ligne a un saut de ligne ajouté avec vblf " &
vbLf
print #1, "Voici une ligne avec vblf" & vblf & "au milieu"
close
lirelebeaufichiertexte
End Sub
Sub lirelebeaufichiertexte()
Dim ligne As String
Open "c:\LeBeauFichierTexte.txt" For Input As 1
Do While Not EOF(1)
Line Input #1, ligne
ligne = ligne & " " & Len(ligne)
MsgBox ligne
Loop
Close
End Sub
On voit, durant le test (avec Windows) que vbnewline, (ASCII 10 + ASCII 13
==> Windows, ASCII 10 seulement Mac) , vbcrlf et vbcr retournent tous les
trois une ligne de 58 caractères de VBA, suivies d'une ligne vide.
Alors que vblf (ASCII 10), retourne une ligne de 59 caractères VBA sans
ligne vide supplémentaire.
Si on ajoute un vblf entre deux chaînes de caractères, la ligne est lue et
affichée sur 2 lignes, mais elle a une seule ligne dans le fichier ouvert
dans le bloc-notes
Et puis, quand on fait Fichier - Ouvrir - lebeaufichiertexte.txt dans Word, la dernière ligne est affichée sur deux lignes.
"Clément Marcotte" a écrit dans le message de news:
Bonjour,
Tout d'abord désolé pour les âneries et les autres conneries que j'ai dites dans mes réponses a Mersemme, un peu plus/bas.
J'ai fini par faire ce que j'aurais de faire plus tôt.
J'ai réécrit mes macros de test, en faisant attention de mettre le même nombre de caractères pour chaque ligne à l'écriture du fichier, et récupérer le nombre de caracteres par ligne, à la lecture du fichier.
Sub LeBeauFichierTexte() Dim ligne As String Open "c:LeBeauFichierTexte.txt" For Output As 1 Print #1, "Cette ligne n'a de saut de ligne ajouté par le programmeur" Print #1, "Cette ligne a un saut de ligne ajouté avec vbnewline " & vbNewLine Print #1, "Cette ligne a un saut de ligne ajouté avec vbcrlf " & vbCrLf Print #1, "Cette ligne a un saut de ligne ajouté avec vbcr " & vbCr Print #1, "Cette ligne a un saut de ligne ajouté avec vblf " & vbLf print #1, "Voici une ligne avec vblf" & vblf & "au milieu" close lirelebeaufichiertexte End Sub
Sub lirelebeaufichiertexte() Dim ligne As String Open "c:LeBeauFichierTexte.txt" For Input As 1 Do While Not EOF(1) Line Input #1, ligne ligne = ligne & " " & Len(ligne) MsgBox ligne Loop Close End Sub
On voit, durant le test (avec Windows) que vbnewline, (ASCII 10 + ASCII 13 ==> Windows, ASCII 10 seulement Mac) , vbcrlf et vbcr retournent tous les trois une ligne de 58 caractères de VBA, suivies d'une ligne vide. Alors que vblf (ASCII 10), retourne une ligne de 59 caractères VBA sans ligne vide supplémentaire. Si on ajoute un vblf entre deux chaînes de caractères, la ligne est lue et affichée sur 2 lignes, mais elle a une seule ligne dans le fichier ouvert dans le bloc-notes
Et puis, quand on fait Fichier - Ouvrir - lebeaufichiertexte.txt dans Word,
la dernière ligne est affichée sur deux lignes.
"Clément Marcotte" <clement.marcotte@sympatico.ca> a écrit dans le message
de news: OiuZ4M2OGHA.3100@TK2MSFTNGP11.phx.gbl...
Bonjour,
Tout d'abord désolé pour les âneries et les autres conneries que j'ai
dites
dans mes réponses a Mersemme, un peu plus/bas.
J'ai fini par faire ce que j'aurais de faire plus tôt.
J'ai réécrit mes macros de test, en faisant attention de mettre le même
nombre de caractères pour chaque ligne à l'écriture du fichier, et
récupérer
le nombre de caracteres par ligne, à la lecture du fichier.
Sub LeBeauFichierTexte()
Dim ligne As String
Open "c:LeBeauFichierTexte.txt" For Output As 1
Print #1, "Cette ligne n'a de saut de ligne ajouté par le programmeur"
Print #1, "Cette ligne a un saut de ligne ajouté avec vbnewline " &
vbNewLine
Print #1, "Cette ligne a un saut de ligne ajouté avec vbcrlf " &
vbCrLf
Print #1, "Cette ligne a un saut de ligne ajouté avec vbcr " &
vbCr
Print #1, "Cette ligne a un saut de ligne ajouté avec vblf " &
vbLf
print #1, "Voici une ligne avec vblf" & vblf & "au milieu"
close
lirelebeaufichiertexte
End Sub
Sub lirelebeaufichiertexte()
Dim ligne As String
Open "c:LeBeauFichierTexte.txt" For Input As 1
Do While Not EOF(1)
Line Input #1, ligne
ligne = ligne & " " & Len(ligne)
MsgBox ligne
Loop
Close
End Sub
On voit, durant le test (avec Windows) que vbnewline, (ASCII 10 + ASCII
13
==> Windows, ASCII 10 seulement Mac) , vbcrlf et vbcr retournent tous les
trois une ligne de 58 caractères de VBA, suivies d'une ligne vide.
Alors que vblf (ASCII 10), retourne une ligne de 59 caractères VBA sans
ligne vide supplémentaire.
Si on ajoute un vblf entre deux chaînes de caractères, la ligne est lue et
affichée sur 2 lignes, mais elle a une seule ligne dans le fichier ouvert
dans le bloc-notes
Et puis, quand on fait Fichier - Ouvrir - lebeaufichiertexte.txt dans Word, la dernière ligne est affichée sur deux lignes.
"Clément Marcotte" a écrit dans le message de news:
Bonjour,
Tout d'abord désolé pour les âneries et les autres conneries que j'ai dites dans mes réponses a Mersemme, un peu plus/bas.
J'ai fini par faire ce que j'aurais de faire plus tôt.
J'ai réécrit mes macros de test, en faisant attention de mettre le même nombre de caractères pour chaque ligne à l'écriture du fichier, et récupérer le nombre de caracteres par ligne, à la lecture du fichier.
Sub LeBeauFichierTexte() Dim ligne As String Open "c:LeBeauFichierTexte.txt" For Output As 1 Print #1, "Cette ligne n'a de saut de ligne ajouté par le programmeur" Print #1, "Cette ligne a un saut de ligne ajouté avec vbnewline " & vbNewLine Print #1, "Cette ligne a un saut de ligne ajouté avec vbcrlf " & vbCrLf Print #1, "Cette ligne a un saut de ligne ajouté avec vbcr " & vbCr Print #1, "Cette ligne a un saut de ligne ajouté avec vblf " & vbLf print #1, "Voici une ligne avec vblf" & vblf & "au milieu" close lirelebeaufichiertexte End Sub
Sub lirelebeaufichiertexte() Dim ligne As String Open "c:LeBeauFichierTexte.txt" For Input As 1 Do While Not EOF(1) Line Input #1, ligne ligne = ligne & " " & Len(ligne) MsgBox ligne Loop Close End Sub
On voit, durant le test (avec Windows) que vbnewline, (ASCII 10 + ASCII 13 ==> Windows, ASCII 10 seulement Mac) , vbcrlf et vbcr retournent tous les trois une ligne de 58 caractères de VBA, suivies d'une ligne vide. Alors que vblf (ASCII 10), retourne une ligne de 59 caractères VBA sans ligne vide supplémentaire. Si on ajoute un vblf entre deux chaînes de caractères, la ligne est lue et affichée sur 2 lignes, mais elle a une seule ligne dans le fichier ouvert dans le bloc-notes
Mersenne
Clément, c'est gentil de vous excuser mais je n'ai peut-être pas été tout à fait clair.
Pour mettre les points sur les i : enregistrez comme fichier txt, avec CR/LF pour les marques de "paragraphe" un document qui comporte plusieurs "paragraphes". Fermez-le et rouvrez-le. Faites une sélection qui recouvre en tout et pour tout une des marques de "paragraphe". (Evitons le dernier "caractère" du document, pour ne pas compliquer les choses.) Si vous faites afficher Len(Selection.Text), vous obtenez 2. Placez maintenant le curseur n'importe où et appuyez sur la touche "entrée". Sélectionnez la marque de paragraphe que vous avez ainsi créée, et elle seule. L'affichage de Len(Selection.Text) donne maintenant 1.
Contrairement à ce que hennissait ("hihihi") Anacoluthe, l'incohérence a maintenant lieu dans un même document, et non entre un txt et un doc.
Cela veut dire que si l'utilisateur exécute plusieurs fois la macro en modifiant le texte entre deux exécutions, on ne peut pas se fier à Len(Selection.Text).
Comme la documentation ne semble pas avertir de cette particularité de la propriété Text, et que je ne vois vraiment pas son utilité mais bien ses inconvénients, j'estime qu'il y a là un bug.
Si ça dépendait de moi, il y aurait une propriété Text10 de l'objet Selection et des objets Range qui lirait une marque de paragraphe comme un unique Chr(10), aussi bien dans un document Word que dans un txt. Il y aurait des propriétés Text13, Text1013 et Text1310 analogues. Ainsi, pour tester si un "caractère" (à l'écran) sélectionné est une marque de paragraphe, on pourrait dire "If Selection.Text10 = Chr(10) "; on pourrait aussi mettre "If Selection.Text13 = Chr(13)", ce qui aurait exactement le même effet. Quant aux programmeurs qui ont l'utilité des mystérieuses propriétés de Text, ils pourraient continuer à s'en servir.
Mersenne.
Clément, c'est gentil de vous excuser mais je n'ai peut-être pas été tout à
fait clair.
Pour mettre les points sur les i : enregistrez comme fichier txt, avec CR/LF
pour les marques de "paragraphe" un document qui comporte plusieurs
"paragraphes".
Fermez-le et rouvrez-le.
Faites une sélection qui recouvre en tout et pour tout une des marques de
"paragraphe". (Evitons le dernier "caractère" du document, pour ne pas
compliquer les choses.)
Si vous faites afficher Len(Selection.Text), vous obtenez 2.
Placez maintenant le curseur n'importe où et appuyez sur la touche "entrée".
Sélectionnez la marque de paragraphe que vous avez ainsi créée, et elle
seule. L'affichage de Len(Selection.Text) donne maintenant 1.
Contrairement à ce que hennissait ("hihihi") Anacoluthe, l'incohérence a
maintenant lieu dans un même document, et non entre un txt et un doc.
Cela veut dire que si l'utilisateur exécute plusieurs fois la macro en
modifiant le texte entre deux exécutions, on ne peut pas se fier à
Len(Selection.Text).
Comme la documentation ne semble pas avertir de cette particularité de la
propriété Text, et que je ne vois vraiment pas son utilité mais bien ses
inconvénients, j'estime qu'il y a là un bug.
Si ça dépendait de moi, il y aurait une propriété Text10 de l'objet
Selection et des objets Range qui lirait une marque de paragraphe comme un
unique Chr(10), aussi bien dans un document Word que dans un txt.
Il y aurait des propriétés Text13, Text1013 et Text1310 analogues.
Ainsi, pour tester si un "caractère" (à l'écran) sélectionné est une marque
de paragraphe, on pourrait dire "If Selection.Text10 = Chr(10) "; on
pourrait aussi mettre "If Selection.Text13 = Chr(13)", ce qui aurait
exactement le même effet.
Quant aux programmeurs qui ont l'utilité des mystérieuses propriétés de
Text, ils pourraient continuer à s'en servir.
Clément, c'est gentil de vous excuser mais je n'ai peut-être pas été tout à fait clair.
Pour mettre les points sur les i : enregistrez comme fichier txt, avec CR/LF pour les marques de "paragraphe" un document qui comporte plusieurs "paragraphes". Fermez-le et rouvrez-le. Faites une sélection qui recouvre en tout et pour tout une des marques de "paragraphe". (Evitons le dernier "caractère" du document, pour ne pas compliquer les choses.) Si vous faites afficher Len(Selection.Text), vous obtenez 2. Placez maintenant le curseur n'importe où et appuyez sur la touche "entrée". Sélectionnez la marque de paragraphe que vous avez ainsi créée, et elle seule. L'affichage de Len(Selection.Text) donne maintenant 1.
Contrairement à ce que hennissait ("hihihi") Anacoluthe, l'incohérence a maintenant lieu dans un même document, et non entre un txt et un doc.
Cela veut dire que si l'utilisateur exécute plusieurs fois la macro en modifiant le texte entre deux exécutions, on ne peut pas se fier à Len(Selection.Text).
Comme la documentation ne semble pas avertir de cette particularité de la propriété Text, et que je ne vois vraiment pas son utilité mais bien ses inconvénients, j'estime qu'il y a là un bug.
Si ça dépendait de moi, il y aurait une propriété Text10 de l'objet Selection et des objets Range qui lirait une marque de paragraphe comme un unique Chr(10), aussi bien dans un document Word que dans un txt. Il y aurait des propriétés Text13, Text1013 et Text1310 analogues. Ainsi, pour tester si un "caractère" (à l'écran) sélectionné est une marque de paragraphe, on pourrait dire "If Selection.Text10 = Chr(10) "; on pourrait aussi mettre "If Selection.Text13 = Chr(13)", ce qui aurait exactement le même effet. Quant aux programmeurs qui ont l'utilité des mystérieuses propriétés de Text, ils pourraient continuer à s'en servir.
Mersenne.
Anacoluthe
Bonjour !
'Mersenne' nous a écrit ...
Contrairement à ce que hennissait ("hihihi") Anacoluthe, l'incohérence a maintenant lieu dans un même document, et non entre un txt et un doc.
il me plait de hennir !
Je maintiens, je persiste et je signe : AUCUNE INCOHERENCE !!!
Dans le même document vous avez une PLAGE issue d'un fichier TEXTE contenant 2 caractères et plus loin une PLAGE strictement équivalente pour Word écrite avec la touche entrée et comportant 1 seul caractère.
Comme la documentation ne semble pas avertir de cette particularité de la propriété Text, et que je ne vois vraiment pas son utilité mais bien ses inconvénients, j'estime qu'il y a là un bug.
La documentation est parfaitement CLAIRE : qu'est-ce que la propriété TEXT ? C'est une grandeur STRING. Une chaîne de caractères composées d'octets. Word n'est pas un éditeur hexadécimal. Quand vous vous entêtez à ne raisonner que sur Selection.Text vous utilisez une TRANSPOSITION de la PLAGE Selection du document. La propriété text malgré tous les défauts que vous lui trouvez est très souvent utilisée en vba.
Je comprends qu'obtenir 2 transpositions text différentes pour deux plage (Range) apparemment identiques puisse vous gêner dans votre projet, mais veuillez nous épargner vos meuglements au bug. Merci
hihihihihihihihihihi
Anacoluthe
Bonjour !
'Mersenne' nous a écrit ...
Contrairement à ce que hennissait ("hihihi") Anacoluthe, l'incohérence a
maintenant lieu dans un même document, et non entre un txt et un doc.
il me plait de hennir !
Je maintiens, je persiste et je signe : AUCUNE INCOHERENCE !!!
Dans le même document vous avez une PLAGE issue d'un fichier TEXTE
contenant 2 caractères et plus loin une PLAGE strictement équivalente
pour Word écrite avec la touche entrée et comportant 1 seul caractère.
Comme la documentation ne semble pas avertir de cette particularité de la
propriété Text, et que je ne vois vraiment pas son utilité mais bien ses
inconvénients, j'estime qu'il y a là un bug.
La documentation est parfaitement CLAIRE : qu'est-ce que la propriété
TEXT ? C'est une grandeur STRING. Une chaîne de caractères composées
d'octets. Word n'est pas un éditeur hexadécimal. Quand vous vous
entêtez à ne raisonner que sur Selection.Text vous utilisez une
TRANSPOSITION de la PLAGE Selection du document.
La propriété text malgré tous les défauts que vous lui trouvez est
très souvent utilisée en vba.
Je comprends qu'obtenir 2 transpositions text différentes pour deux
plage (Range) apparemment identiques puisse vous gêner dans votre
projet, mais veuillez nous épargner vos meuglements au bug. Merci
Contrairement à ce que hennissait ("hihihi") Anacoluthe, l'incohérence a maintenant lieu dans un même document, et non entre un txt et un doc.
il me plait de hennir !
Je maintiens, je persiste et je signe : AUCUNE INCOHERENCE !!!
Dans le même document vous avez une PLAGE issue d'un fichier TEXTE contenant 2 caractères et plus loin une PLAGE strictement équivalente pour Word écrite avec la touche entrée et comportant 1 seul caractère.
Comme la documentation ne semble pas avertir de cette particularité de la propriété Text, et que je ne vois vraiment pas son utilité mais bien ses inconvénients, j'estime qu'il y a là un bug.
La documentation est parfaitement CLAIRE : qu'est-ce que la propriété TEXT ? C'est une grandeur STRING. Une chaîne de caractères composées d'octets. Word n'est pas un éditeur hexadécimal. Quand vous vous entêtez à ne raisonner que sur Selection.Text vous utilisez une TRANSPOSITION de la PLAGE Selection du document. La propriété text malgré tous les défauts que vous lui trouvez est très souvent utilisée en vba.
Je comprends qu'obtenir 2 transpositions text différentes pour deux plage (Range) apparemment identiques puisse vous gêner dans votre projet, mais veuillez nous épargner vos meuglements au bug. Merci
Ah ben zut alors... moi on m'avait dit que c'était qqchose de tout petit au contraire :-) http://fr.wikipedia.org/wiki/String
JièL Fils celle et cale son
Mersenne
"Anacoluthe" a écrit dans le message de news:
Bonjour !
Je maintiens, je persiste et je signe : AUCUNE INCOHERENCE !!!
et un peu plus loin :
Je comprends qu'obtenir 2 transpositions text différentes pour deux plage (Range) apparemment identiques puisse vous gêner dans votre projet,
Ce n'est pas une incohérence, ça ?
La documentation est parfaitement CLAIRE : qu'est-ce que la propriété TEXT ? C'est une grandeur STRING. Une chaîne de caractères composées d'octets.
Est-ce la chaîne qui est composée (au singulier) d'octets ou les caractères qui en sont composés (au masculin) ? Si vous voulez dire que Len(Text) est le nombre d'octets qui composent la chaîne, je crois que vous vous trompez. Par exemple écrivez dans un document le caractère I à l'aide par exemple de Selection.TypeText Text:=ChrW(300) (mon Word 2002 ne me permet pas de taper del'Unicode, mais je crois que Word 2002 le permet avec Insertion/Caractères spéciaux). Ensuite sélectionnez ce caractère et faites afficher Len(Selection.Text) : vous obtenez 1. Or je ne crois pas que ce caractère tienne sur un seul octet.
La documentation ne me semble donc pas si claire, puisque vous semblez penser que Len(Selection.Text) compte des octets. Si la documentation était claire, les différences constatées seraient prévisibles. Or un vieux routier comme Clément a dit des ... demandez-lui quoi.
Word n'est pas un éditeur hexadécimal.
Justement : un éditeur hexadécimal, ça va voir sous le capot, or Geo expliquait qu'il n'est pas nécessaire d'aller voir sous le capot. En disant que Len(Selection.Text) est 2 quand une marque de paragraphe est sélectionnée, Word se mêle d'aller voir sous le capot dans un contexte où on n'en a pas besoin et où ça a un effet perturbant.
Si vous pouvez m'indiquer un avantage de la disparité de fonctionnement de Selection.Text (tantôt 1 et tantôt 2), cela m'intéresserait, à condition, bien sûr, que ce ne soit pas un avantage auquel on puisse répliquer comme vous : "Word n'est pas un éditeur hexadécimal".
Mersenne.
"Anacoluthe" a écrit dans le message de news:
OdoBFm6OGHA.3944@tk2msftngp13.phx.gbl...
Bonjour !
Je maintiens, je persiste et je signe : AUCUNE INCOHERENCE !!!
et un peu plus loin :
Je comprends qu'obtenir 2 transpositions text différentes pour deux
plage (Range) apparemment identiques puisse vous gêner dans votre
projet,
Ce n'est pas une incohérence, ça ?
La documentation est parfaitement CLAIRE : qu'est-ce que la propriété
TEXT ? C'est une grandeur STRING. Une chaîne de caractères composées
d'octets.
Est-ce la chaîne qui est composée (au singulier) d'octets ou les caractères
qui en sont composés (au masculin) ?
Si vous voulez dire que Len(Text) est le nombre d'octets qui composent la
chaîne, je crois que vous vous trompez.
Par exemple écrivez dans un document le caractère I à l'aide par exemple de
Selection.TypeText Text:=ChrW(300)
(mon Word 2002 ne me permet pas de taper del'Unicode, mais je crois que Word
2002 le permet avec Insertion/Caractères spéciaux).
Ensuite sélectionnez ce caractère et faites afficher Len(Selection.Text) :
vous obtenez 1. Or je ne crois pas que ce caractère tienne sur un seul
octet.
La documentation ne me semble donc pas si claire, puisque vous semblez
penser que Len(Selection.Text) compte des octets.
Si la documentation était claire, les différences constatées seraient
prévisibles. Or un vieux routier comme Clément a dit des ... demandez-lui
quoi.
Word n'est pas un éditeur hexadécimal.
Justement : un éditeur hexadécimal, ça va voir sous le capot, or Geo
expliquait qu'il n'est pas nécessaire d'aller voir sous le capot.
En disant que Len(Selection.Text) est 2 quand une marque de paragraphe est
sélectionnée, Word se mêle d'aller voir sous le capot dans un contexte où on
n'en a pas besoin et où ça a un effet perturbant.
Si vous pouvez m'indiquer un avantage de la disparité de fonctionnement de
Selection.Text (tantôt 1 et tantôt 2), cela m'intéresserait, à condition,
bien sûr, que ce ne soit pas un avantage auquel on puisse répliquer comme
vous : "Word n'est pas un éditeur hexadécimal".
Je maintiens, je persiste et je signe : AUCUNE INCOHERENCE !!!
et un peu plus loin :
Je comprends qu'obtenir 2 transpositions text différentes pour deux plage (Range) apparemment identiques puisse vous gêner dans votre projet,
Ce n'est pas une incohérence, ça ?
La documentation est parfaitement CLAIRE : qu'est-ce que la propriété TEXT ? C'est une grandeur STRING. Une chaîne de caractères composées d'octets.
Est-ce la chaîne qui est composée (au singulier) d'octets ou les caractères qui en sont composés (au masculin) ? Si vous voulez dire que Len(Text) est le nombre d'octets qui composent la chaîne, je crois que vous vous trompez. Par exemple écrivez dans un document le caractère I à l'aide par exemple de Selection.TypeText Text:=ChrW(300) (mon Word 2002 ne me permet pas de taper del'Unicode, mais je crois que Word 2002 le permet avec Insertion/Caractères spéciaux). Ensuite sélectionnez ce caractère et faites afficher Len(Selection.Text) : vous obtenez 1. Or je ne crois pas que ce caractère tienne sur un seul octet.
La documentation ne me semble donc pas si claire, puisque vous semblez penser que Len(Selection.Text) compte des octets. Si la documentation était claire, les différences constatées seraient prévisibles. Or un vieux routier comme Clément a dit des ... demandez-lui quoi.
Word n'est pas un éditeur hexadécimal.
Justement : un éditeur hexadécimal, ça va voir sous le capot, or Geo expliquait qu'il n'est pas nécessaire d'aller voir sous le capot. En disant que Len(Selection.Text) est 2 quand une marque de paragraphe est sélectionnée, Word se mêle d'aller voir sous le capot dans un contexte où on n'en a pas besoin et où ça a un effet perturbant.
Si vous pouvez m'indiquer un avantage de la disparité de fonctionnement de Selection.Text (tantôt 1 et tantôt 2), cela m'intéresserait, à condition, bien sûr, que ce ne soit pas un avantage auquel on puisse répliquer comme vous : "Word n'est pas un éditeur hexadécimal".
Mersenne.
Clément Marcotte
Bonjour,
Même que c'est lassant à la longue de se faire dire que c'est un bug parce que ce n'est pas la copie conforme de Perl ou de Java ou de C ou de C++ ou de Cobol ou de Logo ou d'APL ou de Pascal ou de Fortran ou de Forth ou de ...
"Anacoluthe" a écrit dans le message de news:
Bonjour !
'Mersenne' nous a écrit ...
Contrairement à ce que hennissait ("hihihi") Anacoluthe, l'incohérence a maintenant lieu dans un même document, et non entre un txt et un doc.
il me plait de hennir !
Je maintiens, je persiste et je signe : AUCUNE INCOHERENCE !!!
Dans le même document vous avez une PLAGE issue d'un fichier TEXTE contenant 2 caractères et plus loin une PLAGE strictement équivalente pour Word écrite avec la touche entrée et comportant 1 seul caractère.
Comme la documentation ne semble pas avertir de cette particularité de la propriété Text, et que je ne vois vraiment pas son utilité mais bien ses inconvénients, j'estime qu'il y a là un bug.
La documentation est parfaitement CLAIRE : qu'est-ce que la propriété TEXT ? C'est une grandeur STRING. Une chaîne de caractères composées d'octets. Word n'est pas un éditeur hexadécimal. Quand vous vous entêtez à ne raisonner que sur Selection.Text vous utilisez une TRANSPOSITION de la PLAGE Selection du document. La propriété text malgré tous les défauts que vous lui trouvez est très souvent utilisée en vba.
Je comprends qu'obtenir 2 transpositions text différentes pour deux plage (Range) apparemment identiques puisse vous gêner dans votre projet, mais veuillez nous épargner vos meuglements au bug. Merci
hihihihihihihihihihi
Anacoluthe
Bonjour,
Même que c'est lassant à la longue de se faire dire que c'est un bug parce
que ce n'est pas la copie conforme de Perl ou de Java ou de C ou de C++ ou
de Cobol ou de Logo ou d'APL ou de Pascal ou de Fortran ou de Forth ou de
...
"Anacoluthe" <nopub_anacoluthe@Ouanadoo.fr> a écrit dans le message de news:
OdoBFm6OGHA.3944@tk2msftngp13.phx.gbl...
Bonjour !
'Mersenne' nous a écrit ...
Contrairement à ce que hennissait ("hihihi") Anacoluthe, l'incohérence a
maintenant lieu dans un même document, et non entre un txt et un doc.
il me plait de hennir !
Je maintiens, je persiste et je signe : AUCUNE INCOHERENCE !!!
Dans le même document vous avez une PLAGE issue d'un fichier TEXTE
contenant 2 caractères et plus loin une PLAGE strictement équivalente
pour Word écrite avec la touche entrée et comportant 1 seul caractère.
Comme la documentation ne semble pas avertir de cette particularité de la
propriété Text, et que je ne vois vraiment pas son utilité mais bien ses
inconvénients, j'estime qu'il y a là un bug.
La documentation est parfaitement CLAIRE : qu'est-ce que la propriété
TEXT ? C'est une grandeur STRING. Une chaîne de caractères composées
d'octets. Word n'est pas un éditeur hexadécimal. Quand vous vous
entêtez à ne raisonner que sur Selection.Text vous utilisez une
TRANSPOSITION de la PLAGE Selection du document.
La propriété text malgré tous les défauts que vous lui trouvez est
très souvent utilisée en vba.
Je comprends qu'obtenir 2 transpositions text différentes pour deux
plage (Range) apparemment identiques puisse vous gêner dans votre
projet, mais veuillez nous épargner vos meuglements au bug. Merci
Même que c'est lassant à la longue de se faire dire que c'est un bug parce que ce n'est pas la copie conforme de Perl ou de Java ou de C ou de C++ ou de Cobol ou de Logo ou d'APL ou de Pascal ou de Fortran ou de Forth ou de ...
"Anacoluthe" a écrit dans le message de news:
Bonjour !
'Mersenne' nous a écrit ...
Contrairement à ce que hennissait ("hihihi") Anacoluthe, l'incohérence a maintenant lieu dans un même document, et non entre un txt et un doc.
il me plait de hennir !
Je maintiens, je persiste et je signe : AUCUNE INCOHERENCE !!!
Dans le même document vous avez une PLAGE issue d'un fichier TEXTE contenant 2 caractères et plus loin une PLAGE strictement équivalente pour Word écrite avec la touche entrée et comportant 1 seul caractère.
Comme la documentation ne semble pas avertir de cette particularité de la propriété Text, et que je ne vois vraiment pas son utilité mais bien ses inconvénients, j'estime qu'il y a là un bug.
La documentation est parfaitement CLAIRE : qu'est-ce que la propriété TEXT ? C'est une grandeur STRING. Une chaîne de caractères composées d'octets. Word n'est pas un éditeur hexadécimal. Quand vous vous entêtez à ne raisonner que sur Selection.Text vous utilisez une TRANSPOSITION de la PLAGE Selection du document. La propriété text malgré tous les défauts que vous lui trouvez est très souvent utilisée en vba.
Je comprends qu'obtenir 2 transpositions text différentes pour deux plage (Range) apparemment identiques puisse vous gêner dans votre projet, mais veuillez nous épargner vos meuglements au bug. Merci
hihihihihihihihihihi
Anacoluthe
Mersenne
Désolé, mais je vois que dans mon message précédent, le caractère Unicode 300 a été transformé en I ordinaire. Ne faites attention qu'à ChrW(300)
Mersenne.
Désolé, mais je vois que dans mon message précédent, le caractère Unicode
300 a été transformé en I ordinaire. Ne faites attention qu'à ChrW(300)
Désolé, mais je vois que dans mon message précédent, le caractère Unicode 300 a été transformé en I ordinaire. Ne faites attention qu'à ChrW(300)
Mersenne.
Clément Marcotte
Ensuite sélectionnez ce caractère et faites afficher Len(Selection.Text) : vous obtenez 1. Or je ne crois pas que ce caractère tienne sur un seul octet.
1 caractère dans Word = 1 lettre = 1 chiffre = 1 espace = 1 signe de ponctuation = 1 symbole mathématique
Ensuite sélectionnez ce caractère et faites afficher Len(Selection.Text) :
vous obtenez 1. Or je ne crois pas que ce caractère tienne sur un seul
octet.
1 caractère dans Word = 1 lettre = 1 chiffre = 1 espace = 1 signe de
ponctuation = 1 symbole mathématique
Ensuite sélectionnez ce caractère et faites afficher Len(Selection.Text) : vous obtenez 1. Or je ne crois pas que ce caractère tienne sur un seul octet.
1 caractère dans Word = 1 lettre = 1 chiffre = 1 espace = 1 signe de ponctuation = 1 symbole mathématique
Mersenne
"Clément Marcotte" a écrit dans le message de news:
Bonjour,
Même que c'est lassant à la longue de se faire dire que c'est un bug parce que ce n'est pas la copie conforme de Perl ou de Java ou de C ou de C++ ou de Cobol ou de Logo ou d'APL ou de Pascal ou de Fortran ou de Forth ou de ...
Je ne demande pas que VBA-W soit une copie conforme de Perl, j'attendrais un peu de cohérence, et s'il y a des raisons de sacrifier la cohérence, un peu de documentation.
Anacoluthe, pour expliquer que Len(Selection.Text) renvoie 2 quand le document a été enregistré (avant d'être ouvert) en tant que txt CR/LF, nous dit que Text renvoie une chaîne de caractères "composées (sic) d'octets". La seule interprétation raisonnable de cette façon de s'exprimer est que Len(Selection.Text) est le nombre d'octets de la chaîne, ce qui est inexact, comme le montre l'exemple de ChrW(300).
Mersenne.
"Clément Marcotte" a écrit dans le message de news:
ufkPhA8OGHA.516@TK2MSFTNGP15.phx.gbl...
Bonjour,
Même que c'est lassant à la longue de se faire dire que c'est un bug parce
que ce n'est pas la copie conforme de Perl ou de Java ou de C ou de C++ ou
de Cobol ou de Logo ou d'APL ou de Pascal ou de Fortran ou de Forth ou de
...
Je ne demande pas que VBA-W soit une copie conforme de Perl, j'attendrais un
peu de cohérence, et s'il y a des raisons de sacrifier la cohérence, un peu
de documentation.
Anacoluthe, pour expliquer que Len(Selection.Text) renvoie 2 quand le
document a été enregistré (avant d'être ouvert) en tant que txt CR/LF, nous
dit que Text renvoie une chaîne de caractères "composées (sic) d'octets".
La seule interprétation raisonnable de cette façon de s'exprimer est que
Len(Selection.Text) est le nombre d'octets de la chaîne, ce qui est inexact,
comme le montre l'exemple de ChrW(300).
"Clément Marcotte" a écrit dans le message de news:
Bonjour,
Même que c'est lassant à la longue de se faire dire que c'est un bug parce que ce n'est pas la copie conforme de Perl ou de Java ou de C ou de C++ ou de Cobol ou de Logo ou d'APL ou de Pascal ou de Fortran ou de Forth ou de ...
Je ne demande pas que VBA-W soit une copie conforme de Perl, j'attendrais un peu de cohérence, et s'il y a des raisons de sacrifier la cohérence, un peu de documentation.
Anacoluthe, pour expliquer que Len(Selection.Text) renvoie 2 quand le document a été enregistré (avant d'être ouvert) en tant que txt CR/LF, nous dit que Text renvoie une chaîne de caractères "composées (sic) d'octets". La seule interprétation raisonnable de cette façon de s'exprimer est que Len(Selection.Text) est le nombre d'octets de la chaîne, ce qui est inexact, comme le montre l'exemple de ChrW(300).
Mersenne.
Clément Marcotte
Dans VB - VBA, len() a toujours compté le nombre de caractères, bien avant l'arrivée d'unicode. Avant l'arrivée d'Unicode 1 caractère = 1 octet.
Unicode change la donne, mais Microsoft, contrairement à d'autres, a toujours eu la politique de préserver la compatibilité ascendante.
Je suis sur que si l'on cherchait un peu, on pourrait arriver à des histoires semblables avec bien des produits.
Et puis, il suffit, au moment de l'importation, de juste enlever la fin de ligne. Au moment de l'enregistrement du fichier texte VBA va toujours mettre le même caractère de fin de ligne.
Et puis, comme j'ai dit ailleurs, Print #1, sans rien d'autre imprime une ligne vide
Et puis, j'en ai marre. PLONK.
"Mersenne" a écrit dans le message de news:
"Clément Marcotte" a écrit dans le message de news:
Bonjour,
Même que c'est lassant à la longue de se faire dire que c'est un bug parce que ce n'est pas la copie conforme de Perl ou de Java ou de C ou de C++ ou de Cobol ou de Logo ou d'APL ou de Pascal ou de Fortran ou de Forth ou de ...
Je ne demande pas que VBA-W soit une copie conforme de Perl, j'attendrais un peu de cohérence, et s'il y a des raisons de sacrifier la cohérence, un peu de documentation.
Anacoluthe, pour expliquer que Len(Selection.Text) renvoie 2 quand le document a été enregistré (avant d'être ouvert) en tant que txt CR/LF, nous dit que Text renvoie une chaîne de caractères "composées (sic) d'octets". La seule interprétation raisonnable de cette façon de s'exprimer est que Len(Selection.Text) est le nombre d'octets de la chaîne, ce qui est inexact, comme le montre l'exemple de ChrW(300).
Mersenne.
Dans VB - VBA, len() a toujours compté le nombre de caractères, bien avant
l'arrivée d'unicode. Avant l'arrivée d'Unicode 1 caractère = 1 octet.
Unicode change la donne, mais Microsoft, contrairement à d'autres, a
toujours eu la politique de préserver la compatibilité ascendante.
Je suis sur que si l'on cherchait un peu, on pourrait arriver à des
histoires semblables avec bien des produits.
Et puis, il suffit, au moment de l'importation, de juste enlever la fin de
ligne. Au moment de l'enregistrement du fichier texte VBA va toujours mettre
le même caractère de fin de ligne.
Et puis, comme j'ai dit ailleurs, Print #1, sans rien d'autre imprime une
ligne vide
Et puis, j'en ai marre. PLONK.
"Mersenne" <fa602502@skynet.be> a écrit dans le message de news:
eaZVGP8OGHA.2040@TK2MSFTNGP14.phx.gbl...
"Clément Marcotte" a écrit dans le message de news:
ufkPhA8OGHA.516@TK2MSFTNGP15.phx.gbl...
Bonjour,
Même que c'est lassant à la longue de se faire dire que c'est un bug
parce que ce n'est pas la copie conforme de Perl ou de Java ou de C ou de
C++ ou de Cobol ou de Logo ou d'APL ou de Pascal ou de Fortran ou de
Forth ou de ...
Je ne demande pas que VBA-W soit une copie conforme de Perl, j'attendrais
un peu de cohérence, et s'il y a des raisons de sacrifier la cohérence, un
peu de documentation.
Anacoluthe, pour expliquer que Len(Selection.Text) renvoie 2 quand le
document a été enregistré (avant d'être ouvert) en tant que txt CR/LF,
nous dit que Text renvoie une chaîne de caractères "composées (sic)
d'octets".
La seule interprétation raisonnable de cette façon de s'exprimer est que
Len(Selection.Text) est le nombre d'octets de la chaîne, ce qui est
inexact, comme le montre l'exemple de ChrW(300).
Dans VB - VBA, len() a toujours compté le nombre de caractères, bien avant l'arrivée d'unicode. Avant l'arrivée d'Unicode 1 caractère = 1 octet.
Unicode change la donne, mais Microsoft, contrairement à d'autres, a toujours eu la politique de préserver la compatibilité ascendante.
Je suis sur que si l'on cherchait un peu, on pourrait arriver à des histoires semblables avec bien des produits.
Et puis, il suffit, au moment de l'importation, de juste enlever la fin de ligne. Au moment de l'enregistrement du fichier texte VBA va toujours mettre le même caractère de fin de ligne.
Et puis, comme j'ai dit ailleurs, Print #1, sans rien d'autre imprime une ligne vide
Et puis, j'en ai marre. PLONK.
"Mersenne" a écrit dans le message de news:
"Clément Marcotte" a écrit dans le message de news:
Bonjour,
Même que c'est lassant à la longue de se faire dire que c'est un bug parce que ce n'est pas la copie conforme de Perl ou de Java ou de C ou de C++ ou de Cobol ou de Logo ou d'APL ou de Pascal ou de Fortran ou de Forth ou de ...
Je ne demande pas que VBA-W soit une copie conforme de Perl, j'attendrais un peu de cohérence, et s'il y a des raisons de sacrifier la cohérence, un peu de documentation.
Anacoluthe, pour expliquer que Len(Selection.Text) renvoie 2 quand le document a été enregistré (avant d'être ouvert) en tant que txt CR/LF, nous dit que Text renvoie une chaîne de caractères "composées (sic) d'octets". La seule interprétation raisonnable de cette façon de s'exprimer est que Len(Selection.Text) est le nombre d'octets de la chaîne, ce qui est inexact, comme le montre l'exemple de ChrW(300).
