Discussion :

[npze]

Bonjour à tous!
Je viens de passer de delphi 2005 à delphi 2010, et même si je savais que le changement de gestion des chaines pour

supporter l'unicode pourrait poser problème, je ne pensais pas en avoir autant.

Le contexte: J'utilise dans Access (donc en VBA) la fonction ci dessous, exportée depuis une dll.

Voici le code que j'utilise dans ma DLL (donc fonctionnel avec delphi 2005)

Code :

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

1
2
3
4
5
6
7
8
9
10
 
procedure SetDataBasePath(DatabasePath: PString; SysDatabasePath: PString); stdcall; export;
var
  DBP: String;
  SDP: String;
begin
    DBP := String(databasePath);
    SDP := string(SysDatabasePath);
    //...
end;

Voici comment elle est déclarée et utilisée dans Access:

Code :

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

1
2
3
4
5
6
 
Declare Sub SetDataBasePathA Lib "madll.ocx" Alias "SetDataBasePath" (ByVal DatabasePath As String, ByVal SysDatabasePath As String)
 
...
 
SetDataBasePathA "chemindemabaseaccess", "chemindemonfichierdesécu"

Evidemment, avec delphi 2010 cela me fait de chaines DBP et SDP vides.

Ma question est donc celle-ci: Quel type dois-je choisir pour ma fonction, et comment traiter les valeurs récupérées pour que cela fonctionne avec delphi 2010 ?

[ShaiLeTroll]

PString ? ça fonctionne ça ?
ça donne quand même pointeur de pointeur de tableau de char

Remplace par PAnsiString (PAnsiString = ^AnsiString), si tu veux conserver la même méthode

en théorie var ou const, on le même effet, passage par référence et non par valeur, bon pour les chaines en delphi c'est plus subtile, je sais que cela fonctionne très bien pour les Record et les types comme Integer, ... mais pour string, je n'utilise jamais ce type pour les DLL à cause de la même mémoire partagée (Bordelmm.dll)

D2005

Code :

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

procedure SetDataBasePath(const DatabasePath: String; const SysDatabasePath: PString); stdcall; export;

D2010

Code :

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

procedure SetDataBasePath(const DatabasePath: AnsiString; const SysDatabasePath: AnsiString); stdcall; export;

Enfin, voir si ceci fonctionne en D2005 et D2010

Code :

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

procedure SetDataBasePath(DatabasePath: PAnsiChar; SysDatabasePath: PAnsiChar); stdcall; export;

[BuzzLeclaire]

@Salut,

J'ai eu la même problèmatique récement, voilà ce que je fais actuellement.

Dans ma Dll je déclare comme cela

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
procedure Test(Base: PChar); StdCall;
Var
// ...
Begin
  Cnx := TADOConnection.Create(nil);
  try
    with Cnx do
    begin
      Provider := 'Microsoft.Jet.OLEDB.4.0';
      ConnectionString :='Data Source=' +
                          Base +
                          ';Persist Security Info=False';
// ...
end;

Et dans le soft je l'appel comme ceci (moi je suis en DLL dynamique).

Code :

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

1
2
3
4
5
6
//....
                  @Test := getprocaddress(DllInstance,'Test');
                  if Assigned(Test) then
                  begin
                    Test(PChar(Chemin_et_Base));
//...

@+

[npze]

@BuzzLeclaire :
Merci pour ta contribution mais cela ne s'applique pas du tout à mon cas (j'utilise ma dll dans VBA qui ne supporte pas unicode).

@ShaiLeTroll
Merci pour ta proposition d'utiliser directement le type Ansistring.

Maintenant j'utilise ceci dans ma déclaration, ce qui me permet de récupérer dans ma fonction des valeurs correctes sous la forme d'ansistring:

Code :

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

1
2
3
4
5
 
procedure SetDataBasePath(DatabasePath: AnsiString; SysDatabasePath: AnsiString); stdcall; export;
begin
 //...
end;

Le problème est que mes variables DatabasePath et SysDatabasePath sont maintenant des ansistring, et que je dois en faire des unicodestring pour pouvoir les utiliser avec delphi dans l'optique de support de l'unicode (et éviter de réécrire tout mon code pour lui dire de ne pas le supporter, ce qui serait idiot tout de même)...

[ShaiLeTroll]

Soit tu utilise le type string directement, mais tout vient de l'appel de le VBA, il faut que ses string à lui soit aussi en unicode !
Regarde aussi WideString qui est le type BSTR Automation, il est géré différement !

enfin, tu devrais utiliser plutôt un ActiveX (fonction en safecall), c'est plus normé qu'une DLL !
en VBS (le VBA doit être équivalent), avec CreateOleObject tu peux instancier ton objet, ensuite tu l'utilise en LateBinding ...

[npze]

Soit tu utilise le type string directement, mais tout vient de l'appel de le VBA, il faut que ses string à lui soit aussi en unicode !
Regarde aussi WideString qui est le type BSTR Automation, il est géré différement !

J'ai déjà tenté WideString, mais il est maintenant basé sur unicode dans delphi.
Pour ce qui est de gérer l'appel de la fonction en unicode dans VBA j'adorerais, mais je vois pas du tout comment il faudrait que je m'y prenne, vla la diversité des types dans Access (2000 en plus) ...

[Dr.Who]

regarde TEncoding dans SysUtils

mais logiquement tu n'as besoin que de deux types pour travailler en Ansi :
AnsiString, AnsiChar et PAnsiChar.