affichage d'un DWORD

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...

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 :)

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

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.

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."

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.

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 ?

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.

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...

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.

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

oui c'est normal pour MSJava il s'en sort.

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...

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.

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 !

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 !

C'est en appelant GetProcAdress ou en appelant la methode elle meme ?

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 ?

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 ^^

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