Table Ascii Etendue -> Forcer le jeu de caractères [API WIN32/VISUAL] [Résolu]

Messages postés
37
Date d'inscription
jeudi 22 octobre 2009
Dernière intervention
10 décembre 2011
- 28 janv. 2010 à 03:35 - Dernière réponse :
Messages postés
37
Date d'inscription
jeudi 22 octobre 2009
Dernière intervention
10 décembre 2011
- 3 févr. 2010 à 12:12
Bonjour,

J'aurais encore une fois besoin de vos lumières si vous voulez bien m'aider.

Voici la donne :
J'ai en ma possession une petite application console, sous forme d'exe, dont je n'ai pas la source mais de la doc technique.
On m'a demandé de reproduire son fonctionnement et d'intégrer le résultat dans une application avec GUI codée en C/ApiWin32, l'unicode est désactivé pour le compilateur ainsi que pour le linker.

Mon problème :
Tout fonctionne très bien sauf une partie importante qui génère des identifiants uniques en fonction d'une chaine de caractère récupérée dans un Edit Control à l'aide de l'api GetDlgItemText().
En effet, un calcule est réalisé sur la chaine (char *) caractère par caractère avec un (unsigned char)chaineTraitee[i] dans une boucle.
Or si sous l'application console le résultat est identique chez tous nos clients quels que soit le jeu de caractère par défaut de leur OS, sous l'application GUI tous les caractères de la table ascii étendue diffèrent (par exemple le 'ç' devrait me retourner 0x87 or il me retourne la valeur française 0xE7.
Me voilà bien embêté.

Donc ma question :
Existe t'il une solution qui consisterait à forcer le jeu de caractère utilisé lors de la récupération de la chaine dans le Edit Control ?
J'ai regardé pas mal de discussion à ce sujet, mais je n'ai rien trouvé qui fonctionnait. :(
Je suis sous VS2008.

Merci à ceux qui s'intéresseront à mon soucis.

@+
Afficher la suite 

Votre réponse

2 réponses

Meilleure réponse
Messages postés
1910
Date d'inscription
vendredi 18 juin 2004
Dernière intervention
14 novembre 2014
- 3 févr. 2010 à 03:42
3
Merci
Salut,
Les fenêtres sous Windows utilisent les codes ANSI au lieu de ASCII. Ce dernier codage est justement utilisé par les applications en mode console. C'est donc normal d'avoir ce genre de comportement. Pour résoudre le problème il suffira d'utiliser la fonction CharToOem() qui convertira les codes ANSI de ta chaine de caractères en codes ASCII:
CharToOem(buffer,buffer);
buffer étant le tampon contenant le texte récupéré depuis l'Edit. Tu pourras ensuite faire ton calcul sur la chaine correctement.

Merci racpp 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 87 internautes ce mois-ci

Commenter la réponse de racpp
Messages postés
37
Date d'inscription
jeudi 22 octobre 2009
Dernière intervention
10 décembre 2011
- 3 févr. 2010 à 12:12
0
Merci
Salut racpp,

Merci pour ton explication :)

En fait quand je me suis aperçu du problème et que j'ai commencé à bricoler, j'ai essayé par deux fois sans succès d'activer le flag "CONVERT to Oem" de mon Edit Box. Je viens de réessayer à l'instant et le constat est le même, ça ne change en rien la chaîne retournée. Je n'ai donc pas orienté mes recherches vers une conversion Oem pensant qu'il devait s'agir d'autre chose.

Pour ne pas stagner, ce que j'ai fait c'est que j'ai comparé mes résultats Console et mes résultats Edit Box pour trouver exactement mes deux jeux de caractères et faire une petite table rapide de conversion.

Mais ta fonction m'aurait bien simplifié la vie et je te remercie de me l'avoir indiquée parce que comme ça au moins je suis certain du résultat (même si la mienne semblait fonctionner pour toute la batterie de chaînes à convertir que nous avons testé).

En tous cas merci de ton aide.

@+
Commenter la réponse de stagiairecpp

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.