PB pour Appel fonction dans DLL sur Builder3

Voila, j'ai une DLL que je veux utiliser et qui a été développée en C semble t-il.

je déclare dans mon programme la fonction (de la DLL) comme cela:

Code:

---

1 2 3 4 5

extern void conv (struct MessIn *, struct MessOut *, int (*)(void), /* GetSecurity() */ int (*)(void), /* GetKey */ int (*)(char *, int, char *), /* GetStringFromKeyboard */ void (*)(char *, int, short)); /* pos_display() */

---

et j'ai rajouté dans le fichier prj.BPR convdll.dll qui est le nom de la dll, ce qui donne:

ALLLIB = $(LIBFILES) import32.lib cw32mt.lib convdll.dll


lors de la compilation et du make j'ai le message:

Citation:

---

[LieurErreur] Error processing module F:\PACKAGE\DLL\CONVLL.DLL.

---

lorsque j'utilise la fonction dump.exe -ee convdll.dll il me sort :
EXPORT ord:0000='conv' donc la fonction est visible ???

HELP!!!! :? :?

[Balise [code] & [quote] ajoutées par netah_25 - Merci d'y penser a l'avenir]

Bonjour,


Je ne connais pas Builder3 (je suis arrivé directement au 5...) mais n'y a-t-il pas de possibilité de passer par un .lib ??

Le pb c'est que je n'ai pas la .LIB ... mais le principe reste le même je crois ??

Ta Dll a été écrite en C ou en C++, car il y a un problème de décoration des noms en C++, fais un impdef de la Dll pour savoir.

Tu peux toujours créer le .lib à partir de la dll. Avec IMPLIB.
si les noms ont été décorées il faudra utiliser une des options (je sais plus laquelle... :oops: ).

Alors après utilisation de la commande IMPDEF le fichier .def est généré avec:

Citation:

---

LIBRARY CONVDLL.DLL

EXPORTS
conv @1

---

Après avoir changé la librairie DLL par LIB le compilateur me sort maintenant:

Citation:

---

[LieurErreur] Unresolved external '_conv' referenced from F:\C3KIT\DLL\TEST.OBJ.

---

:cry: :cry: ??

C'est sûrement une question bête mais tu as inclu le fichier .lib dans ton projet ? Je demande ça avant de chercher plus loin... :wink:


Autre vérification d'usage...

Code:

---

1 2 3 4 5

__declspec(dllexport) void WINAPI conv (struct MessIn *, struct MessOut *, int (*)(void), /* GetSecurity() */ int (*)(void), /* GetKey */ int (*)(char *, int, char *), /* GetStringFromKeyboard */ void (*)(char *, int, short)); /* pos_display() */

---

A+

Citation:

---

Envoyé par Pylz

C'est sûrement une question bête mais tu as inclu le fichier .lib dans ton projet ? Je demande ça avant de chercher plus loin... :wink:

---

Bah ça m'est pas venu tout de suite :oops: , mais le résultat est le même:

Citation:

---

[LieurErreur] Unresolved external 'conv()' referenced from F:\C3KIT\DLL\TEST.OBJ.

---

ou alors

Citation:

---

quote][LieurErreur] Unresolved external '_conv' referenced from F:\C3KIT\DLL\TEST.OBJ.

---

si je déclare la fonction par:

Code:

---

extern "C" ....

---

je suis décontenancé.... :? je vais faire un tour dans les tuto .LIB car je ne comprends plus rien :roll: c'est pourtant simple de lier un bibliothèque statique...

Résumons:

1°) inclure MaDll.lib dans le projet
2°) dans MaDll.h, declarer la fonction à exporter :

Code:

---

extern "C" __declspec(dllexport) int WINAPI FonctionDll(...);

---

3°) Dans le module d'utilisation de la dll :

Code:

---

1 2 3 4 5 6

#include "MaDll.h"   void UneFonction(...) { FonctionDll(...); }

---

Si ça marche pas comme ça, le problème vient d'ailleurs... :?

Bon courage

Alors là BRAVO ce la donne ça:

Code:

---

1 2 3 4 5 6

extern "C" __declspec(dllexport) void WINAPI conv (struct tpvMessIn *, struct tpvMessOut *, int (*)(void), /* GetSecurity() */ int (*)(void), /* GetKey */ int (*)(char *, int, char *), /* GetStringFromKeyboard */ void (*)(char *, int, short)); /* pos_display() */

---

dans le module livré il y avait aussi une LIB qui me générait ça:

Citation:

---

[LieurErreur] 'F:\C3KIT\DLL\CONV.LIB' contains invalid OMF record, type 0x21.

---

le Lib je l'ai généré depuis la DLL avec IMPLIB.EXE...

autre précision:
que l'on renseigne le fichier map avec

Citation:

---

ALLLIB = $(LIBFILES) import32.lib cw32mt.lib CONV.LIB

---

ou que l'on rajoute CONV.LIB au projet c'est pareil....

ça compile bien, ça link ya pu qu'à faire marcher..

MerciMerci

sinon pourquoi

Citation:

---

WINAPI

---

???

Ta Dll a été écrite avec Visual C ?

WINAPI est un #define de Borland qui remplace la convention d'appel de fonction __cdecl ou __stdcall (selon l'environnement...).

les conventions d'appel dispo sont __cdecl, __stdcall, __fastcall, __pascal...

Consulte l'aide de Borland à ce sujet, c'est assez bien expliqué.

Bon courage pour la suite.. :)

Et oublie pas de cliquer sur 'Resolu'...si ton problème est résolu

A+

Sinon, moi j'ai l'habitude de faire un LoadLibrary suivi d'un GetProcAdress toi tu le fais en faisant (char *)1 et ça fonctionne très bien entre Borland et Visual C.
Perso j'avais toujours pensé que c'était l'intérêt des Dll, on les charge en dynamique comme ça si elles sont défectueuses, il n'y a qu'elle à changer 8)

Bonjour,

Ce n'est pas parcequ'on utilise le .lib que la Dll est compilé avec le prog. Le fichier lib ne sert que d'interface au moment de la conception mais la dll est toujours appelée au moment de l'execution, ce qui permet effectivement d'en changer sans avoir à recompiler... du moment que les protos des fonctions exportees sont les mêmes.

Je vois au moins trois moyens principaux de charger un Dll :

Le chargement 'normal', la dll est chargée en mémoire au lancement de l'appli, ses fonctions sont exportées à ce moment là.

Le chargement retardé, la dll n'est chargée en mémoire qu'au moment de sa premiere utilisation, ce qui permet d'éviter les plantages si un dll est absente ou corompue mais qu'elle ne sert pas forcément.

Le mappage (comme tu fais avec LoadLibrary et GetProcAddress), ca ressemble au chargement retardé mais là on maitrise mieux le processus...

Dans tous les cas, la dll etv ses fonctions ne sont pas compilés avec le prog. Par contre si quelqu'un connait un moyen de faire ça, ça ça m'interesse... :wink:

A+

Ben tu vois, j'aurais au moins appris ça aujourd'hui !