Affichage de chaine de caractères

Fabien LE LEZ

03/09/2003 à 12:47

On Wed, 03 Sep 2003 11:10:46 +0200, thierry
wrote:

Mon problème est au niveau de l'affichage du texte : les caractères de
tabulation "t" sont interprétés comme il se doit
(le texte est décalé), mais ces caractères sont affichés sous la forme
d'un petit carré que j'aimerais bien faire
disparaitre.

C'est n'est pas un problème lié au langage C++, mais vraisemblablement
à ton OS et/ou aux bibliothèques que tu utilises. HS ici donc...

thierry

04/09/2003 à 23:28

[à propos d'un programme en C++]

Mon problème est au niveau de l'affichage du texte : les caractères de
tabulation "t" sont interprétés comme il se doit

C'est n'est pas un problème lié au langage C++, mais vraisemblablement
à ton OS et/ou aux bibliothèques que tu utilises. HS ici donc...

Disons que j'ai VRAIMENT passé du temps à chercher une solution, et
qu'en l'absence de forum spécifique, celui-ci me parait le plus adapté.

Fabien LE LEZ

04/09/2003 à 23:40

On Thu, 04 Sep 2003 23:28:06 +0200, thierry
wrote:

Disons que j'ai VRAIMENT passé du temps à chercher une solution, et
qu'en l'absence de forum spécifique, celui-ci me parait le plus adapté.

Eh bien tu t'es lourdement trompé. Il faut lire la FAQ avant de poster
sur un forum.

kanze

05/09/2003 à 10:59

Fabien LE LEZ wrote in message
news:...

On Thu, 04 Sep 2003 23:28:06 +0200, thierry
wrote:

Disons que j'ai VRAIMENT passé du temps à chercher une solution, et
qu'en l'absence de forum spécifique, celui-ci me parait le plus
adapté.

Eh bien tu t'es lourdement trompé. Il faut lire la FAQ avant de poster
sur un forum.

N'exagérons rien. Je soupçonne que son problème soit lié à une histoire
de codepage, et donc du système, mais je ne peux pas être certain. Il se
peut aussi bien que c'est un problème de locale, ce qui ne serait pas du
tout HS ici.

Le problème, c'est ce qu'il doit faire pour procéder. A priori, s'il
voit de petits carrés, comme il dit, c'est qu'il sort un caractère vers
le système pour lequel il n'y a pas de caractère correspondant dans le
font utiliser. Alors, a mon avis, la première chose à faire, c'est de
rédiriger les sorties vers un fichier, et régarder ce qu'on a réelement
sortie avec un éditeur hex. Si ce qu'on a réelement sortie, c'est ce
qu'on voulait sortir (ou ce qu'on croyait vouloir sortir), c'est un
problème système -- il faudrait s'adresser à un groupe propre au système
pour se renseigner comment faire avec des fonts (et peut-être pour
apprendre que ce qu'on croyait vouloir sortir, ce n'est pas ce qu'on
aurait dû vouloir sortir, ce qui pourrait le ramener ici de nouveau). Se
ce qu'on a sorti n'est pas ce qu'on voulait sortir, en revanche, c'est
probablement un problème C++, et la question a tout à fait sa place ici.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

thierry

06/09/2003 à 12:45

Le problème, c'est ce qu'il doit faire pour procéder.

[...]

Merci, c'est toujours une bonne idée de donner un bout de piste pour
chercher une solution à un problème.

J'ai donc continué à chercher, mais toujours pas de solution.
Résultat de mes test :

1- Les caractère semble correctement encodé, sous la forme hexa de "09"
ce qui me parait adapté (mais j'ai toujours un doute ?)

2 - Le pb persiste quel que soit l'objet utilisé dans la bibliothèque
GTK (label, textview...)

3 - Le seul cas ou le pb ne se produit pas est en utilisant une
MessageBoxEx.

4 - Si je crée un fichier texte manuellement, en écrivant des tabulation
avec la touche du clavier, le pb est toujours là quand je tente
l'affichage à travers mon programme.

5 - Si je copie une portion de texte mal affiché dans le presse-papier,
puis je le colle dans un document word par exemple, il n'y a pas ce
problème d'affichage, qui reste donc interne à mon programme.

6 - Le problème est spécifique aux tabulation, quels soient entrée sous
la forme "t" ou en utilisant la valeur ascii 9. Les fins de lignes
("n" ou 13) ne posent pas ce problème.

Que conclure ?

1- A priori, le système n'est pas en cause, puisque ça fonctionne avec
les MessageBoxEx.

2 - Il se pourrait bien que ce soit les bibliothèque GTK qui soient en
cause. Mais j'ai un peu de mal à y croire puisque diférentes versions
testés posent le même problème : peu probable qu'un truc aussi voyant
n'est pas été corrigé d'une version à l'autre.

3 - Peut-être aussi qu'il esiste d'autre forme d'écriture que "t" ou 9
pour intégrer une tabulation dans un texte, et que je n'utilise pas la
bonne méthode ?

Bref, je n'ai pas beaucoup avance, et je ne sais toujours pas avec
certitude à quel niveau ce situe le problème ?

Bon week-end à tous.

kanze

08/09/2003 à 10:08

thierry wrote in message
news:<bjcdut$m7j$...

Le problème, c'est ce qu'il doit faire pour procéder.

[...]

Merci, c'est toujours une bonne idée de donner un bout de piste pour
chercher une solution à un problème.

J'ai donc continué à chercher, mais toujours pas de solution. Résultat
de mes test :

1- Les caractère semble correctement encodé, sous la forme hexa de "09"
ce qui me parait adapté (mais j'ai toujours un doute ?)

C-à-d que si tu fais quelque chose du genre :

std::cout << "tan"

dans un programme où tu as rédirigé les sorties vers un fichier, si tu
régardes le fichier avec un éditeur hex, il contient 0x09, 0x61, 0x0D,
0x0A ? (Les deux derniers caractères peuvent varier selon le système.
Mais les deux premiers doivent être corrects.)

Si oui, on peut dire que le problème ne vient probablement pas de la
bibliothèque C++.

2 - Le pb persiste quel que soit l'objet utilisé dans la bibliothèque
GTK (label, textview...)

C'est donc un problème d'affichage graphique. Je ne connais pas cette
bibliothèque, mais typiquement, les bibliothèques d'interface graphique
ne traitent pas le 't', parce qu'elles s'attendent à ce que le font ait
une chasse variable, et donc que ce caractère n'a pas de signification.
(Comment avancer jusqu'à la prochaine colonne multiple de huit, s'il n'y
a pas de colonnes ?)

Du coup, il l'affiche comme un carré vide. (C'est au moin le
comportement par défaut la plupart du temps sous Windows.)

Si c'est ça ton problème, la solution est simple : ne pas essayer
d'afficher des 't'. Typiquement, la seule façon de créer des éspaces
dans le texte, c'est de l'afficher dans deux composants distincts, avec
un composant d'éspaçage entre eux, ou en forçant la taille des deux
composants.

3 - Le seul cas ou le pb ne se produit pas est en utilisant une
MessageBoxEx.

Ils auraient une fonction spéciale pour le traiter là ?

4 - Si je crée un fichier texte manuellement, en écrivant des
tabulation avec la touche du clavier, le pb est toujours là quand je
tente l'affichage à travers mon programme.

Si sortir "t" pose un problème, le fait que tu lis le 't' d'un fichier
n'y changerait rien. Si un 't' constante s'affiche mal, le problème ne
peut pas être dans les entrées.

5 - Si je copie une portion de texte mal affiché dans le
presse-papier, puis je le colle dans un document word par exemple, il
n'y a pas ce problème d'affichage, qui reste donc interne à mon
programme.

Là, je ne peux pas dire grand chose. Je ne connais pas comment fonction
le copier/coller sous Windows.

6 - Le problème est spécifique aux tabulation, quels soient entrée
sous la forme "t" ou en utilisant la valeur ascii 9. Les fins de
lignes ("n" ou 13) ne posent pas ce problème.

Que conclure ?

Que la bibliothèque graphique comprend bien les 'n', mais pas les 't'.

C'est donc un problème de bibliothèque graphique. HS ici, mais si ce
n'est pas la bibliothèque standard de Windows (MFC), je ne sais pas où
t'envoyer. Seulement, comme j'ai dit ci-dessus, ce comportement me
semble assez normal pour un bibliothèque graphique -- Java Swing
n'interprète pas les 't' (en Java) non plus.

1- A priori, le système n'est pas en cause, puisque ça fonctionne avec
les MessageBoxEx.

Le système est un entité complexe. Ce n'est pas dit que les MessageBoxEx
passe par le même chemin que les autres textes. L'affichage d'un carré,
c'est bien un comportement de Windows, je crois, pour les caractères ne
se trouvant pas dans la police. La règle, c'est de ne pas envoyer des
't' à une fenêtre Windows (ni X-Windows, sous Unix).

2 - Il se pourrait bien que ce soit les bibliothèque GTK qui soient en
cause. Mais j'ai un peu de mal à y croire puisque diférentes versions
testés posent le même problème : peu probable qu'un truc aussi voyant
n'est pas été corrigé d'une version à l'autre.

Je crois que le problème vient de ce que tu démandes à la bibliothèque
quelque chose qu'elle ne supporte pas. Je ne connais pas cette
bibliothèque, et je ne crois pas que des questions sur des détails de sa
fonctionnement conviennent ici ; c'est donc à toi de lire la
documentation en détail. Mais si tu ne trouves rien en particulier sur
comment elle traite des tabulations, je partirais du principe qu'elle ne
les traite pas. Comme j'ai dit, du fait que l'affichage en général n'est
pas dans une police à chasse fixe, insérer un nombre de blancs basés sur
le nombre de caractères qui ont précédé dans la ligne n'a aucun sens.

3 - Peut-être aussi qu'il esiste d'autre forme d'écriture que "t" ou
9 pour intégrer une tabulation dans un texte, et que je n'utilise pas
la bonne méthode ?

Le C++ ne connais que les flux de texte. Historiquement, affiché avec
des polices à chasse fixe. Le caractère 't' n'a véritablement une
signification que dans ce contexte. Donc, pas dans les affichages
graphiques.

Pour savoir comment faire dans un affichage graphique, il faut savoir
d'abord à quoi sert réelement le 't'. Typiquement, par exemple, les
bibliothèques graphiques ont des composants de tables, qui remplaceront
d'une manière plus élégante la plupart des utilisations des 't'. Mais
là, il va falloir que tu régardes dans la documentation de ta
bibliothèque, puis trouver un groupe de news qui lui convient
(fr.comp.graphisme.programmation, peut-être).

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

thierry <thierry-77@wanadoo.fr> wrote in message
news:<bjcdut$m7j$1@news-reader1.wanadoo.fr>...

Le problème, c'est ce qu'il doit faire pour procéder.

[...]

Merci, c'est toujours une bonne idée de donner un bout de piste pour
chercher une solution à un problème.

J'ai donc continué à chercher, mais toujours pas de solution. Résultat
de mes test :

1- Les caractère semble correctement encodé, sous la forme hexa de "09"
ce qui me parait adapté (mais j'ai toujours un doute ?)

C-à-d que si tu fais quelque chose du genre :

std::cout << "tan"

dans un programme où tu as rédirigé les sorties vers un fichier, si tu
régardes le fichier avec un éditeur hex, il contient 0x09, 0x61, 0x0D,
0x0A ? (Les deux derniers caractères peuvent varier selon le système.
Mais les deux premiers doivent être corrects.)

Si oui, on peut dire que le problème ne vient probablement pas de la
bibliothèque C++.

2 - Le pb persiste quel que soit l'objet utilisé dans la bibliothèque
GTK (label, textview...)

C'est donc un problème d'affichage graphique. Je ne connais pas cette
bibliothèque, mais typiquement, les bibliothèques d'interface graphique
ne traitent pas le 't', parce qu'elles s'attendent à ce que le font ait
une chasse variable, et donc que ce caractère n'a pas de signification.
(Comment avancer jusqu'à la prochaine colonne multiple de huit, s'il n'y
a pas de colonnes ?)

Du coup, il l'affiche comme un carré vide. (C'est au moin le
comportement par défaut la plupart du temps sous Windows.)

Si c'est ça ton problème, la solution est simple : ne pas essayer
d'afficher des 't'. Typiquement, la seule façon de créer des éspaces
dans le texte, c'est de l'afficher dans deux composants distincts, avec
un composant d'éspaçage entre eux, ou en forçant la taille des deux
composants.

3 - Le seul cas ou le pb ne se produit pas est en utilisant une
MessageBoxEx.

Ils auraient une fonction spéciale pour le traiter là ?

4 - Si je crée un fichier texte manuellement, en écrivant des
tabulation avec la touche du clavier, le pb est toujours là quand je
tente l'affichage à travers mon programme.

Si sortir "t" pose un problème, le fait que tu lis le 't' d'un fichier
n'y changerait rien. Si un 't' constante s'affiche mal, le problème ne
peut pas être dans les entrées.

5 - Si je copie une portion de texte mal affiché dans le
presse-papier, puis je le colle dans un document word par exemple, il
n'y a pas ce problème d'affichage, qui reste donc interne à mon
programme.

Là, je ne peux pas dire grand chose. Je ne connais pas comment fonction
le copier/coller sous Windows.

6 - Le problème est spécifique aux tabulation, quels soient entrée
sous la forme "t" ou en utilisant la valeur ascii 9. Les fins de
lignes ("n" ou 13) ne posent pas ce problème.

Que conclure ?

Que la bibliothèque graphique comprend bien les 'n', mais pas les 't'.

C'est donc un problème de bibliothèque graphique. HS ici, mais si ce
n'est pas la bibliothèque standard de Windows (MFC), je ne sais pas où
t'envoyer. Seulement, comme j'ai dit ci-dessus, ce comportement me
semble assez normal pour un bibliothèque graphique -- Java Swing
n'interprète pas les 't' (en Java) non plus.

1- A priori, le système n'est pas en cause, puisque ça fonctionne avec
les MessageBoxEx.

Le système est un entité complexe. Ce n'est pas dit que les MessageBoxEx
passe par le même chemin que les autres textes. L'affichage d'un carré,
c'est bien un comportement de Windows, je crois, pour les caractères ne
se trouvant pas dans la police. La règle, c'est de ne pas envoyer des
't' à une fenêtre Windows (ni X-Windows, sous Unix).

2 - Il se pourrait bien que ce soit les bibliothèque GTK qui soient en
cause. Mais j'ai un peu de mal à y croire puisque diférentes versions
testés posent le même problème : peu probable qu'un truc aussi voyant
n'est pas été corrigé d'une version à l'autre.

Je crois que le problème vient de ce que tu démandes à la bibliothèque
quelque chose qu'elle ne supporte pas. Je ne connais pas cette
bibliothèque, et je ne crois pas que des questions sur des détails de sa
fonctionnement conviennent ici ; c'est donc à toi de lire la
documentation en détail. Mais si tu ne trouves rien en particulier sur
comment elle traite des tabulations, je partirais du principe qu'elle ne
les traite pas. Comme j'ai dit, du fait que l'affichage en général n'est
pas dans une police à chasse fixe, insérer un nombre de blancs basés sur
le nombre de caractères qui ont précédé dans la ligne n'a aucun sens.

3 - Peut-être aussi qu'il esiste d'autre forme d'écriture que "t" ou
9 pour intégrer une tabulation dans un texte, et que je n'utilise pas
la bonne méthode ?

Le C++ ne connais que les flux de texte. Historiquement, affiché avec
des polices à chasse fixe. Le caractère 't' n'a véritablement une
signification que dans ce contexte. Donc, pas dans les affichages
graphiques.

Pour savoir comment faire dans un affichage graphique, il faut savoir
d'abord à quoi sert réelement le 't'. Typiquement, par exemple, les
bibliothèques graphiques ont des composants de tables, qui remplaceront
d'une manière plus élégante la plupart des utilisations des 't'. Mais
là, il va falloir que tu régardes dans la documentation de ta
bibliothèque, puis trouver un groupe de news qui lui convient
(fr.comp.graphisme.programmation, peut-être).

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Vous avez filtré cet utilisateur ! Consultez son message

thierry wrote in message
news:<bjcdut$m7j$...

Le problème, c'est ce qu'il doit faire pour procéder.

[...]

Merci, c'est toujours une bonne idée de donner un bout de piste pour
chercher une solution à un problème.

J'ai donc continué à chercher, mais toujours pas de solution. Résultat
de mes test :

1- Les caractère semble correctement encodé, sous la forme hexa de "09"
ce qui me parait adapté (mais j'ai toujours un doute ?)

C-à-d que si tu fais quelque chose du genre :

std::cout << "tan"

dans un programme où tu as rédirigé les sorties vers un fichier, si tu
régardes le fichier avec un éditeur hex, il contient 0x09, 0x61, 0x0D,
0x0A ? (Les deux derniers caractères peuvent varier selon le système.
Mais les deux premiers doivent être corrects.)

Si oui, on peut dire que le problème ne vient probablement pas de la
bibliothèque C++.

2 - Le pb persiste quel que soit l'objet utilisé dans la bibliothèque
GTK (label, textview...)

C'est donc un problème d'affichage graphique. Je ne connais pas cette
bibliothèque, mais typiquement, les bibliothèques d'interface graphique
ne traitent pas le 't', parce qu'elles s'attendent à ce que le font ait
une chasse variable, et donc que ce caractère n'a pas de signification.
(Comment avancer jusqu'à la prochaine colonne multiple de huit, s'il n'y
a pas de colonnes ?)

Du coup, il l'affiche comme un carré vide. (C'est au moin le
comportement par défaut la plupart du temps sous Windows.)

Si c'est ça ton problème, la solution est simple : ne pas essayer
d'afficher des 't'. Typiquement, la seule façon de créer des éspaces
dans le texte, c'est de l'afficher dans deux composants distincts, avec
un composant d'éspaçage entre eux, ou en forçant la taille des deux
composants.

3 - Le seul cas ou le pb ne se produit pas est en utilisant une
MessageBoxEx.

Ils auraient une fonction spéciale pour le traiter là ?

4 - Si je crée un fichier texte manuellement, en écrivant des
tabulation avec la touche du clavier, le pb est toujours là quand je
tente l'affichage à travers mon programme.

Si sortir "t" pose un problème, le fait que tu lis le 't' d'un fichier
n'y changerait rien. Si un 't' constante s'affiche mal, le problème ne
peut pas être dans les entrées.

5 - Si je copie une portion de texte mal affiché dans le
presse-papier, puis je le colle dans un document word par exemple, il
n'y a pas ce problème d'affichage, qui reste donc interne à mon
programme.

Là, je ne peux pas dire grand chose. Je ne connais pas comment fonction
le copier/coller sous Windows.

6 - Le problème est spécifique aux tabulation, quels soient entrée
sous la forme "t" ou en utilisant la valeur ascii 9. Les fins de
lignes ("n" ou 13) ne posent pas ce problème.

Que conclure ?

Que la bibliothèque graphique comprend bien les 'n', mais pas les 't'.

C'est donc un problème de bibliothèque graphique. HS ici, mais si ce
n'est pas la bibliothèque standard de Windows (MFC), je ne sais pas où
t'envoyer. Seulement, comme j'ai dit ci-dessus, ce comportement me
semble assez normal pour un bibliothèque graphique -- Java Swing
n'interprète pas les 't' (en Java) non plus.

1- A priori, le système n'est pas en cause, puisque ça fonctionne avec
les MessageBoxEx.

Le système est un entité complexe. Ce n'est pas dit que les MessageBoxEx
passe par le même chemin que les autres textes. L'affichage d'un carré,
c'est bien un comportement de Windows, je crois, pour les caractères ne
se trouvant pas dans la police. La règle, c'est de ne pas envoyer des
't' à une fenêtre Windows (ni X-Windows, sous Unix).

2 - Il se pourrait bien que ce soit les bibliothèque GTK qui soient en
cause. Mais j'ai un peu de mal à y croire puisque diférentes versions
testés posent le même problème : peu probable qu'un truc aussi voyant
n'est pas été corrigé d'une version à l'autre.

Je crois que le problème vient de ce que tu démandes à la bibliothèque
quelque chose qu'elle ne supporte pas. Je ne connais pas cette
bibliothèque, et je ne crois pas que des questions sur des détails de sa
fonctionnement conviennent ici ; c'est donc à toi de lire la
documentation en détail. Mais si tu ne trouves rien en particulier sur
comment elle traite des tabulations, je partirais du principe qu'elle ne
les traite pas. Comme j'ai dit, du fait que l'affichage en général n'est
pas dans une police à chasse fixe, insérer un nombre de blancs basés sur
le nombre de caractères qui ont précédé dans la ligne n'a aucun sens.

3 - Peut-être aussi qu'il esiste d'autre forme d'écriture que "t" ou
9 pour intégrer une tabulation dans un texte, et que je n'utilise pas
la bonne méthode ?

Le C++ ne connais que les flux de texte. Historiquement, affiché avec
des polices à chasse fixe. Le caractère 't' n'a véritablement une
signification que dans ce contexte. Donc, pas dans les affichages
graphiques.

Pour savoir comment faire dans un affichage graphique, il faut savoir
d'abord à quoi sert réelement le 't'. Typiquement, par exemple, les
bibliothèques graphiques ont des composants de tables, qui remplaceront
d'une manière plus élégante la plupart des utilisations des 't'. Mais
là, il va falloir que tu régardes dans la documentation de ta
bibliothèque, puis trouver un groupe de news qui lui convient
(fr.comp.graphisme.programmation, peut-être).

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Affichage de chaine de caractères

6 réponses

Veuillez sélectionner un problème