Reprise du message précédent :

 
Arf, la denomination chrisbk
 
bah c pas moi qui ai appelé ca comme ca, hein ? y'a bien deux maniere de charger une DLL....
 
une un peu relou mais qui te permet de bricoler (run time) et une moins ouverte mais toute simple a mettre en oeuvre
 
bon mon ptit god (je peux ? ) reste en loadtime, la comme tu fais avec le .lib+.dll et ca sera ...formidable
 
(laisse tomber cette histoire de fichier de conf, win se demerdera comme un grand...
il sait ce qu'il faut importer, et de quelle DLL . genre dans une commande dos tape :  
dumpbin monexe.exe /IMPORTS  
Suprise surpise .... enfin, ca marche que pour le loadtime ca)
 
++

chrisbk > Je crois que tu n'as pas tous compris, mais CE N'EST PAS LUI QUI FAIT LE PROGRAMME, lui il ne fais que la Dll... or le porogramme doit etre independant de la Dll... donc ton loadtime n'est tout simplement pas adapte, hors sujet...
 
De toute maniere, ce n'est pas lui qui choisit mais ceux qui font ce fichu programme. Lui ne fais qu'un Dll...
 
Je me trompe pardon de m'emporter...

C'est exact moi je ne touche pas au programme.
Ceux qui l'ont fait doivent me faire une dll pour pouvoir ajouter des menus, des boutons, et en utilisant les fonctions de cette dll je dois faire la mienne.
 
C'est encore flou pour l'instant

houla ca m'a l'air touffu ce truc
 
moi je ferme ma gueule

Je suis en train de me rendre compte que pour tester ma dll je dois mettre sans cesse le lib, la dll et le .h dans le dossier de l'exe et le recompiler.
Je crois donc que c'est pas la bonne methode parce que je ne dois pas recompiler l'exe.
Faut que je me tourne vers le LoadLibrary non ?

je croyais que tu n'avais pas le code de l'exe... ???
 
c'est celui qui fait l'exe qui choisit comment on charges la Dll...

 
je me suis mal exprime.
Effectivement je n'ai pas le code de l'exe mais on peut discuter ensemble de la meilleure facon pour importer la dll.
Moi j'ai fait un exe et une dll, pour m'entrainer.

Ta Dll est un Plug-In...
 Si tu l'utilise comme tel, tu est quasiment oblige de passer par un LoadLibrary et GetProcAddress, c'est le chargement "RunTime"...
 
Effectivement pour un test tu peu etre tente d'utiliser le .lib pour faire du chargement "LoadTime"... Ce qui est :
 

• Plus simple

• Te permet de tester valablement les fonctionnalites de ta Dll

• Ne te permet pas de tester l'interface de ta Dll

• T'oblige a recompiler (theoriquement)l'exe a chaque modif de la Dll

En effet utilisant le LoadTime, toutes le references sont resolues a la compilation d'ou recompil et erreur de compil en cas de mauvaise utilisation de l'interface.  
Si tu te trouvais en RunTime tu elimines la dependance entre l'exe et la Dll (ou tu l'inverse) mais du coup certains Pb de d'interface peuvent apparaitre si l'exe ne trouve pas les fct dans la Dll....
 
Si tu ne connais pas l'interface de ta Dll (non encore disponible) et que tes exe ne sont pas lourds, alors oui, fais du "loadTime".... fais meme directement un exe, non ?
Le fait d'etre dans une Dll ne change pas grand chose...

ok
Je vais tout faire dans un exe pour le moment, ce sera plus simple.
Merci

[edtdd]--Message édité par Godbout--[/edtdd]

..
bon je viens de lire tout ce joli post ..
 
une dll est un bout de programme qui peut etre compilé a part c bien cela ? .genre une class pour pouvoir la metre a jour sans avoir a recompiler le reste ?
 
je veux etre sur de bien comprendre

Ben si j'ai bien compris ce qu'on m'a dit c'est ca si tu charges dans ton prog la dll par un LoadLibrary et un GetProcAddress.
 
Sinon, quand tu fais un .lib, tu es oblige de recompiler l'exe avec la nouvelle lib et la nouvelle dll (et le nouveau .h si il a ete change)

Kouye a écrit a écrit : .. bon je viens de lire tout ce joli post ..   une dll est un bout de programme qui peut etre compilé a part c bien cela ? .genre une class pour pouvoir la metre a jour sans avoir a recompiler le reste ?   je veux etre sur de bien comprendre

c'est un morceau de programme comme un .lib destine a etre lie avec un executable. La difference est que cette edition des liens est faite a l'execution.
 
La dependence est en generale du cote de l'exe, c'est a dire que c'est lui qui depend de la Dll. dans ce cas changer la Dll implique de recompiler l'exe. Ces dll contiennent donc des codes supposes sur est stable partages par plusieurs executables.
 
Mais la dependance peut etre inversee, c'est a dire que c'est la Dll qui depend de l'exe, et c'est elle qui doit etre recompilee a chaque modification de l'exe. C'est le cas pour les Plug-in.

 
heuh a chaque remodif majeure tu veux dire
genre changement de l'interface de base ou ce genre de truc, parce que sinon ca deviendrait rapidement invivable

Nomalement ces developpement sont fait avec un exe stable...
 
Sinon Tout depends du niveau de dependence.  
S'il est faible, peu de Pb a attendre.
J'ai l'ai fait dans un cas ou le niveau de  dependances etait relativement eleve (une 100 de fct de l'exe exportes vers les plug-in) et la il faillait que la Dll soit chargee par l'exe corespondant au .lib utilise pour produire la Dll... ...sinon...  
comportement imprevisible...

[edtdd]--Message édité par BENB--[/edtdd]

Normalement, si c'est la dll qui depend de l'exe, on a pas besoin de recompiler l'exe.(par exemple plug in winamp)
 
Si c'est ca j'crois que j'ai tout compris

ok merci pour ces précisions