Bonjour
Y at-il une solution pour qu'un Key:CHAR reçu par OnKeyPress au format Unicode soit converti au format ANSI local ?
Je suis avec Delphi10 et Windows10-64.
Gab
Bonjour
Y at-il une solution pour qu'un Key:CHAR reçu par OnKeyPress au format Unicode soit converti au format ANSI local ?
Je suis avec Delphi10 et Windows10-64.
Gab
Peut-être qu'il y a une autre approche
le ANSI local en France c'est Windows 1252, en gros principalement des accents et le symbole €
Quel le besoin ?
Car caster un WideChar en AnsiChar, il y a une grand possibilité d'une perte à la conversion via une fonction comme LocaleCharsFromUnicode ou CharFromWChar : SetAnsiString
Merci pour les suggestions. La question vient d'un internaute russe qui utilise un de mes logiciels ( c'est bien la 1ère fois !) et qui se plaint que les caractères cyrilliques ne sont pas traités correctement. Il est vrai que je n'ai jamais testé mes programmes dans une configuration russe de Windows !!!!
Je soupçonne que les caractères cyrilliques sont entrés en format Unicode et comme mon logiciel n'est prévu que pour traiter des caractères au format ANSI ça ne fonctionne pas. J'ai abandonné. Trop compliqué de modifier mon programme. Cdlt.
ah il est clair qu'un caractère cyrilliques n'a pas d'équivalent dans la page de code ANSI Française ! tu obtiendras au mieux un caractère ANSI dans la page de code cyrilliqueCitation:
Envoyé par f6dqm1
peut-on savoir pour quel traitement utilises tu de l'ANSI uniquement ?
C'est un programme que j'ai écrit il y a déjà fort longtemps à l'usage des radioamateurs pour apprendre et s'entrainer à lecture du morse.
Il est toujours utilisé un peu partout dans le monde par la communauté radioamateur mais je n'avais encore jamais eu de rapport venant de Russie ! Il faut dire que les communications en Morse se font normalement en anglais et en caractères latins. Le programme s'appelle CW_PLAYER. Vous le trouverez facilement sur Internet. Le programme manipule les caractères ANSI locaux pour les transformer en caractères morse standards ou spécifiques à certains pays comme les caractères accentués ou doubles. Toute l'architecture est donc faite autour d'une table de 256 caractères morse maximum (taille de la table ANSI locale). Cdlt.
ça me rappelle mon terminal 5250 :) il permet de se connecter sur un AS/400 qui utilise la table EBCDIC, j'ai donc deux tables de correspondance EBCDIC => ANSI et ANSI => EBCDIC...et mon soft a été utilisé en hébreux :) mais j'ai utilisé une astuce toute bête liée à la machine, en transférant en FTP binaire un fichier de 256 octets contenant les caractères de #0 à #255, quand je le relis en FTP texte, le système me fourni directement la table de conversion :) et dans l'autre sens pour l'autre table.
alors tu ne peux pas utiliser l'astuce FTP mais rien ne t'empêche de créer un fichier de paramètre à destination des usagés qui pourront redéfinir la "table de 256 caractères morse" en fonction de leur pays. D'ailleurs les utilisateurs pourront alors te fournir les tables adaptées comme dans mon cas http://tothpaul.free.fr/sources.php?dpribm.tn400
enfin je suppose que c'est juste une question de table de correspondance, car en fait je n'y connais rien en morse à part SOS évidemment :)
Il est possible de choisir la table ANSI par défaut pour les applications non unicode a partir du panneau de configuration ..
https://knowledgebase.progress.com/a...s/Article/4677Citation:
Open Windows Control Panel
Select Region (and Language)
Click on the "Administrative" tab
Under Language for non-Unicode programs section, click "Change System Locale" button
Select the locale
D10 ne produit pas d'application non unicode, l'astuce de wheel c'est typiquement ce que l'on faisait pour D7, on avait beaucoup de sujet sur le forum en Windows 1256 soit l'arabic charset au lieu du Windows 1252 occidental europe.
Cependant, le type AnsiString utilise la locale de l'OS, donc il est possible que la conversion Unicode vers Ansi avec un Windows 1251 soit le Cyrillic charset défini dans les options régionnales permettent de convertir l'UTF-16 de la page Cyrillic vers l'ensemble 8Bits ANSI toujours en Cyrillic
J'ignore comment est codé l'application mais il me semble assez aisé d'avoir sa constante de 256 valeurs ANSI Français, de recopier l'ensemble dans un tableau à dimension dynamique en faisant la conversion ANSI -> UNICODE
Et gérer en parallèle un fichier XML ou JSON, voire un simple INI (UTF8) qui ajoute dynamiquement un dictionnaire de caractère UNICODE, cela rendra l'application plus évolutive, sans restreinte à un jeu de caractère à la fois
Ce n'est pas si compliqué de passer de ANSI à Unicode, je l'ai fait plusieurs fois dans plusieurs sociétés, la plupart du temps avec du Chinois qui s'ajoute à l'Anglais et Français.
Faut juste jamais supposé que 1 Char = 1 Byte, en dehors de ça, rien ne change en Delphi, c'est bien plus dur en C++Builder de repasser tous les ->c_str() où il fallait modifier une chier d'endroit tous les char* en wchar_t ... en Delphi le type Char étant un alias passant de AnsiChar à WideChar, en dehors de code très poussé sur le parsage de chaine en mode octet, la transition est presque enfantine.
Bien évidemment ce n'est pas pour la version compilée par D10 mais je suppose que l'ancienne version ne supporte pas le texte unicode ... j 'ai fait un test sur la version disponible sur le net j'ai vu que certains contrôles affichent correctement le russe d'autres non :?Citation:
D10 ne produit pas d'application non unicode, l'astuce de wheel c'est typiquement ce que l'on faisait pour D7, on avait beaucoup de sujet sur le forum en Windows 1256 soit l'arabic charset au lieu du Windows 1252 occidental europe.
le contrôle TEdit ne supporte pas le texte en cyrillique par contre Edit le fait correctement.
https://www.developpez.net/forums/at...1&d=1658954890
https://www.developpez.net/forums/at...1&d=1658954868