cs_piwy
Messages postés27Date d'inscriptionmardi 6 janvier 2004StatutMembreDernière intervention 2 février 2006
-
13 janv. 2004 à 10:29
ADiranzo2
Messages postés1Date d'inscriptiondimanche 12 mars 2006StatutMembreDernière intervention12 mars 2006
-
12 mars 2006 à 17:07
bonjour ,
voila je voudrai faire une dll en visual basic. Toutes les docs que je trouve me montre bien comment lire une dll depuis vb, mais la dll est ecrite en VC++. Ce qui m'interesse la n'est pas de faire ma dll en VC++ mais en VB.net
Il doit y a voir des paramètres d'exportation pour que mes fonction puissent être accessibles depuis un programme extérieur mais je ne trouve rien.
Pour appeller ma dll depuis un programme vb c'est simple j'utilise :
declare sub test lib"C:\\MaDll.dll" ( ... )
ca c'est simple.
Ce qu'il me faudrait, c'est savoir comment ecrire ma dll en VB.net de façon a ce qu'elle soit utilisable avec l'appel comme ci-dessus
Si quelqu'un a la réponse à ma question, je l'en remercie ....
cs_piwy
Messages postés27Date d'inscriptionmardi 6 janvier 2004StatutMembreDernière intervention 2 février 2006 13 janv. 2004 à 10:49
Et bien en fait je ne suis pas sur de grand chose. Qu'entend tu par une vrai dll ?
Je commence à douter que l'on puisse faire des dll en visual basic.net ce qui m'etonnerai grandement quand même.
Pour être plus clair, je suis sur un projet multi développeur. Et dans notre organisation de travail, nous avons un module noyau qui charge diverses fonctions de diverses dll. Chaque développeur travaillant sur sa ou ses dll.
Tout simplement, puis-je faire un simple hello world (msgbox("hello world") dans une fonction d'une dll vb.net, qui est appellé ensuite depuis un autre programme vb.net ... de façon dynamique (par le code, et non pas en incluant une référence à mon projet, sinon il faut recompiler a chaque fois le module noyau qui charge les dll )
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 13 janv. 2004 à 10:55
Ce que je nomme une 'vraie' dll est une dll en code compile (C, ASM) fournissant une API, elles n'ont pas a etre enregistrees en base de registres, tu t'en sers sous forme Declare... en vb.
Je ne pense pas qu'un langage interprete puisse produire cela. Tu fais les DLLs en C et plus de probleme.
BruNews, ciao...
cs_DARKSIDIOUS
Messages postés15814Date d'inscriptionjeudi 8 août 2002StatutMembreDernière intervention 4 mars 2013130 13 janv. 2004 à 12:26
Ce que tu veux faire est possible si tu enregistre ta dll dans le registre, et en créant un lien dynamique vers ta dll par le code et non par VB directement (en passant par une variable objet par exemple)
DarK Sidious
[Responsable de la rubrique API et responsable VB du site www.ProgOtoP.com]
Vous n’avez pas trouvé la réponse que vous recherchez ?
cs_labout
Messages postés1356Date d'inscriptionsamedi 8 décembre 2001StatutMembreDernière intervention23 octobre 20068 13 janv. 2004 à 14:38
labout
Va voir les différentes DLL que j'ai mis sur le source
Boutons, ListBox, Shape etc
Si l'on compare avec VB ce serait des OCX.
Tu peux voir aussi ObjetsAcces.DLL source
OBJETS D'UNE BASE ACCESS DLL VIA OLEDB ET ADO VN.NET
qui se rapproche d'une DLL VB6
Tu n'as pas à inscrire une DLL vb.net, le fait de l'ajouter aux références de ton projet suffit.
cs_piwy
Messages postés27Date d'inscriptionmardi 6 janvier 2004StatutMembreDernière intervention 2 février 2006 14 janv. 2004 à 08:51
Effectivement, je ne souhaite pas incorporer ma dll dans mon projet, mais de faire un chargement dynamique de ma dll.
Ce n'est pas cela qui me pose probleme, c'est plutot le fait de FAIRE une vrai DLL en VB.NET qui semble compliqué. En VC++ c'est relativement simple, mais le probleme c'est que le projet est à faire en VB.net :(
J'ai vu cependant, que quand on inclut une DLL dans un projet, ce dernier ne la "fusionne" pas dans ces source. La DLL reste un fichier extérieur qui est chargé au lancement. Si on remplace cette DLL par une nouvelle, qui conserve les même fonction APPELLÉES dans l'executable, le changement fonctionne : la DLL est rechargée. C'est un petit moyen de contourner aussi, mais dés qu'une nouvelle DLL doit être inclus, ou qu'une nouvelle fonction doit être utilisée, il faut recompiler l'éxecutable principal.