Discussion :

[frantzgac]

Bonjour

je migre un grosse application (322 sources 700.000 lignes sans les Packages) de C++Builder 6 vers 2010. Après avoir corrigé diverses erreurs de comptabilité qui bloquait la compilation j'exécute le code et comme un bogue survient je pose un trap dans le code sur un instruction innocente :

Code :

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

AnsiString s = Edit1->Text

ou Edit1 est un TEdit

Je m'aperçois que s est vide tandis que Edit1->Text ne l'est pas. Je consulte (en debug) Edit1->Text et j'obtiens le message

E2451 Symbole '_fastcall Controls::TControl::GetText()' non défini

Étonné je crée un nouveau projet dans lequel je fais la manipe suivante :

Code :

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

1
2
AnsiString s=Edit1->Text;
Button1->Caption=s;

Je constate cette fois que Edit1->Text est bien lisible mais chose étrange, bien que la valeur de Edit1->Text soit transférée dans Button1->Caption, "s" est vide ! J'essaie s.Length() et là j'obtiens

E2451 Symbole '_fastcall System::AnsiStringBase::Length()' non défini

J'en déduis que mon projet a été converti avec des options qui agissent sur les types de chaines mais je n'ai pas trouvé d'explication claire dans la doc en ligne.

[ShaiLeTroll]

Tu devrais avoir un warning sur cette ligne AnsiString s = Edit1->Text; comme conversion implicite avec perte : W1058: Transtypage de chaîne implicite avec perte de données potentielle de '%s' en '%s' (Delphi)

En fait cette ligne est équivalente à AnsiString s = AnsiString(Edit1->Text);.
Cela appelle implicitement le constructeur AnsiString(UnicodeString),
car l'opérateur = n'existe que si la forme AnsiString operator =(AnsiString).

N'utilise pas le débogueur pour cela, cela ne fonctionnait déjà pas avant !
Fait des ShowMessage ou OutputDebugString pour afficher tes tests !

Ensuite, si tu as migré le projet, par défaut il mélange ANSI pour les API Windows et UnicodeString pour la VCL
Si tu as recréé un projet, il est passer totalement en Unicode : Mappage _TCHAR

Cela fait au moins 3 ans que l'on répète inlassablement l'enjeu et l'éventuelle complexité de la migration : Comment passer en douceur de D5 à XE2 ?

Il y a toute une histoire de CodePage en fait ta chaine AnsiString contient une copie la valeur brute de l'UnicodeString avec le CodePage 65001 (sous Windows) converti par LStrFromUStr et si l'on remonte la chaine d'appel et de directive on abouti à WideCharToMultiByte

Possible que le déboggueur soit perdu, ça lui arrive souvent !

[frantzgac]

Merci

Au vu de toutes ces infos utiles j'ai investigué plus avant et j'ai constaté que :

Un projet migré (par ouverture du projet C++6) est automatiquement opté
"Mappage de _TCHar en : char"
Un projet créé de toute pièce : c'est pareil.

Je précise qu'il s'agit du C++ 2009 du RAD Studio 2009, peut être différent de XE2.

Mais ce que je n'avais pas vu c'est que le débogueur est désormais plus subtil et offre plusieurs niveaux de détails comme suit :



J'avais en fait mal localisé mon problème qui se situe au niveau d'un TDataset->Open() qui produit une division par zéro. Mais comme je pensais que la chaine SelectSQL était mal construite cela avait égaré mes recherches. Je vous tiens au courant.

[frantzgac]

La suite du problème est déplacé ici

http://www.developpez.net/forums/d12...bdataset-open/