Salut,
 
Je suis victime d'un probleme vraiment bizarre, mon but étant de créer une Dll avec VC++ 6  et ensuite de l'utiliser avec Access. Cette dll se contente de retourner, a travers une fonction, un entier = 5 !
 
Alors, je crée cette dll (MFC dll-> regular Dll). Elle compile tres bien ! Alors, sur le meme ordinateur, j'y fait appel comme ceci :
 

 
tout en prenant soin de copier la dll générée sur C:\ !
 
Ensuite, je lance mon programme avec Access (VBA) et tout marche bien , le nombre est bien récupéré à partir de la dll !
 
Alors, l'idée me vient d'essayer cette dll sur un autre ordi, ne contenant pas Visual Studio, mais contenant Access ! Je fais la meme procédure, et la il me dit :
 
"Run-time error '53':
 
File not found : c:\forVB.dll"
 
Vraiment incroyable !  
 
Alors, juste pour le fun, je prends une dll quelconque de Windows (ici en loccurence aclui.dll), et je la copie sur c:\ tout en la renommant ForVB.dll !  
 
Et là, lorsque je lance mon programme Access, ca "marche", enfin, il me dit : "Can't find DLL Entry Point AfficherMessage...." ce qui pouve qu'il voit bien la DLL !
 
Est ce que vous arrivez à comprendre et m'expliquer la cause de tout ca? Est ce que ca vient du fait que je n'ai pas Visual Studio sur mon autre ordi?
 
Merci, Yoyo*

 
 
ben tu mets ta dll ForVB.dll dans le c:\ de l'autre PC (et la bonne hein, pas un vieux traficouillage comme tu nous as fait)
 
la vc il est y pour pas grand chose
 

 
Bah, justement, c'est ce que je te dis : quand je mets la bonne ForVB.dll sur le C:\ de l'autre PC, il ne la voit pas, alors que quand je prends une dll quelconque de Windows, et que je la renomme en forVB.dll et que la mets sur c:\, il la voit m(ais ne peut l'utiliser of course !!)

C'est exprès les variations au niveau de la 1ere lettre?
Une fois c'est f une fois c'est F...

 
Non, j'ai vérifié, j'ai bien mis "ForVB.dll" de partout !
 
Ce n'est donc pas un probleme de casse !

Le plus simple est de virer le c:\ devant ton nom, et de mettre ta dll soit dans system32, soit dans le répertoire d'Access. C'est un probleme avec Access / VBA, et moi Access ...

 
Voilà, je viens de le faire...
 
J'ai donc remplacé mon code par :  
 

 
Et j'ai copié le fichier en question dans c:\windows\System32
 
Résultats :
1er PC : marche très bien
2eme PC : ne marche pas (meme symptome : File not Found !)
 
Vraiment chelou tout ça !

Bon, voila, j'ai trouvé une solution à mon probleme...
 
En fait, la dll dont je vous ai parlée, je l'ai crée en faisant New Project => MFC AppWizard (dll) et en regardant les dependencies (utilitaire depends.exe de VS), il me disait : MSVCRTTD.DLL, KERNEL32.DLL, MFC42D.DLL
 
Là, je viens de créer la meme Dll, mais en utilisant New Project => Win32 Dynamic-Link Library, et làdepends.exe me donne comme dépendance seulement KERNEL32.DLL !
 
Donc, comme je le pressentais, ma premiere dll ne maarchait pas sur mon ordi sans Visual Studio, car elle avait besoin de MFC42D.DL pour fonctionner (sans doute installé avec Visual Studio???)
 
Voilà !
 
Si vous avez des commenaires la dessus, n'hésitez pas !
 
Yoyo*

T'as peu eu de bol alors, t'es tombé sur un message d'erreur a la con. A priori il a pas pu loader la dll (car les dependances n'ont pas pu etre assuree) et en a conclu que s'il a pas pu loader la dll c t parce qu'elle n'existait pas
 
(sorry pour mon premier post j'avais mal compris ton souc)
 
Neanmoins, MFC42D est comme son D l'indique une DLL de debug, essaye de compiler ta DLL en release et de voir si ca marche comme ca

 
Parfait, ca marche
 
En fait, j'avais bien compris que tu n'avais pas trop compris ce que je disais( au vu de ta réponse), c'est donc pour ca que je t'avais répondu !
 
Sinon, comme tu dis, c'est "pas de bol", le prog me faisait croire qu'il ne trouvait pas le fihier, mais je me suis déouté que c'était pas vraiment le cas, et c'était d'ailleurs pour ca que j'avais pris un dll quelconque et renommé avec le nom de la dll que j'avais créée, et la, il m'a sorti une autre erreur !
 
En fait, je ne te cache pas que je ne connais aps encore beaucoup Visual C++ (j'ai pas assez d'expérience avec) et que je ne savais meme pas vraiment qu'il était possibl de créer des composants en debug ou en release (et d'ailleurs,q uelle est en gros la différence? La possibilité de debugger lorsque tu lances ton prog sous VS??), et je viens juste de découvrir qu'on pouvait changer ca en changeant "Set Active Configuration"
 
Donc, maintenant, ma Dll utilise MFC42.dll, MSVCRT.dll et Kernel32.dll
 
Est ce que ca veut dire qu'elle devrait normalement pouvoir tourner sous nimporte quel PC ayant Windows > 98?
 
D'autre part, en faisant un Win32 DLL, il n'y a plus toutes ces dépendances, seulement Kernel32.dll ! A quoi peuvent donc me servir les MFC? Ce serait par exemple pour les dialogues, ou les trucs du genre?
 
Merci en tout cas, j'y vois vraiment plus clair la dessus !

ben debug comme son nom l'indique c du debug : aucune optim et visu insere des infos dans ton prog pour s'y retrouver.
release il optimise, vire l'inutile et tout ca
 
MFC42.dll, MSVCRT.dll sont fournies depuis pas mal de tps avec win, donc pas de soucis. Les MFC un ensemble de classe facilitant la creation d'appli (gestion des fenetres/composant et tout ce barda)

 
D'accord, c'est tres clair !
 
Et est ce que par exemple, les données du type CString font parties aussi du MFC? Et est ce que cette dll a évolué avec les versions de Windows (risques d'incompatbilités??)

Oui, tout ce qui est MFC (CString, Cxxx, ...) est dans la dll MFC. msvcrt c'est la runtime C, c'est les fonctions standards du C.
Ces dll évoluent, mais soient restent compatibles, soient possèdent un autre nom (avec la dernière version de VC++ et donc des MFC, c'est MFC70.dll.
MFC42.dll t'es à peu près sûr de la trouver sur tous les postes, la nouvelle non.
Si ta dll est simple, passe toi des MFC et utilise la STL.

 
La STL? Tu veux dire faire une Dll Win32 classique?

nan, que si tu utilises que les CString des MFC alors autant laissé tomber et utiliser std::string

J'en déduis  :STL = Standard Library? Pour utiliser je dois faire un include spécial, genre string.h ou c'est inclus?

 
Standard Template Library
 
En gros, ca rajoute des nouveaux types utiles, comme par exemple le type chaine de caracteres, ou encore le type liste.
HelloWorld te conseillait simplement une alternative aux MFC
 
edit : pour s'en servir tu fais par exemple :
 include <string> ( sans le .h )
Et tu dois aussi faire :
using namespace std;
Et la tu peux te servir du type string de la maniere suivante :
 
string a = "I love STL";

 
<string> en l'occurence, ca fait référence à la template et non pas au header comme d'hab?
 
Et c'est normalisé C++ tout ca?

Oui, contrairement aux MFC.

 
Concretement, je pourrais accéder à a comme si c'était un tableau?
 
Et en mémoire, il y aura quoi? : "I love STL/0" ?

Tu ne t'occupes pas de ce qu'il y a dans la mémoire! On s'en fiche! On cherche pas a savoir! Si tu veux accéder caractere par caractere il y a des fonctions d'acces mais a aucun moment on a besoin de savoir ce qu'il y a en mémoire ni comment c'est organisé.

 
Ben il existe un fichier "string" sans extension qui est en fait un header. Sauf que tout ce qu'il déclare est dans un namespace d'ou le besoin de faire un usign apres.