zero terminal et widestring

Bonjour,

J'utilise une API externe qui dialogue avec un matériel sur un port série.
La chaine hexa que je dois envoyer est la suivante : 1B FA 02 00 01 03 5E.

Là ou ça se complique c'est que la procédure externe que je dois appeler admet en argument un paramètre de type Widestring.
Du coup mon appel ressemble à ceci : ProcAAppeler(#$1B#$FA#$00#$01#$03#$5E).
La difficulté provient du zéro terminal se situant en milieu de chaine. La procédure appelée va tronquer cette donnée et la chaine hexa ne sera donc pas envoyée entièrement sur le port série.

Comment faire ?

Merci de votre aide.

Rom

Code:

---

1 2 3 4 5 6

var S: WideString; begin S := #$1B#$FA#$02#$00#$01#$03#$5E; ShowMessage(IntToStr(Length(S))); end;

---

Le ShowMessage renvoie 7, donc correct.

En fait il s'agit d'un WideString non un PWideString. ;)

@+ Claudius

Oui j'avais remarqué ça mais du coup l'API externe que j'utilise et qui attend bien en argument un widestring doit mal le gérer et tronquer les données puisque la trame envoyée sur le port série est incomplète...

Donc peut être que je cherche à résoudre un problème qui ne dépend pas de moi.

Oui sauf que Delphi c'est un malin, il stocke combien de caractère possède la chaîne ce qui fait qu'il ne s'arrête pas au premier #0 trouvé pour déclarer que c'est la fin de la chaîne.

En revanche ton API j'en doutes, elle doit utiliser la chaîne comme étant une chaîne AZT. Dans ces conditions effectivement ta chaîne est tronqué au premier #0 trouvé. Est-ce que t'on API n'attends pas que tu lui passe le nombre de caractère à lire des fois ?

Ce qui est bizarre aussi c'est pourquoi passer par un WideString pour faire transiter des données binaire plutôt qu'utiliser une combinaison PByte + nombre d'octet à lire... Est-ce que des fois ton API ne s'attend pas à recevoir '1BFA020001035E' plutôt que #$1B#$FA#$00#$01#$03#$5E (soit la représentation hexadécimale sous forme de chaîne plutôt que la valeur binaire elle-même) ?

Bonjour,
il me semble que les WideString Delphi sont l'encapsulation des BSTR de Windows.

Ce type de chaines peuvent parfois embarquer des données au lieu de caractères

Citation:

---

Envoyé par msdn

In situations where a BSTR will not be translated from ANSI to Unicode, or vice versa, you can use BSTRs to pass binary data....

---

(exemple), et donc normalement ne pas interpréter les zéros terminaux qui sont à l'intérieur de la chaîne).
Il faut dans ce cas les allouer avec SysReAllocStringLen, mais c'est normalement ce que fait Delphi

Code:

---

1 2 3 4 5 6

// unité System procedure _WStrAsg(var Dest: WideString; const Source: WideString); //[...] CALL SysReAllocStringLen //[...] end;

---

Comme dit précédement, vérifie si ton Api prend un PWideString ou WideString/BSTR.
Sinon, as tu essayé d'utiliser une variable intermédiaire comme dans l'exemple de Cl@udius ?

Code:

---

1 2 3 4

var S: WideString; begin S := #$1B#$FA#$02#$00#$01#$03#$5E; //...

---

Citation:

---

Envoyé par Cl@udius

Code:

---

1 2 3 4 5 6

var S: WideString; begin S := #$1B#$FA#$02#$00#$01#$03#$5E; ShowMessage(IntToStr(Length(S))); end;

---

Le ShowMessage renvoie 7, donc correct.

En fait il s'agit d'un WideString non un PWideString. ;)

@+ Claudius

---

C'est là l'erreur, tu insère 7 caractères mais S contient 14 octets !
Une WideString ne peut pas contenir des nombres impaires d'octets en Delphi !
On peut supposer que le choix de la WideString est parce qu'elle est alloué dans la mémoire COM, c'est juste vilain, si c'est utilisé avec une DLL non OLE ...

Essaye ça, il y a surement plus simple (par transtypage peut-être)

Code:

---

1 2 3 4 5 6 7 8 9

var SA: AnsiString; SW: WideString; begin SA := #$1B#$FA#$02#$00#$01#$03#$5E; SetLength(SW, (Length(SA) + 1) div 2); ZeroMemory(@SW[1], SizeOf(WideChar) * Length(SW)); CopyMemory(@SW[1], @SA[1], Length(SA)); ProcAAppeler(SW);

---

Version par Transtypage, mais j'ai un doute, conversion ou pas, à tester

Code:

---

1 2 3 4 5

var SA: AnsiString; begin SA := #$1B#$FA#$02#$00#$01#$03#$5E#$00#$00; // 00 en plus pour éviter des violations d'accès ... disons que c'est risqué ... ProcAAppeler(WideString(SA)); // Doute si Conversion ou Transtypage ...

---

Je reviens un peu tardivement, j'avais laissé tomber le sujet pendant quelques temps.

Mon Api externe attend bien un WideString sans pouvoir lui spécifier une quelconque longueur.

J'ai testé vos différentes solution, rien à y faire. A mon avis, la procédure externe s'arrête à #0 quoi que je lui passe.

Je vais me rapprocher du fabricant pour lui demander conseil.

Merci à vous en tout cas.

Rom

Citation:

---

Envoyé par ShaiLeTroll

C'est là l'erreur, tu insère 7 caractères mais S contient 14 octets !

---

Bien vu!
C'est vrai que les littéraux en Delphi sont typés par le contexte (ou du moins s'y adapte), contrairement au C++ par exemple ( "chaine ansi" -> char * vs L"chaine wide" -> wchar_t *, 'A' -> char vs L'W' -> wchar_t). En Delphi, 'chaine' sera Ansi ou Wide selon son affection, de même pour #$FF.
Or dans un contexte Wide, #$.. est WideChar = #$0..#$FFFF. Exemple :

Code:

---

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 32 33 34 35 36 37 38 39 40 41

procedure TForm1.Button1Click(Sender: TObject); var WStr : WideString; WC : WideChar; AStr : AnsiString; WA : AnsiChar;   RawWStr : PUBoundArray absolute WStr; RawAStr : PUBoundArray absolute AStr;   I : Integer; Msg : string; begin WStr := #$01#$02#$03#$04#$05; AStr := #$01#$02#$03#$04#$05;   Msg := 'AnsiString : '; for WA in AStr do begin Msg := Msg + IntToHex( Ord(WA), 2 ) + ' '; end; Msg := Msg + sLineBreak;   Msg := Msg + 'WideString : '; for WC in WStr do begin Msg := Msg + IntToHex( Ord(WC), 4 ) + ' '; end; Msg := Msg + sLineBreak;   Msg := Msg + 'RawAStr : '; for I:=0 to Length(AStr)*SizeOf(WA)-1 do begin Msg := Msg + IntToHex( Ord(RawAStr[I]), 2 ) + ' '; end; Msg := Msg + sLineBreak;   Msg := Msg + 'RawWStr : '; for I:=0 to Length(WStr)*SizeOf(WC)-1 do begin Msg := Msg + IntToHex( Ord(RawWStr[I]), 2 ) + ' '; end;   ShowMessage(Msg); end;

---

Affiche :
AnsiString : 01 02 03 04 05
WideString : 0001 0002 0003 0004 0005
RawAStr : 01 02 03 04 05
RawWStr : 01 00 02 00 03 00 04 00 05
Une solution (mais pas très lisible)

Code:

---

1 2 3 4 5

begin WStr := #$0201#$0403#$05; AStr := #$01#$02#$03#$04#$05; end;

---

Sinon la solution de ShaiLeTroll avec SetLength me semble bonne. Tu peux en faire une fonction du type

Code:

---

1 2 3 4 5 6 7 8 9

function DataToWideString( var Data; Count : Integer ): WideString; begin SetLength( Result, (Count+1) div 2 ); if Count mod 2 = 1 then begin Result[Length(Result)]:=#0; end; Move( Data, Result[1], Count); end;

---

Ou on peut aussi essayer de passer par les Api Windows (après test ce code semble bon)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

// vrai signature function __SysAllocStringByteLen( Data : PAnsiChar; len : Cardinal ) : PWideChar; stdcall; external 'oleaut32.dll' name 'SysAllocStringByteLen';   function SysAllocStringByteLen( Data : PAnsiChar; len : Cardinal ) : WideString; // inline; entraine une copie de chaine supplémentaire (?!?) mais libérée begin Pointer(Result) := __SysAllocStringByteLen( Data, len ); end;   function SysAllocStringData( var Data ; len : Cardinal ) : WideString; begin Pointer(Result) := __SysAllocStringByteLen( PAnsiChar(@Data), len ); end;

---

:alerte: attention ne pas faire directement

Code:

---

1 2	function SysAllocStringByteLen( Data : PAnsiChar; len : Cardinal ) : WideString; stdcall; external 'oleaut32.dll' name 'SysAllocStringByteLen';

---

Car en paramètre de sortie Delphi ne passe pas un WideString comme un pointeur (directement dans eax) mais en tant que paramètre var supplémentaire (ce qui change complètement la signature de la fonction avec de jolis Acess Violation à l'exécution :aie:)

Citation:

---

• Les résultats scalaires sont renvoyés, quand c'est possible, dans un registre CPU : les octets sont renvoyés dans AL, les mots dans AX, les doubles mots dans EAX.

• Pour un résultat chaîne, tableau dynamique, pointeur de méthode ou variant, les effets sont les mêmes que si le résultat de la fonction était déclaré en tant que paramètre var supplémentaire suivant les paramètres déclarés. En d'autres termes, l'appelant passe un pointeur 32 bits supplémentaire qui pointe sur une variable dans laquelle le résultat de la fonction doit être renvoyé.

---

D'où la fonction intermédiaire __SysAllocStringByteLen/SysAllocStringByteLen. Mais si la données a un nombre impaire d'octets, elle sera tronqué par l'Api (dernier octet).

Oh, tu as vraiement poussé le sujet sur l'allocation des chaines dans la mémoire COM ...

C'est tout de même une étrange fonction dans cette DLL, pour écrire sur un port, un PByte aurait tellement été plus simple et plus pertinent ... on sent vraiement la grosse panique pour la gestion de la mémoire d'un tableau de Byte soulagée par la gestion d'une OleSTR ... baaah ...

En tout cas, ravi de t'avoir aidé, un petit :resolu:

Citation:

---

Envoyé par ShaiLeTroll

C'est tout de même une étrange fonction dans cette DLL, pour écrire sur un port, un PByte aurait tellement été plus simple et plus pertinent ... on sent vraiement la grosse panique pour la gestion de la mémoire d'un tableau de Byte soulagée par la gestion d'une OleSTR ... baaah ...

---

Je suis d'accord, mais comme je l'ai dit plus haut, même Microsoft a utilisé cette technique pour SendOnVirtualChannel. Et là, le gag, c'est que Visual Studio (que j'ai du utiliser), avec les MFC (:ouin::ouin::ouin:), transforme la méthode de l'ActiveX en changeant les BStr en CString, ce qui ne facilite déjà pas le passage de données, surtout quand une conversion Ansi -> Unicode est réalisée systématiquement pour les CString en mode de compilation Ansi :aie:. En Delphi, pas de problème, le BStr est bien directement transmis à la méthode (sans conversion).

Citation:

---

Envoyé par ShaiLeTroll

un petit :resolu:

---

:oops: C'est à l'auteur de ce sujet de décider :mrgreen:.