Problem creation fichier DLL

Le
vbnet3
Bonjour,
J’ai crée un nouveaux projet DLL ActiveX puis je créée une fonction :
Public Function EstPaire(Nombre As Long) As Boolean
If (Nombre Mod 2 = 0) Then
EstPaire = True
Else
EstPaire = False
End If
End Function
Pui je click fichier - > Crée Paire.dll.
************************************************************************************************************
Puis je copier le fichier Paire.dll dans c:windwossystem32
************************************************************************************************************
Puis je crée un nouveau projet et je déclarer
Public Declare Function EstPaire Lib "paire.dll" (ByVal Nombre As Integer) As Boolean
Private Sub Command1_Click()
Dim x As Boolean
x = EstPaire(5)
MsgBox x
End Sub
Il affiche une erreur
Point d’entée EstPaire d’une DLL introuvable dans paire.dll
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Lo
Le #18236321
Salut,

JM, je me permets de nuancer ton expression de "vraies dll".

Visual Basic 6 permet de créer des DLL ActiveX qui ne sont pas de
fausses dll ;o) et qui ont pour avantage d'être utilisables dans de
nombreux langages supportant la technologie ActiveX. On peut d'autant
plus utiliser ces dll dans des pages Web (sous windows uniquement avec
IE ou une version de FireFox patchée), ce qui n'est pas le cas avec les
dll "classiques" qui exportent seulement des fonctions. Ceci étant, le
déploiement de ces librairies peut s'avérer lourd sur certaines
machines dans la mesure où elles doivent être enregistrées dans la base
de registre (ce qui requiert certains droits). On pourrait écrire 100
pages sur les avantages/désavantages des différents types de
librairies...


Sinon, pour ce qui est de l'article, très intéressant, je trouve que la
méthode permettant de récupérer chacun des noms d'export est un peu
lourde. Retrouver tous les noms de fonctions d'une librairie qui en
exporte beaucoup est assez fastidieux. D'autant plus, le jour où l’on
modifie le nombre ou le type de paramètres acceptés par une fonction,
ça va modifier également le nom "décoré".

Pour palier à ça une méthode toute simple consiste à insérer un fichier
.def avec les fichiers d'entête.

Dans le cadre de l'exemple de l'article il suffit de procéder ainsi:

- Créer un fichier à l'aide de note pad appelé samplevb.def
- Y insérer le contenu suivant:

LIBRARY samplevb


EXPORTS

IsNumberEven @ 1
- Le rajouter dans le projet écrit en C dans les fichiers d'entête.

Après compilation la fonction exportée conservera son nom d'origine.






Hello,

Pour compléter, voici l'article de la FAQ qui traite du early/late binding:
http://faq.vb.free.fr/index.php?question4

Pour vbnet3, voici également un article qui explique comment créer de vraies
DLL et appeler les fonctions créées depuis VB avec Declare ... :
http://faq.vb.free.fr/index.php?question4



--
http://www.gdpicture.com
Jean-marc
Le #18238641
Loïc Carrère wrote:
Salut,



Hello,

JM, je me permets de nuancer ton expression de "vraies dll".

Visual Basic 6 permet de créer des DLL ActiveX qui ne sont pas de
fausses dll ;o) et qui ont pour avantage d'être utilisables dans de
nombreux langages supportant la technologie ActiveX. On peut d'autant
plus utiliser ces dll dans des pages Web (sous windows uniquement avec
IE ou une version de FireFox patchée), ce qui n'est pas le cas avec
les dll "classiques" qui exportent seulement des fonctions.



C'est tout à fait exact. Peut être devrait on dire "dll classiques" ou "dll
normales",
ou "dll Windows" ou simplement "dll", je ne sais pas.
Disons juste que ces dll "classiques" sont l'équivalents des .so d'Unix
ou des COMPLIB de z/OS par exemple.

Ceci
étant, le déploiement de ces librairies peut s'avérer lourd sur
certaines machines dans la mesure où elles doivent être enregistrées
dans la base de registre (ce qui requiert certains droits). On
pourrait écrire 100 pages sur les avantages/désavantages des
différents types de librairies...



C'est clair. Perso, j'emploie les 2 types en fonction de mes besoins ou
contraintes.


Sinon, pour ce qui est de l'article, très intéressant, je trouve que
la méthode permettant de récupérer chacun des noms d'export est un peu
lourde.



Je sais :-(


Retrouver tous les noms de fonctions d'une librairie qui en
exporte beaucoup est assez fastidieux. D'autant plus, le jour où l'on
modifie le nombre ou le type de paramètres acceptés par une fonction,
ça va modifier également le nom "décoré".

Pour palier à ça une méthode toute simple consiste à insérer un
fichier .def avec les fichiers d'entête.

Dans le cadre de l'exemple de l'article il suffit de procéder ainsi:
- Créer un fichier à l'aide de note pad appelé samplevb.def
- Y insérer le contenu suivant:
LIBRARY samplevb
EXPORTS
IsNumberEven @ 1
- Le rajouter dans le projet écrit en C dans les fichiers d'entête.
Après compilation la fonction exportée conservera son nom d'origine.



C'est tout à fait clair et ton explication est limpide. Je n'avais pas
expliqué le
principe des .def pour ne pas alourdir l'article, mais à la relecture, je
pense que
l'expliquer en quelques lignes comme tu l'as fait ici est définitivement une
bonne idée.

J'incluerais donc cet ajout dans la prochaine release de la FAQ.

Merci à toi en tout cas pour le feedback sur l'article.

Bien cordialement,

--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
Publicité
Poster une réponse
Anonyme