Discussion :

[Steff2]

Bonjour,

Il semble que la directive sdtcall provoque des erreurs quand on crée un DLL.
Peut-être qu'il faut changer le type de paramètres ?

exemple :

Function CreateFichier(Nom : string):Boolean;export;

fonctionne très bien

mais

Function CreateFichier(Nom : string):Boolean;stdcall;export;

génère une erreur quand l'exécutable appelant ferme. J'ai même tenté un type Pchar pour le paramètre.

Si je veux que VB (ou autre) utilise ma DLL il me faut stdcall pour compatibilité non ?

[Lung]

Moi, pour ma DLL, j'ai utilisé stdcall sans problème.
Testé avec un exe Delphi et un exe C++

D'après l'aide de Delphi, ça fait en sorte que les paramètres soient traités dans le bon ordre.

Par contre, j'ai été obligé d'utiliser PChar pour les chaînes de caractères.

[Paul TOTH]

Bonjour,

Il semble que la directive sdtcall provoque des erreurs quand on crée un DLL.
Peut-être qu'il faut changer le type de paramètres ?

exemple :

fonctionne très bien

mais

génère une erreur quand l'exécutable appelant ferme. J'ai même tenté un type Pchar pour le paramètre.

Si je veux que VB (ou autre) utilise ma DLL il me faut stdcall pour compatibilité non ?

la convention d'appel importe peu...pour peu que l'EXE et le DLL utilisent les mêmes. Le C utilise cdecl par défaut me semble-t-il.

quand à l'usage d'un STRING par un exe VB c'est niet !

au niveau Delphi il faut déclarer un PCHAR et au niveau VB un STRING BYREF

[Steff2]

ok,
je vous remercie à tous.

Je vais faire des test sans stdcall avec VB et c++

[sjrd]

Si tu fais de l'inter-langage, tu ne peux pas utiliser register, la convention par défaut de Delphi. En effet, la convention register est la convention "fast-call" de Delphi, et les conventions fast-call sont différentes dans chaque langage.

Il faut utiliser une autre convention (stdcall, safecall, cdecl ou pascal), mais pas register, car register n'a pas d'équivalent dans VB ou C++.

[Steff2]

ok merci,

pour register je savais.
mon problème est que normalement même avec stdcall ou autre cela ne devrait pas planter. Du moins, c'est la première fois que ça m'arrive.

ça plante toujours à la sortie de la fonction ou procédure. je pense qu'il y a un pointeur qui se perd

[rt15]

Salut,

Déjà, confirmation, pour que ce soit compatible avec Visual Basic 6, il FAUT que la convention soit stdcall (Sauf si on fait du COM, bien entendu).

Pour ce qui est de l'emploi de chaînes, il est très dangereux d'utiliser le type String de Delphi. En effet, ce type utilise le gestionnaire de mémoire de Delphi pour allouer ces chaînes, et est donc le seul abilité à les libérer (C'est pour ça qu'il faut mettre ShareMem lors d'un dev avec exe+dll en Delphi : pour que le gestionnaire de mémoire soit commun à l'exe et à la dll).

Comme tu ne peux pas mettre ShareMeme dans les uses de VB , il faut que tu alloue et libère tes chaînes que d'un seul côté, comme ça se fait dans l'API Windows, ou c'est très souvent l'exe qui passe en paramètre un buffer avec sa taille. Le buffer est ensuite rempli par la dll, et c'est l'exe qui se chargerat de la libération du buffer à un moment ou à un autre.Dans ces cas là, on utilise effectivement un PChar comme signalé plus haut, mais on passe les arguments ByVal. Avec Un String ByRef, on passerait plutôt un pointeur sur un pointeur sur la chaine. Alors que notre PChar est un pointeur sur la chaîne.

Autre solution : utiliser SysAllocString et consort, ce qui est ce qui est utilisé par VB6 pour allouer ces chaînes en interne. Comme c'est Windows qui se charge de l'allocation (Certainement avec un LocalAlloc ou GlobalAlloc), aucun problème : VB6 pourrat traiter cette chaîne comme s'il l'avait alloué lui même.