Discussion :

[Skape252]

Bonjour, je développe actuellement un addon Outlook et je suis bloqué sur le partie transfert de Variable de la DLL vers mon addon.
Ma DLL est censé me retourner un PAnsiChar :

Code :

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

1
2
res := PAnsiChar(AnsiString(s));
Result := res;

Seulement dans mon code VB je ne sais comment la récupérer. J'ai essayé la solution suivante mais l'application plante :

Code :

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

1
2
3
Declare Function AjoutMail Lib "DLMDLL.dll" Alias "Ajouter_une_piece_jointe_a_un_mail" () As String
Dim temp As Object
temp = AjoutMail()

Merci de vos réponses

[Ph. B.]

Bonjour,

Bonjour, je développe actuellement un addon Outlook et je suis bloqué sur le partie transfert de Variable de la DLL vers mon addon.
Ma DLL est censé me retourner un PAnsiChar :

Code :

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

1
2
res := PAnsiChar(AnsiString(s));
Result := res;

Seulement dans mon code VB je ne sais comment la récupérer. J'ai essayé la solution suivante mais l'application plante :

Code :

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

1
2
3
Declare Function AjoutMail Lib "DLMDLL.dll" Alias "Ajouter_une_piece_jointe_a_un_mail" () As String
Dim temp As Object
temp = AjoutMail()

Quelques remarques :

• Temp est un object alors que la fonction renvoie un string
• Delphi natif ou managé ? Visual Basic natif ou managé ? VBA ?
• Une fonction qui renvoie une chaine ne me parait pas la meilleure façon de faire quand il s'agit de dll, en particulier entre 2 environnements de développements. J'utiliserais plutôt une procédure à laquelle on passe des variables PChar initialisées et gérées côté client (en l'occurrence ByRef String. Est ce une dll que vous avez écrite et dont vous avez les sources ?

[Skape252]

Bonjour,
Quelques remarques :

• Temp est un object alors que la fonction renvoie un string
• Delphi natif ou managé ? Visual Basic natif ou managé ? VBA ?
• Une fonction qui renvoie une chaine ne me parait pas la meilleure façon de faire quand il s'agit de dll, en particulier entre 2 environnements de développements. J'utiliserais plutôt une procédure à laquelle on passe des variables PChar initialisées et gérées côté client (en l'occurrence ByRef String. Est ce une dll que vous avez écrite et dont vous avez les sources ?

Tout d'abord merci de votre réponse.
Pour l'objet temp c'est une omission de ma pars.
Je développe sous Delphi 2010 et Visual Studio 2010, aucune idée s'il sagit de natif ou managé.
Le problème c'est qu'en effet je n'ai pas écrit cette DLL, il me serait alors compliqué de tout reprendre pour remplacer la fonction par une procédure.
J'ai cru comprendre que la solution pour réaliser ce passage de variable était d'utiliser les BSTR, mais je n'arrive pas à le mettre en oeuvre.

[ShaiLeTroll]

Attention, il faut penser au partage mémoire
Une fonction ne peut JAMAIS renvoyer de PChar directement si il n'utilise pas un gestionnaire de mémoire partagée tel que ShareMem, FastShareMem (Delphi\C++Builder) ou COMString (tout langage gérant BSTR OLE)

Il faut que ce soit l'appelant qui fournisse la zone mémoire approprié avec la taille maximale (incluant le zéro terminal)
Avec un retour de PChar, Delphi alloue la mémoire mais qui la libère ?
VB impossible => Erreur de Privilège ou Violation d'Accès

Pour info :
"natif ou managé" c'est un manière élégante pour désigner "Win32 ou .NET"

En plus PChar en D2010 = PWideChar = 2 octets par caractère, à ne pas oublier lors de l'utilisation en VB

[Skape252]

Dans mon cas, c'est mon complément en VB(.net) qui appelle la DLL.
Il faudrait donc que je définisse la zone mémoire dans mon programme VB. Et que mon application delphi renvoi un PWideChar ?!

[ShaiLeTroll]

Dans mon cas, c'est mon complément en VB(.net) qui appelle la DLL.

Donc managé !

Il faudrait donc que je définisse la zone mémoire dans mon programme VB.

Voir Interoperating with Unmanaged Code - Consuming Unmanaged DLL Functions
Voir GCHandle, GCHandle.Alloc, GCHandle.ToIntPtr

Et que mon application delphi renvoi un PWideChar ?!

Ce n'est pas ce que je disais, Delphi 2010 utilise par défaut le PWideChar via l'alias PChar, faut juste en avoir conscience !

VB.Net utilise le même encodage normalement, StrLCopy fera très bien le boulot

Tu peux en retour renvoyé le nombre de caractère, un peu comme l'API windows, GetWindowText

Code :

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

1
2
3
4
5
6
function Ajouter_une_piece_jointe_a_un_mail(lpString: PChar; nMaxCount: integer): integer;
begin
  // s est une chaine interne de la DLL qui contient déjà quelque chose
  CopyLStr(lpString, s, nMaxCount - 1);
  Result := Math.Min(Length(s), nMaxCount - 1);
end;

Pour, la version BSTR OLEChar, le type Delphi c'est WideString qui encapsule les API Windows qui gère un compteur de référence ...

Code :

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

1
2
3
4
5
function Ajouter_une_piece_jointe_a_un_mail(): WideString;
begin
  // s est une chaine interne de la DLL qui contient déjà quelque chose
  Result := s;
end;

J'ignore totalement comment mappé cela en VB.NET !
Le WideString, je l'utilise avec une TLB qui est utilisé en COM sous Delphi ou considéré presque comme une Assembly par .NET

[Ph. B.]

Dans mon cas, c'est mon complément en VB(.net) qui appelle la DLL.
Il faudrait donc que je définisse la zone mémoire dans mon programme VB. Et que mon application delphi renvoi un PWideChar ?!

Oui, allouer la mémoire sous vb.net puis passer les pointeurs à la procédure de la dll qui les "alimente".

Concernant les String, vous avez la possibilité de préciser le jeu de caractères, Vous pouvez aussi préciser la convention d'appel.

Code vb :

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

<DllImport("Votre.dll", CharSet:=CharSet.Ansi, CallingConvention:=CallingConvention.StdCall)>

Voici un lien (en anglais) plus détaillé : Utiliser une dll Pascal avec .Net