Discussion :

[Invité]

Bonjour,

je cherche de la documentation récente sur l'utilisation des diverses formes de strings. (AnsiString, UTF8String...)

Un de mes anciens programmes fonctionne sous Lazarus avec des librairies dynamiques (.dll ou .so) écrites elles aussi en Lazarus. L'ensemble est compilé en 0.9.28. RAS.

J'ai voulu recompiler l'ensemble (dll et programme) en 0.9.29. Et j'ai quelques soucis avec les pChar(string).

J'obtiens fréquemment (mais pas systématiquement ?) des messages du genre...
fwaformX.pas(597,34) Error: Illegal type conversion: "ShortString" to "^Char"
Le code de la dll suivant:

Code :

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

1
2
3
4
5
6
7
8
function IsLengthOK(pReq : PChar) : boolean; cdecl; //ou stdcall;   
var
 sREQtmp : String;
begin
 Result := False;
 sREQtmp := pReq;
 if length(sREQtmp) > 4 then Result := True;
end;

...appelé ainsi par le programme

Code :

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

1
2
3
4
5
6
 
var
 sREQ : String;
begin
[...]
 if not IsLengthOK(pChar(sREQ)) then

...génère l'erreur.

En 0.9.29, j'ai essayé l'option {$H+}{$LongString On} que je n'utilisais pas en 0.9.28 : sans succès. Mais, si je remplace "sReq : String;" par "sReq : AnsiString;" ou par "sReq : UTF8String;", il n'y a pas de problème... Jusqu'à présent, je pensais que String ~ LongString et pas ShortString... Est-ce que c'est une évolution de Lazarus ? A la rigueur, je m'en moque... à condition que je puisse "mesurer" l'implication dans mes programmes de l'utilisation de AnsiString et UTF8String sachant qu'ils doivent fonctionner sous Win et Nux... et là j'ai du mal à réellement comprendre la théorie Lazarusienne sur la question et reste toujours en pratique très "expérimental" sur certains composants avec les UTF8Toxxx.

Bref, quelqu'un a une idée précise sur la question des pchar(string) ?

Merci d'avance.
Cordialement. Gilles

[Invité]

Bonjour,

J'ai un petit peu progressé mais je n'y comprends toujours rien.

Ce code

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
function IsLengthOK(pReq : PChar) : boolean;
var
 sREQtmp : String;
begin
 Result := False;
 sREQtmp := pReq;
 if length(sREQtmp) > 4 then Result := True;
end;
 
{ TForm1 }
procedure TForm1.Button1Click(Sender: TObject);
var
 sREQ : String;
begin
 sReq := '123';
 if not IsLengthOK(pChar(sREQ)) then
  showmessage('OK')
 else
  showmessage('No');
end;

Dans un programme contenant une simple TForm1, ce code fonctionne avec ma Lazarus 0.9.28.3 sous XP... et fonctionne aussi compilé avec une 0.9.29.

Je copie cette forme dans le programme de départ qui utilise avec succès des dll (compilées en 0.9.28) et elle plante avec l'erreur mentionnée ci-dessus.

J'ai comparé les options du projet 0.9.29 avec la seule Form1 avec celles du projet "complet" ... elles sont semblables. C'est tout de même bizarre.

Cordialement. Gilles

[dragonno]

Dans le topic "Lazarus est-il utilisable par le monde professionnel" ou un truc qui y ressemble, il y a une discussion à propos de bugs de Lazarus avec l'utilisation des types de strings (utf8 et Cie) peut-être que c'est lié ?

Là :

http://www.developpez.net/forums/d74...l/#post4386745

[batyann811]

A ma connaissance :

• Le type UTF8String est équivalent à AnsiString.
• La conversion directe de ShortString vers PChar est interdite car les chaînes courtes n'ont pas de caractère NUL à la fin. Il faut donc réaliser une conversion explicite et couteuse par StrNew (libérer avec StrDispose).
• La conversion AnsiString -> PChar est autorisée car les chaînes longues ont un caractère NUL final.
• Le type String peut être soit AnsiString soit ShortString selon les options de compilation et les directives présentes dans le source.

Es-tu certain que ta dll et ton programme ont bien la même définition du type String ? Les chaînes String sont elles bien des chaînes longues dans ton programme et ta dll ? N'oublie pas qu'outre les options passées au compilateur des directives dans le code ($H, $longtsrings, $mode) peuvent avoir une influence.

Pour t'en assurer tu peux utiliser SizeOf(String). Si tu obtiens 256 c'est que tes chaînes par défaut sont des chaines courtes si tu obtiens 4 ou 8 c'est que ce sont des chaînes longues. Teste SizeOf(String) dans ton programme et dans ta dll pour voir si les deux utilisent bien des chaînes longues.

[Invité]

Bonjour Dragonno,

Oui je me souviens de cette discussion. Le problème est identifié depuis longtemps sur certains composants et jusqu'à présent "on" arrive à corriger le tir même si parfois la logique fait place aux tâtonnements...

Dans le cas présent, ce n'est pas un composant qui est concerné mais le type string lui-même... Je n'avais jamais rencontré ce problème.
Je viens d'installer la lazarus 0.9.29-27844-fpc-2.4.3-20101025-win32. J'ai recompilé le code : même problème. Dans un nouveau projet, j'ai recréé une fenêtre, placer le code incriminé -mais pas l'environnement (les dll)- et là, pas de problème. Ce sont exactement les mêmes options (notamment de compilation) pour les 2 projets... Je vais porter mes fenêtres et mes dll, une par une, de l'ancien vers le nouveau projet jusqu'à ce que j'obtienne le même plantage. J'espère y voir plus clair alors.

Cordialement. Gilles

[Invité]

Bonjour Batyann811,

Oui,

ce sont en effet des chaînes courtes (Showmessage(IntToStr(SizeOf(sREQ)))-->256) dans le "programme qui plante" mais pourquoi ?

Je continue à déménager le code dans un projet vierge qui affiche ... Showmessage(IntToStr(SizeOf(sREQ)))-->4 Par contre, je n'ai pas eu la curiosité de voir ce qui se passe sous Nux... Ces vacances scolaires tombent bien finalement
Cordialement. Gilles

[batyann811]

Si "Projets > Options du compilateur > Afficher les options" te donne exactement la même réponse dans les 2 projets c'est que tu dois avoir une ou des directives de compilations qui modifient le type des chaînes par défaut.

Sous réserve, les directives concernées sont :

• {$longstrings} et {$h}
• {$mode} certains modes imposent des chaînes courtes (tp, fpc) d'autres des chaînes longues (objfpc, delphi)
• {$modeswitch ansistrings}

[Invité]

Bonsoir,

Petit point avant d'arrêter pour ce soir.

J'ai "recréé" 50% des fenêtres dans la nouvelle version (en lazarus 0.9.29-27844-fpc-2.4.3-20101025) après avoir recompilé les .dll (qui étaient en 0.9.28). RAS, sans modifier le code -à ce niveau- cela fonctionne bien.

...Mais (faut bien un mais), j'ai un nouveau problème inattendu avec i18n... De toute façon, il fallait que je revisite le "problème' :
Rien à dire avec le

Code :

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

1
2
Translations.TranslateUnitResourceStrings('LCLStrConsts', gsPODirectory +
                  'lclstrconsts.'+gsFallbackLang+'.po', gsLang, gsFallbackLang);

Les lclstrconsts.xx.po sont déjà constitués (Cela traduit les messages système).

Par contre, lorsqu'on génère, les .po du programme lui-même avec les lfm... C'est un bazar "immense"... Et si on les fait à la main, autant trouver autre chose... si c'est possible...

Bon, je mets résolu... mais je n'ai pas d'explication valable. En attendant méfiant, j'ai placé un petit signal d'alarme dans mes fenêtres qui contrôle que mes SizeOf(String)<>256. On ne sait jamais... et je trouverai peut-être alors la cause...

Merci pour votre aide.
Cordialement. Gilles

[Invité]

Bonjour,

Shame on me.... j'ai manqué l'inmanquable :

Il manque dans deux de mes units récentes : {$H+}. J'ai vérifié presque toutes les Forms y compris ... une unité nouvelle d'il y a quelques jours appelée par les Forms "défaillantes" (uses uxxxxxs.pas) mais sans vérifier ce problème "inattendu" et quasiment improbable.

D'un autre côté, après vérification, je constate que lors de la compilation, l'activation du -Sh dans les Options du compilateur n'est pas prioritaire sur l'absence de {$H+} dans le code de la fenêtre. Autrement dit, elle ne change rien dans le comportement des fenêtres après re-compilation. Quelle est son utilité alors ? Il semble que l'activation du -Sh (ou sa désactivation) ne serve qu'au moment de la création de la fenêtre : si l'option -Sh est activée alors, la fenêtre est créée {$mode objfpc}{$H+} sinon elle est créée en mode {$mode objfpc} (donc avec String = ShortString). Et cela se limite à cette action.

Comment cette erreur est-elle arrivée alors que je savais pertinemment ne pas avoir modifié les options de compilation ?

Comme j'installe toutes les releases régulièrement, alors que toutes jusqu'à présent activent par défaut -Sh, il y en a une qui ne l'active pas par défaut.(! ?)... Et je l'ai utilisée pour créer les fameuses units... Bref... inmanquable mais complètement inattendu... Et indétectable sauf à analyser le code -ce que j'ai fait sans voir ce "manque que j'avoue avoir éliminé de prime abord puisque je savais ne rien avoir changé, ni dans le code lui-même [enlever {+}], ni dans mes paramétrages usuels [par défaut]. D'autant que sur la dernière version "compilée avec la dernière version de Lazarus, le -Sh du projet est activé sans toujours rien changer ...

Donc maintenant, c'est résolu. La réponse était dans vos réponses... mais le poids des certitudes erronées (modification après recompilation si on change cette option de compilation -je me méfierai maintenant) et l'usage intensif des assistants (qui placent les modes en tête de Unit) pratiques mais auxquels on ne fait plus attention... m'ont fait perdre une journée...

Donc désolé pour le dérangement et encore merci pour votre aide...
Cordialement. Gilles

[Invité]

Bonjour,

Petite précision : le problème avait été signalé une première fois sur le bug tracker le 23/09/2010... et je ne l'avais pas vu. Mais aujourd'hui en début de PM, un CR de résolution est paru... et cette fois, sensibilisé par le problème , il ne m'a pas échappé : le problème a été corrigé et a même donné lieu à une amélioration dans la dernière 0.9.29 SVN : http://bugs.freepascal.org/view.php?id=17473

Cordialement. Gilles