affichage d'un DWORD

Version imprimable

20/08/2007, 14h12
MegaSoft

affichage d'un DWORD

Bonjour,

Je suis sur un problème tout bête, mais je n'y arrive pas, donc je vous le soumet en vous remerciant d'avance pour vos réponses :

Je suis avec Visual Studio, je n'utilise pas le framework .net, et je tente de charger une DLL avec la fonction

LoadLibrary("laDll.dll");

mais en testant le handle renvoyé, je me rend compte que mon chargement a échoué, donc, j'appelle la fonction

GetLastError;

Là, je reçoit un joli DWORD, mais mon problème, est que j'aimerai bien savoir quel est ce numéro d'erreur !

J'ai essayé en vain de l'afficher via la fonction MessageBox

Is everyone can help me ?

voila comment afficher l'erreur avec un beau message (dans ta langue natale)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
char *errorMessage;
if(::FormatMessage( FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,
                    NULL,
                    ::GetLastError(),
                    0,
                    (LPTSTR)&errorMessage,
                    0,
                    NULL))
{
            (void)MessageBox(0, errorMessage, "Erreur", MB_ICONERROR | MB_OK);
            (void)LocalFree(errorMessage);
}
else
{
            (void)MessageBox(0, "Meme pas reussi a recuperer le message", "Erreur", MB_ICONERROR | MB_OK);
}

20/08/2007, 14h46
MegaSoft

Merci beaucoup !!!

mais j'ai le regret de t'annoncer qu'au premier abord, ta solution a pour seul effet de figer mon application...

je vais me pencher un peu plus sur ce que tu as marqué, pour comprendre le truc (même si c'est suffisamment limpide au premier abord)

je précise que je suis dans le code d'une Dll, peut-être est-ce à cause de cela que ça ne marche pas ?

Merci quand même.
20/08/2007, 16h20
screetch

ah tiens bizarre, enfin je reste a l'ecoute si tu arrives a trouver l'erreur! :(

Alors...

Après quelques tests, il s'avère que ton code n'était responsable de l'arrêt de fonctionnement de mon application... ça m'aurait étonné aussi vu comment il est simple !

Je vais donc t'expliquer mon but plus en détails :

Je doit faire une application en C++ qui se sert d'une DLL en C++ qui se sert d'une DLL en Delphi, en gros c'est ça.

Le problème est que ma DLL en C++ refuse de charger la DLL en Delphi, alors que l'application en C++, elle veut bien charger la DLL en Delphi.

Voici des codes de test :

L'Application en C++
Code:

1 2 3 4 5 6 7 8 9 10 11 12 #include <windows.h> int main() { HMODULE hinstDLL; MessageBox(0,"Chargement de la DLL...","Suivi",0); hinstDLL=LoadLibrary("SimpleDll.dll"); FreeLibrary(hinstDLL); hinstDLL=LoadLibrary("simpledllcpp.dll"); FreeLibrary(hinstDLL); return 0; }
Rien d'extraordinaire...

La DLL en Delphi : SimpleDll.dll
Ce n'est pas la vraie, c'est juste pour tester
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 library Convert; uses dialogs; Const DevEuro=6.55957; function ConvertEuro(Montant:double):double; stdcall; begin Result:=Montant*DevEuro; end; function ConvertFranc(Montant:double):double; stdcall; begin Result:=Montant/DevEuro; end; exports ConvertEuro, ConvertFranc; begin ShowMessage('Project1 :: Initialisation'); {partie initialisation de la dll} end.
La Dll en C++ : simpledllcpp.dll
Générée par Visual Studio 2005, je n'ai modifié que le DllMain
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 // simpledllcpp.cpp : Defines the entry point for the DLL application. // #include "stdafx.h" #ifdef _MANAGED #pragma managed(push, off) #endif BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { HMODULE hinstDLL; MessageBox(0,(LPCWSTR)"",(LPCWSTR)"",0); hinstDLL=LoadLibrary((LPCWSTR)"SimpleDll.dll"); char *errorMessage; if(::FormatMessage( FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,NULL,::GetLastError(),0,(LPTSTR)&errorMessage,0,NULL)) { (void)MessageBox(0, (LPCWSTR)errorMessage,(LPCWSTR)"Erreur",MB_ICONERROR | MB_OK); (void)LocalFree(errorMessage); } else { (void)MessageBox(0, (LPCWSTR)"Meme pas reussi a recuperer le message", (LPCWSTR)"Erreur", MB_ICONERROR | MB_OK); } FreeLibrary(hinstDLL); return TRUE; } #ifdef _MANAGED #pragma managed(pop) #endif

Il se peut que ca plante dans l'initialisation de la Dll delphi (pour une raison quelconque ca plante avec le C++ de la Dll mais pas avec le C++ du programme)

donc c'est l'appel a LoadLibrary qui lance l'initialisation, et la PAF! pastèque.

Pour voir ci c'est ca mets des messages au debut et a la fin de l'initialisation et verifie que tu vois les deux messages. Si ca plante entre les deux messages, essaye de rapprocher les messages jusqu'a ce que tu aies encadre l'execution qui plante et tu auras l'identité du bug.

Exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 library Convert; uses dialogs; Const DevEuro=6.55957; function ConvertEuro(Montant:double):double; stdcall; begin Result:=Montant*DevEuro; end; function ConvertFranc(Montant:double):double; stdcall; begin Result:=Montant/DevEuro; end; exports ConvertEuro, ConvertFranc; begin ShowMessage('Project1 :: Initialisation'); {partie initialisation de la dll} ShowMessage('Project1 :: Initialisation OK!!!'); end.
et resserre les deux ShowMessage jusqu'a ce que tu encadres la ligne qui plante.

Si les deux dialogues marchent c'est que le bug n'est pas dans cette initialisation :(

21/08/2007, 09h22
MegaSoft

C'est bien pensé

mais j'y ai pensé, et le premier message ne s'affiche même pas !

De plus, dans l'initialisation de la Dll en Delphi, il n'y a que 3 registerWindowMessage, donc l'isolement a été fait très rapidement sans succès...

En fait, quand je charge la Dll en Delphi directement dans le programme en C++, ça marche sans problème, contrairement au cas quand je la charge dans la Dll en C++. Ton bout de code indique "le module spécifié est introuvable", du moins dans mes tests, car dans la vrai appli, il n'indique rien du tout, et le tout se "freeze" au moment du LoadLibrary...

En ce qui concerne mes tests, peut-être est-ce un problème de conversion entre le "SimpleDll.dll" et l'argument en (LPCWSTR) que demande le LoadLibrary ?
21/08/2007, 09h34
screetch

j'ai du mal a suivre le probleme

1) si tu charges la DLL dans le programme, ca marche
2) si tu le charges depuis ta DLL C++, alors tu vois la boite de dialogue
3) dans quel cas ca freeze?
21/08/2007, 09h57
MegaSoft

Alors...

C'est simple, mais c'est vrai que j'ai pu m'emmêler les pinceaux...

Récapitulons :

Je fais une application en C++ qui charge une Dll en C++, et cette dernière charge une Dll en Delphi.

L'application est faite, et je ne peut pas la modifier.
La Dll en C++ est en partie faite, idem pour la Dll en Delphi.

Lorsque j'ai voulu faire la connection entre les deux Dll, ben pouf !

Donc, après quelques tests infructueux, comme je nageais dans le potage de C++, ben j'ai décidé d'isoler le problème et de faire des programmes plus simples.

Dans ces tests, la Dll en Delphi se charge sans problème dans le programme en C++, mais ne se charge pas dans la Dll en C++.

Et, c'est dans la vraie application que le tout se fige au moment du LoadLibrary dans la Dll en C++ (de toute manière, je ne peut pas le mettre dans l'application).

Voilà

J'espère avoir été assez clair, et merci pour le temps que tu prends pour me répondre !

Donc si je comprends bien, lorsque tu charges la DLL dans un programme de test (cf plus haut qui appelle load library)
alors tu as un message d'erreur

si tu fais ca depuis ton vrai programme, au lieu de voir la boite de dialogue tout part en sucette

tu as plusieurs possibilites mais c'est plutot des suppositions malheureusement :
- as tu des warning sur les lignes d'appel ?
- remplace
Code:

1 2 LoadLibrary("dll");
par
Code:

1 2 LoadLibrary(_T("dll"));
- Le code d'initialisation de la dll est execute plusieurs fois selon le type de "load".
Donc dans le DllMain, verifie le parametre ul_reason_for_call
si celui ci vaut quelque chose comme DLL_REASON_ATTACH alors execute le code sinon ca peut valoir autre chose pour une autre type d'init.
fais un switch de ce gout :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { switch(ul_reason_for_call) { case DLL_REASON_ATTACH: { HMODULE hinstDLL; MessageBox(0,(LPCWSTR)"",(LPCWSTR)"",0); hinstDLL=LoadLibrary((LPCWSTR)"SimpleDll.dll"); char *errorMessage; if(::FormatMessage( FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,NULL,::GetLastError(),0,(LPTSTR)&errorMessage,0,NULL)) { (void)MessageBox(0, (LPCWSTR)errorMessage,(LPCWSTR)"Erreur",MB_ICONERROR | MB_OK); (void)LocalFree(errorMessage); } else { (void)MessageBox(0, (LPCWSTR)"Meme pas reussi a recuperer le message", (LPCWSTR)"Erreur", MB_ICONERROR | MB_OK); } FreeLibrary(hinstDLL); } break; default:; } return TRUE; }
- remplace tous les (LPCWSTR)chaine par des _T(chaine)

- ou/et passe ton programme en mode Multi-Byte character encoding au lieu de Unicode (proprietes generales du projet)

21/08/2007, 11h15
MegaSoft

Donc...

Bien que je me débrouille pas mal en Delphi et en VB, le c++, c'est pas trop ma tasse de thé...

Donc... "warning sur ligne d'appel" <- kézaco ?

Sinon, il me sort un classique "identifiant non reconnu" lorsque je tente le _T(xxx), je vais essayer de trouver quel est l'include qui correspond.

Je sais que le DllMain est appelé plusieurs fois, mais cela m'importe peu, car c'est juste un test, et je ne pense pas que cela ait une incidence sur mon cas.

Quant au multibyte character... je cherche encore...

Sinon, j'ai fait quelques avancées :

J'ai réussi à faire s'éxecuter l'initialisation de la Dll en Delphi depuis la Dll en C++, mais en testant le Handle renvoyé... ben c'est toujours pas bon...

Pour y parvenir, j'ai juste remplacé LoadLibrary((LPCWSTR)"SimpleDll.dll") par LoadLibraryA((LPCSTR)"SimpleDll.dll")...
21/08/2007, 11h32
screetch

Ok je vais essayer d'etre plus clair ^^

tu as deux facons d'utiliser la lib API windows, une marche en ANSI (c'est a dire que les caracteres sont codes sur 1 octet)
l'autre en Unicode

selon tes reglages de projet tu peux utiliser les bibliotheques soit en version ANSI soit en version UNICODE.

Windows fournit deux implementations pour la plupart des fonctions qui prennent des chaines :
- LoadLibraryA (ANSI)
- LoadLibraryW (je crois que c'est avec un W comme WORD mais je suis pas sur, soit 2 octets, c'est peut etre W comme WIDE ou alors c'est pas W, j'en sais rien je m'en sers jamais)

les chaines C sont ANSI c'est a dire que si tu ecris "toto" alors chaque lettre prend 1 octet
Il y a un moyen d'ecrire "toto" en UNICODE, c'est d'ecrire L"toto" (oui avec un L devant en dehors de la chaine)
Selon les reglages du programme tu peux avoir a utiliser des chaines ANSI ou UNICODE. Il existe une macro dans les headers Windows qi permet de declarer une chaine soit ansi soit unicode selon le type de projet : c'est la macro _T("chaine statique") qui rajoute ou pas le L devant la chaine pour la passer en unicode.
Cette macro est dans le fichier <tchar.h>
donc si tu veux supporter les deux, tu peux passer par le type TCHAR au lieu de char (une chaine sera alors soit char chaine[] soit wchar_t chaine[] donc soit ANSI soit UNICODE selon ton projet, et les chaines statiques doivent etre dans la macro _T("chaine") pour en faire soit des chaines ANSI soit des chaines UNICODE

Le defaut que je recommande pour pas casser les burnes des gentils programmeurs que nous sommes et qui n'ont jamais fait de mal a personne, c'est de passer immediatement le projet en ANSI et de se contrebalancer des chaines UNICODE. Rien n'est vraiment pret dans le C pour l'unicode, alors quitte a faire un truc stupide et qui fait mal, autant se flageller avec des cactus. Ca sera plus productif et cafera moins mal que de supporter les TCHAR.

Tu peux donc aller dans les proprietes de ton projet (clic droit sur le projet, proprietes). Normalement tu seras dans un onglet qui est intitulé GENERAl, si tu n'y es pas clique sur GENERAL a gauche.

il y a uen case en bas (deux cases au dessus de la derniere je crois) qui indique "Character Set" (j'ai la version english de VStudio, desole). Tu peux choisir entre "UNICODE character set" (berk, reberk, bereberk!!!) ou Multi-Byte Character Set. Eloigne toi de l'unicode character set comme d'un reste de chili froid!!!!

Ensuite, retire toute les betises de (LPWCSTR) et laisse les char*

Par "warning sur ligne d'appel", je voulais te demander si le compilateur avait indiqué un avertissement sur la ligne ou tu appelles LoadLibrary. Si tu te trompes dans le format de chaine (entre UNICODE et ANSI) alors le compilateur doit refuser de compiler. Donc retire tous les (LPCWSTR) ou (LPWCSTR) ou je sais plus et si ca ne compile pas, c'est que la fonction utilisee n'est pas la bonne version (c'est a dire UNICODE).
21/08/2007, 11h57
MegaSoft

Thanks a lot

Merci pour cette explication, j'y voit maintenant un peu plus clair dans tout ce charabia de LPCSTR & co...

Donc, avant de lire ton message j'avais trouvé comment passer en Multi-byte et effectivement, ça aide beaucoup...

De plus, j'ai réussi à charger ma Dll en Delphi et à en sortir une function !

Mais mon problème est le même que celui qui m'a amener sur ce forum...

Ma function de test est une fonction toute simple qui renvoie un entier qui vaut 128, après avoir affiché un message (ce qu'elle affiche)...

Comment faire pour que ce Int soit lisible ?
Comment le convertir en LPCSTR ?

En fait le but est de renvoyer une chaîne, et c'est ce que je vais tester maintenant...

Merci d'avance...

Edit : J'ai oublié, non je n'ai pas de Warning sur les appels
21/08/2007, 12h08
screetch
HAAAAAAAAAN stooooooooooooooooop

il est impossible de renvoyer une string PASCAL (ou Delphi) vers le C++ directement!

les string pascal sont des objets vaec des champs toussa, ca respecte une convention de passage de paranetre tordue.

La seule chose que le C++ peut gerer est le char*

ta fonction doit donc renvoyer un PCHAR
Code:

1 2 3 4 5 6 7 8 function fonctionDeTest(param : Integer) : PCHAR var temporary : string; begin temporary = IntToStr(param); result := PCHAR(temporary); end
Mais ca ne s'arrete pas la

deja il te faut trouver la fonction IntToStr. Ca c'est un probleme delphi, je sais pas ce que c'est.

De plus, comme je l'ai bien ecrit dans la fonction, la chaine temporary est TEMPORAIRE, elle sera detruite a la fin de la fonction, avant de rendre la main au C++, ce qui fait que le PCHAR va etre moisi!

pour remplir des chaines, j'ai peur qu'il y ait peu de choix, il faut que C++ alloue le buffer, donne le buffer a Delphi (avec la taille) et Delphi remplit le buffer.

Les seules choses renvoyees par Delphi que C++ peut utilser sont les types de base qui ont la meme representation (float => single, double => double, PAS les extended delphi, char* => PCHAR, int => INTEGER, short => WORD...)

tu vas galerer ! ;)
21/08/2007, 14h17
MegaSoft

Donc...

J'ai fait mes petits tests en prenant en compte ce que tu as dit...

Effectivement, passer un shortstring comme prévu est impossible, j'ai donc changé en PCHAR dans la Dll en Delphi et là paf ! ça marche !

Je peux donc appeler une fonction de la Dll en Delphi, et récupérer le Résultat dans la Dll en C++, ce qui est ce que je voulais !

Mais... (pourquoi il y a toujours un mais ?)

En revenant sur l'application initiale, ben, je me retrouve avec le même problème qu'avant, le "freeze" à l'appel de LoadLibrary...

Je pense que quelques précisions s'impose...

Ce que j'appelle l'application en C++, c'est Eudora
Ce que j'appelle la Dll en C++, c'est un de ses plugins
Ce que j'appelle la Dll en Delphi, c'est une bibliothèque de fonctions qu'on veut implanter à Eudora, mais pas que à Eudora

Voilà tout est dit

As-tu une idée sur pourquoi ça gèle au chargement de la Dll ?
21/08/2007, 15h22
screetch

alors la cette fois ci... aucune idee.

peux tu lancer ta Dll dans visual en l'attachant au processus Eudora et voir ce que le CPU est en train de faire ?

si je parle chinois dis moi ^^
21/08/2007, 15h40
MegaSoft

je dirais que...

tu parles Cambodgien... c'est à moitié compréhensible.

Lancer la Dll dans visual en l'attachant au processus d'Eudora, là ça va

Je lance Eudora, j'ouvre Visual avec la Dll en C++, et je fait Debug>Attach to Process>Eudora.exe et hop ! (dis-le moi si je me trompe)

par contre , voir ce que le CPU fait... euh peut-être

je n'ai que Output qui marque des trucs, pas de "CPU" au quelque chose se rapprochant en vue... c'est où stp ?
21/08/2007, 15h47
Albenejean

Citation:

le module spécifié est introuvable

Une idée toute stupide: préciser le chemin complet de la DLL...
21/08/2007, 15h50
MegaSoft

Désolé

mais j'y ai déjà pensé, et cela n'arrange pas les choses

de plus, maintenant, si j'avais un message d'erreur qui s'affichait, je serais assez content, mais il n'y a rien, vu que l'application se "fige" au moment du LoadLibrary
21/08/2007, 15h53
screetch

Ok c'est pas si mal ^^

alors pour attacher au processus il y a un peu plus simple, tu vas dans les proprietes du projet, et dans debuggage tu remplis les champs application a lancer et parametres avec Eudora (si tu connais la ligne de commande pour lancer Eudora). Ca te permet de lancer Eudora automatiquement et des que ta DLL sera chargee Visual sera "liee" dessus, en quelque sorte. Sinon attacher au processus marche aussi, mais il faut reussir a s'attacher au processus avant que ca ne plante

Ensuite, dans le menu de Visual C++ il y a un onglet Debug tout en haut. Si tu deroules, tu verras "Exceptions..."

cliques dessus.

Tu verras des lignes et des checkbox a droite. Elles sont tous decochees par defaut. Coche les toutes (ca devrait etre par defaut c'est un vrai scandale!!!!!!)

Voila maintenant que ca s'est fait tu peux t'attacher au processus. Deux possibilites :
- mettre un "breakpoint" avant le load library et faire du pas a pas jusqu'a ce que ca crashe
- lancer direct comme un boucher. Si ton appli crashe tu auras un diagnostic, si il est perdu dans une boucle infinie (c'est de ca que je parlais en voyant ce que fait le CPU) tu peux cliquer sur "Pause" pour stopper temporairement l'execution, et inspecter la call stack. Ca devrait te dire ce qui ne va pas : en tous cas ca devrait te dire OU il y a un probleme.
21/08/2007, 16h20
MegaSoft

hum...

En fait, j'avais attaché la Dll à Eudora comme tu l'a indiqué depuis le début...

Alors j'ai coché pour voir toutes les exceptions, et là surprise ! Eudora lance plusieurs centaines (ou milliers je sais pas, j'ai pas été jusqu'au bout...) d'exceptions au démarrage...

Après avoir échoué à passer outre cette foire à l'exception, j'ai opté pour la solution attacher au processus étant donné que je peut déclencher le blocage quand je le désire bien après qu'Eudora soit lancé.

Dans les deux cas, si je met met un break sur une ligne de la Dll, il me l'annule donc le mode pas-à-pas n'est pas utilisable (ou alors je sais pas faire...).

Sinon, j'ai fait une pose quand Eudora se gèle, et je me retrouve dans le fichier memset.asm, en train de répéter inlassablement l'instruction REP STOSD...

Je vais donc continuer de chercher pourquoi un arrêt à cet endroit précis, mais si on pouvait m'éclairer parce que là, ça ne m'avance pas des masses...
21/08/2007, 16h26
screetch

ah...
et tu construis bien ta DLL en debug ?

apparemment c'est pas bien attache car si il y arrive alors tu peux poser tes breakpoints dans le code et il comprend. En tous cas des que la DLL est chargee il comprend.

Peut etre c'est jsute pas la "bonne" DLL

pour charger la dll tu fais comment ? tu la copies dans un dossier de Eudora ? tu peux essayer en changant dans les configurations de projet, onglet General, change la destination pour que visual genere la DLL directement au bon endroit ou alors demande a Eudora de charger ta DLL depuis l'emplacement de sortie de Visual. Comme ca on est sur qu on parle bien de la meme DLL :)
21/08/2007, 16h36
MegaSoft

malheureusement

J'ai déjà configuré Visual pour construire la Dll directement dans le dossier dans lequel il faut mettre les plugins pour Eudora, donc je suis sur que c'est toujours la bonne Dll

Au passage, en C++ comme en Delphi, je n'ai jamais pu poser un seul point d'arrêt dans une Dll
21/08/2007, 16h39
screetch

aie.

En delphi ca me parait normal (on avait a peu de chose pres la meme config et c'etait l'enfer cote delphi). En C++ on s'en est toujours sorti.

Donc c'est louche.

Tu as verifie si tu etais en config debug ? normalement ca doit etre debug, c'est la version par defaut.
21/08/2007, 16h44
MegaSoft

Oui

Je suis bien en Configuration Debug (du moins si j'ai bien compris Alt+F7>Configuration réglée sur Debug)

Je fait toujours F5 et non CTRL+F5

Donc, je suis parfaitement d'accord avec toi, ça "devrait" marcher... mais non, les voies de l'informatique sont impénétrables...

j'ai mitraillé mon code de point d'arrêt un peu partout, aucun ne passe, même si je lance avec F5, ou si j'attache la Dll au processus d'Eudora en cours d'utilisation...

là je sèche

Edit : Visual m'indique quand je passe sur un point d'arret à l'éxécution : "The breakpoint will not currently be hit. No symbols have been loaded for this document."
21/08/2007, 17h08
screetch

Je pense que le changement de repertoire a rendus Visual tout confus

Dans les proprietes du projet il y a un onglet "Linker" (ou "Edition de lien" ou un truc comme ca)

dedans, tu verras la ligne Debugging si tu l'etends. Si tu cliques sur ce champ Debugging, a droite vont s'afficher les options de debugging. Il y a en particulier un champ "Generate program database file". Par defaut il est regle sur

Citation:

$(TargetPath)/$(TargetName).pdb

verifie que ca colle bien avec ton repertoire de sortie : si tu cliques sur ce nom de fichier, il te proposera de l'editer. La, tu vois un bouton "Macros >>>". Quand tu cliques dessus, verifie les valeurs de targetPath et TargetName. Si ca ne colle pas, c'est qu'il y a une couille dans le potage.

Dans ce cas la, change la ligne

Citation:

$(TargetPath)/$(TargetName).pdb

par

Citation:

Repertoire qui va bien/$(TargetName).pdb

ou ecrit le en dur (on est plus a ca pres).

Apres regenere la DLL (je ne sais pas si il detectera les changements donc fais Rebuild)

la si tout va bien il mettra un fichier pdb a cote du fichier DLL, verifie qu'il y est.

Si il y est, reessaye le debugging.

Quand tu lances, dans la fenetre Output, il y a 40000 messages. Copie colle la fenetre Output lorsque tout est lance, et colle la dans un nouveau fichier texte (ca permet d'utiliser un editeur de texte sympa) et cherche le nom de ta DLL dedans. Quand tu la trouves, il te dira "Loaded DLL "blah blah blah.dll", ...
c'est la fin de lal igne qui m'interesse.
Il peut dire "No symbols found" et la c'est le drame, ou alors "Symbols loaded" et la c'est miam.
21/08/2007, 17h32
MegaSoft

Je comprend plus rien

J'ai changé les champs OutPut File (pour la deuxième fois je précise, il était revenu à la normale pour une raison quelconque il y a une heure) et Generate Program Database File comme tu me l'as conseillé

au passage, mon visual est aussi en anglais, donc inutile de chercher l'équivalent français !

Et là ! Miracles !

1/ Le point d'arrêt fonctionne !
2/ L'application ne se bloque plus !

Mais... (et oui toujours...)

Grâce à ton petit bout de code du début, j'obtient le message (encore) "Le module spécifié est introuvable".
Alors que la Dll que je demande est bien présente dans le même dossier !
J'ai essayé avec le chemin complet, mais rien y fait...

Mais le plus marrant dans tout ça, c'est quand je met le nom d'une autre Dll qui représente un autre plugin d'Eudora... et bien là ça marche ! il veut bien la charger !

C++ serait-il anti Delphi ?
21/08/2007, 17h36
screetch

ta DLL delphi depend d'une autre DLL peut etre. Utilise l'utilitaire "depends.exe" (il doit etre trouve avec visual) et ouvre ta DLL il te dira en rouge quelle DLL a foiré. Si tu trouves pas depends.exe cherche le sur google, il est facile a trouver et gratos.
21/08/2007, 17h39
MegaSoft

je ne crois pas

que ça soit cela le problème, étant donné que j'utilise ma Dll Delphi dans un autre programme (en Delphi et en Vb) sans le moindre problème...

Je vais essayer quand même, mais j'y crois pas du tout...
21/08/2007, 17h45
screetch

ca fera un entrainement a Depends, c'est tres utile ce petit truc !! :)

Ce qui se passe en fait c'est que si tu charges la DLL il va chercher dans un certain nombre d'endroits. Ces endroits sont changeables mais par defaut c'est :

- le repertoire de l'executable (j'ai bien dit l'executable, ps la DLL si tu passes par la DLL intermediaire)
- le repertoire courant
- les repertoires systemes
- les repertoires du PATH

si il a pas trouve il t'envoie bouler.

Lorsque tu fais LoadLibrary("plugins/monplugindll" a ma connaissance le repertoire des plugins n'est pas ajoute au chemin de recherche donc si monplugin.dll a une dependance ailleurs il t'enverra chier car il la trouve pas.

Depends.exe permet de voir les dll dont tu depends, si en le lancant tu vois que ta DLL a besoin d'une autre alors il faut chercher un endroit approprié et tout ajouter au PATH de recherche des plugins.

La page MSDN de LoadLibrary contient plus d'info (mais elle est lente) : a mon avis pour te simplifier la tache, tu devrais passer tes DLL en nom courts (sinon ca risque d'etre complexe) et ajouter le repertoire de la DLL a la liste des chemins de la DLL (apres comment faire ca proprement, c'est une autre histoire)

utilise SetDllDirectory pour ajouter des repertoires, puis LoadLibrary("MaDLL.dll") sans le chemin complet.
21/08/2007, 17h46
MegaSoft

Voilà

J'ai testé

Depends.exe me dit qu'il ne parvient pas à ouvrir MSJAVA.DLL lorsque je lui met ma Dll en Delphi...

Mais il met la même chose quand je met la Dll du PlugIn que j'ai parlé plus haut... (Qui elle se charge très bien)

Merci quand même
21/08/2007, 17h47
screetch

oui c'est normal pour MSJava il s'en sort.
21/08/2007, 17h50
MegaSoft

Donc...

si j'ai bien compris, faut que je passe en revue toutes les Dll que m'a craché Depends, et je cherche quelles sont celles qui n'ont pas un chemin "normal" ?

Ben j'aurai peut-être fini demain soir...
21/08/2007, 17h56
screetch
non non, dpeends charge ta DLL avec LoadLibrary et te reporte une erreur si il y en a une dans toute la liste de dependance.

Ce que je pense c'est que :

Eudora aurait un truc comme ca :
Code:

1 2 3 4 5 6 7 8 9 Eudora.exe bin/ (j'en sais rien hein) data/ plugins/ plugin1.dll plugin2.dll TonPlugin.dll LaLibDelphi.dll
Donc Eudora charge ton plugin, en chargeant "plugins/TonPlugin.dll" lequel effectue LoadLibrary("LaLibDelphi.dll") et la paf! marche pas

si ca se trouve ca marche en faisant
LoadLibrary("plugins/LaLibDelphi.dll")

autre solution : mets (temporairement!!!) ta DLL dans le repertoire C:/Windows ou C:/WinNT ou bref un truc systeme, fais un coup de depends dessus pour verifier que la version dans le systeme trouve ses dependances, et reessaye en noms courts. Normalement le miracle devrait s'operer. Si cela fonctionne, c'est que le chemin vers ta DLL est incorrect, d'une maniere ou d'une autre, et que tu dois tatonner jusqu'a trouver le bon emplacement qui va avec le bon repertoire.
21/08/2007, 17h59
MegaSoft

C'est parti

mais je reste perplexe, étant donné que je peut charger sans problème d'autres Dlls qui sont dans le même dossier...

Mais qui ne tente rien n'a pas grand chose !
21/08/2007, 18h05
MegaSoft

????????????

Là je comprend vraiment rien......

J'ai mis la Dll comme tu me l'avais conseillé dans le dossier C:\Windows\system32 qui est un bon gros dossier système comme on les aime !

Et là : Paf ! ça marche ! Il me charge la Dll !

J'aimerai bien savoir pourquoi cette Dll doit être mise dans un dossier système alors que je peux charger d'autres dll qui sont dans le dossier Plugins ??? Je trouve pas ça logique du tout !

Sinon... il y a encore un mais...

Lorsque je tente de charger une fonction de la Dll (c'est un peu le but hein) ben, eudora se ferme, purement et simplement...

Enfin, je verrais ça demain... merci pour toute cette aide que tu m'as apporté aujourd'hui et j'espère pouvoir compter encore sur toi demain !

Thanks man !
21/08/2007, 18h22
screetch

C'est en appelant GetProcAdress ou en appelant la methode elle meme ?
22/08/2007, 14h36
MegaSoft

Petit point

Alors, après de nombreux changements, ça marche presque comme je le veux...

à un détail près, il ne charge ma Dll que si elle est dans un dossier répertorié dans la variable système PATH, sinon rien, même en lui donnant le chemin complet...

Coment cela se fait, et comment passer outre ?
22/08/2007, 14h37
screetch

Ce chemin complet ca serait pas
"C:\Program Files\...\plugin.dll" ?

essaye
"C:\\Program Files\\...\\plugin.dll"

si c'est pas ca alors difficile de savoir ^^
22/08/2007, 14h52
MegaSoft

Bien vu !

Bien joué le coup du double slash ! ça marche comme sur des roulettes !

Fuseau horaire GMT +2. Il est actuellement 15h26.