Le forum (ô combien francophone) des utilisateurs de Powerbuilder.
Pages: 1
Bonjour à tous,
J'interviens ponctuellement en maintenance dans une application et on me signale que suite à une intervention précédente certains objets datawindows ne prennent plus en compte les caractères accentués.
Je précise que ce n'est pas suite à une migration
Un libellé comme "Société" est devenu "Socit:"
Quelqu'un a déjà eut un cas similaire ?
Dernière modification par Dadone (18-03-2014 16:19:36)
Hors ligne
Les problèmes d'encodages c'est toujours la plaie.
Il faudrait pouvoir identifier précisément les caractères affichés par leur code pour pouvoir déterminer si c'est un problème de stockage (est-ce bien ce qui devait être enregistré dans la base) ou de représentation (police, mauvais décodage des caractères, ...). Peut-être un problème d'encodage discordant entre celui qui a enregistré et celui qui relit ? Un mauvais encodage spécifié dans la base ? ...
J'avais publié du code permettant d'afficher dans PB des données façon éditeur hexa avec hexdump_blob(), ça pourrait aider.
Hors ligne
seki a écrit:
Les problèmes d'encodages c'est toujours la plaie.
Il faudrait pouvoir identifier précisément les caractères affichés par leur code pour pouvoir déterminer si c'est un problème de stockage (est-ce bien ce qui devait être enregistré dans la base) ou de représentation (police, mauvais décodage des caractères, ...). Peut-être un problème d'encodage discordant entre celui qui a enregistré et celui qui relit ? Un mauvais encodage spécifié dans la base ? ...
J'avais publié du code permettant d'afficher dans PB des données façon éditeur hexa avec hexdump_blob(), ça pourrait aider.
Je précise que cela ne vient pas de la base de données mais bien des libellés stockés dans les programmes (messagebox) ou dans les libellés des objets datawindow
Je ne comprends pas comment cela a été possible.
Et je pense que ce n'est pas possible de faire l'opération inverse.
Dernière modification par Dadone (18-03-2014 21:20:05)
Hors ligne
Dadone a écrit:
Je précise que cela ne vient pas de la base de données mais bien des libellés stockés dans les programmes (messagebox) ou dans les libellés des objets datawindow
Je ne comprends pas comment cela a été possible.
Et je pense que ce n'est pas possible de faire l'opération inverse.
Les chaînes contenues directement dans les sources *.sr? donc. Est-ce que les sources on transité sous forme textuelle par un source control ?
Dernièrement je me suis rendu compte que les accents de mes commentaires de "commit" ont été changés en caractères cyrilliques alors que j'avais modifié mes paramètres régionaux et linguistiques pour tester la compatibilité des dates manipulées par une appli PB avec des réglages exotiques (ici la Yakoutie). Il y a peut-être un problème du genre ?
Il faudrait vérifier aussi le paramètre du dernier onglet de ces paramètres linguistiques "encodage pour les programmes non unicode" qui indique quel sera l'encodage retenu lorsque des accents et autres caractères étendus non-unicodes sont manipulés par windows. Parfois on peut avoir des mauvaises surprises (par exemple chez un client avec un système chinois...) si le réglage n'est pas "français", "anglais" ou un de nos proches voisins.
Il faudrait aussi vérifier que ce n'est pas un "simple" problème d'affichage, si la police est bien celle prévue au départ (ça pourrait être changé par un thème ?). Soit le caractère n'est pas le bon, soit la police ne connaît pas les accents français.
Hors ligne
seki a écrit:
Les chaînes contenues directement dans les sources *.sr? donc. Est-ce que les sources on transité sous forme textuelle par un source control ?
Oui ce sont les bien les fichiers *.src qui sont concernés, les accents ont été physiquement remplacés.
Mais ce qui est étonnant tous les objets n'ont pas été touchés...
Et les sources ont bien transité sous un source control.
seki a écrit:
Dernièrement je me suis rendu compte que les accents de mes commentaires de "commit" ont été changés en caractères cyrilliques alors que j'avais modifié mes paramètres régionaux et linguistiques pour tester la compatibilité des dates manipulées par une appli PB avec des réglages exotiques (ici la Yakoutie). Il y a peut-être un problème du genre ?
C'est possible mais pourquoi tout les objets n'ont pas été affecté ?
Y a t-il moyen de faire machine arrière ?
seki a écrit:
Il faudrait vérifier aussi le paramètre du dernier onglet de ces paramètres linguistiques "encodage pour les programmes non unicode" qui indique quel sera l'encodage retenu lorsque des accents et autres caractères étendus non-unicodes sont manipulés par windows. Parfois on peut avoir des mauvaises surprises (par exemple chez un client avec un système chinois...) si le réglage n'est pas "français", "anglais" ou un de nos proches voisins.
J'ai regardé cette piste, je suis bien en français.
seki a écrit:
Il faudrait aussi vérifier que ce n'est pas un "simple" problème d'affichage, si la police est bien celle prévue au départ (ça pourrait être changé par un thème ?). Soit le caractère n'est pas le bon, soit la police ne connaît pas les accents français.
Tout les postes sont concernés donc je ne pense pas que cela soit un thème
Dernière modification par Dadone (19-03-2014 08:39:00)
Hors ligne
Dadone a écrit:
seki a écrit:
Dernièrement je me suis rendu compte que les accents de mes commentaires de "commit" ont été changés en caractères cyrilliques alors que j'avais modifié mes paramètres régionaux et linguistiques pour tester la compatibilité des dates manipulées par une appli PB avec des réglages exotiques (ici la Yakoutie). Il y a peut-être un problème du genre ?
C'est possible mais pourquoi tout les objets n'ont pas été affecté ?
Y a t-il moyen de faire machine arrière ?
Parce ce ne seraient que les fichiers modifiés pendant que ce réglage exotique était en vigueur ? Après la modif aurait été déployée sur les autres postes. Ce n'est qu'une hypothèse.
Il faudrait regarder dans l'historique des objets concernés si les accents ont bien changé à l'occasion de cette modif. Si c'est le cas, un subversion ou équivalent doit permettre de revenir à la version précédente, un outil de diff (tortoisemerge, winmerge ou autre peut permettre de ne reprendre que les modifs voulues entre 2 versions du fichier).
Hors ligne
Pages: 1