Discussion :

[LoicH]

BOnjour à tous,

encore un nouveau soucis avec mon passage sous Builder XE10.

J'ai une erreur :

Classe d'exception EEncodingError avec un message 'Aucun mappage pour le caractère Unicode n'existe dans la page de code multi-octet cible'.

Le programme se compile très bien mais dès que je lance il me met cette erreur.

J'ai plus ou moins identifier le problème. Mais c'est compliqué.

Pour faire simple,
J'ai une FormPrincipale que je cache au lancement de l'application et une FormIdentification que j'affiche d'abord. Dans cette FormIdentification j'appelle une fonction :

void GererIdentificationChargementTux(AnsiString asTux); //Gère l'affichage du Tux passé en paramètre

Le code étant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
void GererIdentificationChargementTux(AnsiString asTux)  //Gère l'affichage du Tux passé en paramètre
{
  if(asTux != "")
  {
    TImage *Image = new TImage(0);
    TJPEGImage *pGraphTux = new TJPEGImage;
    if(FileExists(FormPrincipale->asRepertoireLogiciel+"Tux.DLL"))
    {
      HANDLE hTuxDll = LoadLibrary((FormPrincipale->asRepertoireLogiciel+"Tux.DLL").c_str());
 
      TResourceStream *Res = new TResourceStream((int)hTuxDll, asTux, RT_RCDATA);
 
      pGraphTux->LoadFromStream(Res);
      pGraphTux->Transparent = true;
      Image->Picture->Bitmap->Assign(pGraphTux);
      delete Res;
 
      FormIdentification->ImageIdentificationLogin->Visible = true;
      FormIdentification->ImageIdentificationLogin->Picture = Image->Picture;
    }
    else
      FormIdentification->ImageIdentificationLogin->Visible = false;
 
    delete Image;
    delete pGraphTux;
  }
  else
    FormIdentification->ImageIdentificationLogin->Visible = false;
}
//---------------------------------------------------------------------------

Avec cela ça plante. Après quelques tests, en mettant tout le code en commentaire, l'application se lance.

Le plus bizarre c'est que lorsque l'application plante, elle plante à la création de la FormPrincipale. Directement lors de l’exécution du constructeur où il n'y a aucuns codes. Avant même que la fonction ne soit appelée.
De plus si dans cette fonction je remplace l'AnsiString passé en paramètre par un ''int'' cela passe aussi.

Donc voila, je pense que c'est pas gagné mais si quelqu'un avait une idée,

Merci d'avance

[Pyramidev]

Bonjour.

Le plus bizarre c'est que lorsque l'application plante, elle plante à la création de la FormPrincipale. Directement lors de l’exécution du constructeur où il n'y a aucuns codes. Avant même que la fonction ne soit appelée.

En es-tu sûr ?

La première étape est d'isoler la ligne de code C++ qui lance l'exception.
Dans C++ Builder XE3, on peut configurer de telle sorte que le programme propose de s'arrêter en Debug chaque fois qu'une exception est levée, donc je pense que c'est possible aussi avec C++ Builder XE10.
Alors, tu peux afficher l'état de la pile et voir quelle ligne de code C++ lance l'exception.

Personnellement, après avoir lu ton autre fil, je soupçonne ta ligne de code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

TResourceStream *Res = new TResourceStream((int)hTuxDll, asTux, RT_RCDATA);

de prendre en paramètre un RT_RCDATA mal encodé, mais ce n'est qu'une hypothèse.

Bonne chance.

A part ça, je conseille d'utiliser des std::unique_ptr à la place des pointeurs nus sur lesquels il faut faire delete.
Comme ça, quand une exception est levée, pas de fuite mémoire.

[DjmSoftware]

Salut
Réponse identique à mon post précédent
Le portage en Unicode comporte certaines erreurs dans C++ builder que l'on ne retrouve pas dans Delphi
Par ailleurs dans ton code tu ne libère pas l'objet TResourceStream ni le Handle de ta DLL --> MemoryLeak
pour éviter de modifier tout le code déjà réalisé avec C++ builder 6 je te conseille d'utiliser des variables temporaires
de Type UnicodeString que tu initialisera avec le contenu de tes paramètres AnsiString
cdlt

[LoicH]

En es-tu sûr ?

La première étape est d'isoler la ligne de code C++ qui lance l'exception.
Dans C++ Builder XE3, on peut configurer de telle sorte que le programme propose de s'arrêter en Debug chaque fois qu'une exception est levée, donc je pense que c'est possible aussi avec C++ Builder XE10.
Alors, tu peux afficher l'état de la pile et voir quelle ligne de code C++ lance l'exception.

Personnellement, après avoir lu ton autre fil, je soupçonne ta ligne de code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

TResourceStream *Res = new TResourceStream((int)hTuxDll, asTux, RT_RCDATA);

de prendre en paramètre un RT_RCDATA mal encodé, mais ce n'est qu'une hypothèse.

Alors oui j'en suis sur. C'est bien le constructeur de la FormPrincipale qui me donne cette erreur c'est la ou le compilateur s'arrete. J'ai egalement fait du pas a pas. Comme vous j'avais cru que c'etait le TResourceStream mais après quelques tests, il s'avere que le programme plante des que j'utilise l'AnsiString passé en parametre.

Salut
Réponse identique à mon post précédent
Le portage en Unicode comporte certaines erreurs dans C++ builder que l'on ne retrouve pas dans Delphi
pour éviter de modifier tout le code déjà réalisé avec C++ builder 6 je te conseille d'utiliser des variables temporaires
de Type UnicodeString que tu initialisera avec le contenu de tes paramètres AnsiString
cdlt

C'est la ou je rebondi sur votre reponse. Etant toujours reste sur Builder 6 et n'avoir utilise que des AnsiString, je ne connaissais pas le UnicodeString.
Je vais donc essaye de mettre tout mes AnsiString en UnicodeString.

J'avais mis le parametre Mappage de _TCHAR en char. Je vais le remettre en wchar_t egalement comme tu le conseilles dans un autre post

Par ailleurs dans ton code tu ne libère pas l'objet TResourceStream ni le Handle de ta DLL --> MemoryLeak

Alors il me semble que je libere bien le TResourceStream avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

delete Res;

Mais le Handle effectivement... je ne le libere pas.

Le chemin va etre long ... en tout cas merci.

PS : desole pour le manque de tout les accents. Mais je suis au boulot avec un clavier US

[DjmSoftware]

Salut
Pour ma part pour éviter les erreurs que tu signale
je recréerais un nouveau projet dans Seattle
Le portage d'anciens projets depuis C++Builder 6 réserve parfois de mauvaises surprises
et cela t'évitera de chercher des Bugs qui sont du aux portage
Beaucoup de choses ont changés dans la définition des options de projets depuis C++ Builder 6 !!!!!

cdlt

[LoicH]

Alors légère avancée dans le problème.

J'ai repassé le paramètre de Mappage de _TCHAR en wchar_t

J'ai passé tout mes AnsiString en String et la ca passe.

Par contre cette erreur reapparait un peu plus loin lorsque j'utilise les fonctions :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
int Pos(const UnicodeString substr, const UnicodeString str);
ou
string substr(int pos = 0, int n = string::npos) const

J'utilise bien les bonnes fonctions ? ou j'aurais du garder AnsiPos() a la place de Pos().

Mais se que j'arrive toujours pas a comprendre c'est que c'est toujours au niveau du constructeur de la FormPrincipale que le compilateur plante. Et non a l'endroit du code...

DjmSoftware : Le pire c'est que je suis bien parti d'un projet vierge sous Builder XE10.

Je vais continuer a étudier tout cela. Déja j'ai avancé un peu. Si des gens ont les composants TMS, je veux bien partagé mon début de programme pour y jeter un oeil.

[LoicH]

Est-ce utile de mettre _T("") sur toutes mes chaines ? Du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
StringGridRecap->Cells[0][0] = _T("vide");
 
ou 
 
FormPrincipale->TaskDialog->Title = _T("Attention !");
 
ou même 
 
if(EditConfirmationMdP->Text != _T(""))

[DjmSoftware]

Alors légère avancée dans le problème.

J'ai repassé le paramètre de Mappage de _TCHAR en wchar_t

J'ai passé tout mes AnsiString en String et la ca passe.

Par contre cette erreur reapparait un peu plus loin lorsque j'utilise les fonctions :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
int Pos(const UnicodeString substr, const UnicodeString str);
ou
string substr(int pos = 0, int n = string::npos) const

J'utilise bien les bonnes fonctions ? ou j'aurais du garder AnsiPos() a la place de Pos().

Mais se que j'arrive toujours pas a comprendre c'est que c'est toujours au niveau du constructeur de la FormPrincipale que le compilateur plante. Et non a l'endroit du code...

DjmSoftware : Le pire c'est que je suis bien parti d'un projet vierge sous Builder XE10.

Je vais continuer a étudier tout cela. Déja j'ai avancé un peu. Si des gens ont les composants TMS, je veux bien partagé mon début de programme pour y jeter un oeil.

Salut En réponse à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
int Pos(const UnicodeString substr, const UnicodeString str);
ou
string substr(int pos = 0, int n = string::npos) const

tu peux continuer d'utiliser les mêmes fonctions que sous c++ Builder 6
le type AnsiString a été automatiquement transfromé en Unicode String et la déclaration devrait être la suivante

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
int __fastcall AnsiPos(System::UnicodeString Substr, System::UnicodeString S);

concernant ton problème d'erreur dans le constructeur de la forme principale
j'utiliserais la fonctionalité de l'EDI <Nettoyer le projet>
je te conseille d'installer si ce n'est pas encore fait la suite Gexpert http://www.gexperts.org/ qui te permettra automatiquement de nettoyer complètement un projet <Clean Directories>

Suite à l'opération de nettoyage tu reconstruit à nouveau ton projet

cdlt

[DjmSoftware]

Est-ce utile de mettre _T("") sur toutes mes chaines ? Du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
StringGridRecap->Cells[0][0] = _T("vide");
 
ou 
 
FormPrincipale->TaskDialog->Title = _T("Attention !");
 
ou même 
 
if(EditConfirmationMdP->Text != _T(""))

non c'est totalement inutile
on utilise ceci si tu veux travailler avec L'API WIn32 ou 64
ton EDI fait ce travail pour toi

et depuis RadStudio 2009 Unicode est un standard

Nouveautés de Delphi et C++Builder 2009From RAD Studio (Français)
Remonter à Prise en main - Index

Cette release contient de nombreuses fonctionnalités nouvelles et importantes pour le développement d'applications utilisant à la fois Delphi et C++Builder.

Notez que cette release est une modification importante de Delphi et C++Builder. La fonctionnalité principale de cette release est le changement de l'utilisation des chaînes ANSI en utilisation d'un type de chaîne basé sur Unicode, nommé de façon appropriée UnicodeString. Afin que Delphi ou C++Builder 2009 fonctionne sur les applications pré-existantes, vous devrez effectuer quelques modifications dans votre code, principalement associées à la gestion des chaînes, et vous devrez recompiler avec succès votre code.

A propos d'Unicode : Le standard Unicode a été adopté par de nombreux leaders de l'industrie informatique, incluant maintenant CodeGear. Unicode fournit un nombre unique pour chaque glyphe, quel que soit la plate-forme, le programme ou le langage utilisé. Selon le consortium Unicode (http://www.unicode.org), Unicode est requis par les standards modernes comme XML, Java, ECMAScript (JavaScript), LDAP, CORBA 3.0, WML, et ainsi de suite, et représente le chemin officiel pour implémenter ISO/IEC 10646. Unicode est pris en charge dans de nombreux systèmes d'exploitation, dans tous les navigateurs modernes et dans beaucoup d'autres produits. La naissance du standard Unicode et la disponibilité des outils le supportant, sont parmi les récentes tendances technologiques logicielles globales les plus significatives.

L'incorporation d'Unicode dans les applications client-serveur ou multiniveau et les sites web offre des gains de coût significatifs par rapport aux anciens jeux de caractères. Unicode permet à un produit logiciel ou à un site web d'être ciblé à travers plusieurs plate-formes, langages et pays sans re-ingénierie. Il permet le transport des données à travers différents systèmes sans corruption.

Contents
1 Unicode partout dans le produit
2 Conversion de vos projets
3 Modifications du compilateur Delphi
4 Modifications de l'EDI
5 C++Builder 2009
6 Modifications de la modélisation pour C++
7 Modifications COM
8 Débogueur
9 Base de données
9.1 dbExpress
9.2 DataSnap
10 VCL et RTL
10.1 Nouvelles classes/nouveaux composants VCL et RTL
10.2 Modifications des classes/composants VCL/RTL
10.3 Autres améliorations :
10.4 Contrôles Ruban
11 Environnement de traduction intégré/Module de traduction externe
12 Modifications de l'aide en ligne
13 Voir aussi


[edit] Unicode partout dans le produit
L'EDI est entièrement compatible Unicode, de haut en bas, de gauche à droite et d'avant en arrière. L'EDI entier est lui-même à présent une application Unicode, nécessitant que tous les composants et le code de conception soit basé sur le type UnicodeString. Les caractères Unicode sont entièrement supportés dans les identificateurs et les chaînes. Pour plus de détails, voir Unicode dans l'EDI.

Il existe quelques exceptions : Vous ne pouvez pas utiliser des caractères Unicode dans les noms de DLL. Quelques utilitaires en ligne de commande, comme MAKE, IMPDEF et IMPLIB, ne peuvent pas gérer les noms de fichiers Unicode.

La modification du type de chaîne par défaut affecte d'autres types de données ainsi que de nombreuses fonctions. Par exemple, SizeOf(Char) est maintenant de 2 octets, pas 1 octet. Les appels à Length(MyString) renvoient le nombre de caractères, pas le nombre d'octets de la chaîne.

Vous pouvez aussi utiliser Unicode dans la console de commandes en définissant les propriétés de fonte et de page de code.

cdlt

[LoicH]

Messieurs je crois que j'ai trouvé. Ou en tout cas je crois et après coup cela me semble si logique.
C'est de ma faute ...

En faite pour allez plus vite. J'ai copié les Objets de Builder 6 pour faire un collé sous XE10. Sauf que dans le lot il y avait un petit vilain canard. Builder XE10 à très bien pris l'objet mais devait comporter un paramètre dans le fichier DFM qu'il n'a pas aimé. La compilation passait sans soucis. Normal il compile pas le fichier DFM il me semble.
Donc cela explique pourquoi mon appli plantait toujours à la construction de la FormPrincipale.

En tout cas pour l'instant tout fonctionne comme ça devrait. Il me reste plus que 103 Form à migrer ...

Merci encore beaucoup de votre aide.

Je pense que vous risquez de me revoir sur un autre post...

[LoicH]

Je reviens vers vous pour une question liée a mon probleme.

En effet, des fois je compile mon programme et tout fonctionne, mais en recompilant dans la foulée sans modif il me refait des erreurs dans le fichier DFM. Sans compter un nombre impressionants de plantage de BuilderXE10.

Y a-t-il un moyen de mettre des points d'arrets dans un fichier DFM ou un moyen de trouver la ligne qui pose probleme ?

[Pyramidev]

Y a-t-il un moyen de mettre des points d'arrets dans un fichier DFM ou un moyen de trouver la ligne qui pose probleme ?

Vu que C++ Builder n'est pas fichu de signaler quelle ligne pose problème dans un fichier DFM, ça m'étonnerait beaucoup qu'il permette d'y mettre des points d'arrêt.

Personnellement, quand j'avais des erreurs dans des fichiers DFM, c'était souvent des erreurs du style "La propriété Machin n'existe pas dans la classe Bidule". Alors, dans le DFM, je cherchais tous les objets de type Bidule et, dans leurs propriétés, chaque fois que je lisais une ligne "Machin=valeur", je la supprimais.

[LoicH]

OK donc c'est pas gagné... car moi les erreurs sont beaucoup plus vague :

'Aucun mappage pour le caractère Unicode n'existe dans la page de code multi-octet cible

[Crayon]

OK donc c'est pas gagné... car moi les erreurs sont beaucoup plus vague :

Salut, l'erreur est peut-être vague, mais lorsque l'exception EEncodingError survient, regarde où le programme break et regarde aussi ta Call Stack pour savoir où tu étais avant (sans doute TEncoding.GetChars). Une chose qui est certaine c'est que l'erreur n'est pas dans un dfm. Le seul problème qui peut arriver c'est qu'un caractère dans le dfm soit Unicode et qu'il n'est pas pris en charge dans ton code. Pour gérer les exceptions il te suffit d'utiliser des try/catch à la bonne place dans ton code.

Personnellement, je préfère affecter les propriétés des composants dans le fichiers cpp plutôt que le dfm. Je trouve ça plus simple pour les outils de révision de code et le débogage.

La string en anglais tiré de System.SysConst.pas:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

  SNoMappingForUnicodeCharacter = 'No mapping for the Unicode character exists in the target multi-byte code page';

[LoicH]

Messieurs,

avec tout ces problemes aléatoires et de plantage lors de la creation du fichier DFM, j'ai contacté le support Embarcadero. Le réponse était simple : désinstaller RAD STUDIO xe10 UPDATE 1 et rester sur RAD STUDIO xe10 ou passer à XE 10.1 Berlin.

Pour ma part je suis repassé sous XE10 sans update et par magie tout mes problèmes ont disparus. Plus de soucis de plantage de l'application, plus de soucis de compilation, plus de soucis d'UNICODE, plus de soucis de passage d'un AnsiString en paramètre.

Donc je ne connais pas le soucis avec cette Update mais c'est peut etre pour cela qu'ils ont sortis XE10.1 BERLIN si vite.

Merci en tout de votre aide et bonne journée à tous