Crash de VB en sortie de l'appli [VB] - VB/VBA/VBS - Programmation
Marsh Posté le 04-08-2003 à 15:40:48
Je dirais que ta DLL n'est pas conforme. Si elle l'était, je ne vois pas de raison pour laquelle VB planterait. A moins que ce ne soit lié à ton hook? C'est une possibilité à explorer.
Tout ce que je sais sur le sujet, c'est que les fonctions C appelées par VB doivent être déclarées avec __stdcall.
D'autre part, sans a priori sur le code de ta DLL, tu dois savoir qu'en VB, les Long et Integer sont toujours signés. Il y a donc possibilité d'une mauvaise interprétation si tu utilises du non-signé côté DLL.
Marsh Posté le 04-08-2003 à 15:42:24
drasche a écrit : Je dirais que ta DLL n'est pas conforme. Si elle l'était, je ne vois pas de raison pour laquelle VB planterait. A moins que ce ne soit lié à ton hook? C'est une possibilité à explorer. |
ok, dans ce cas je vais regarder de plus près la dll (spa mon code non plus...j'ai juste un peu modifié...:sweat
Marsh Posté le 04-08-2003 à 15:48:06
Autre question nulle: pourquoi est-ce que je vois aucune référence à ma dll dans ce putain de code???
Marsh Posté le 04-08-2003 à 15:55:25
oups
tout ce que je vois, c'est ceci:
Code :
|
Tu devrais regarder dans la classe CGlobalHook
Marsh Posté le 04-08-2003 à 16:01:01
drasche a écrit : oups
|
J'ai pas de classe CGlobalHook .
Et tout ce que ma dll exporte c'est
Citation : |
...qui n'apparaissent nulle part dans ce code VB de mes 2...
Marsh Posté le 04-08-2003 à 16:02:14
skeye a écrit : J'ai pas de classe CGlobalHook . |
si, dans ton projet VB (me suis mal exprimé je crois )
Marsh Posté le 04-08-2003 à 16:03:33
drasche a écrit : |
grumpf.
Tout le code que j'ai se trouve dans mon 1er post...
Ou alors caché dans un autre rep de ce que m'a filé mon boss sans rien m'esspliker, p-e...
Marsh Posté le 04-08-2003 à 16:07:52
ah mais... autre supposition, t'as une référence vers un compo externe, lequel contiendrait la classe litigeuse. Va voir dans le menu Project/Reference. T'as une liste avec les librairies référencées. En tête tu as 3x Visual Basic-TrucMuche puis OLE Automation. Ces 4 là sont standard. Les autres cases cochées sont des références spécifiques à ton projet VB.
Marsh Posté le 04-08-2003 à 16:17:16
drasche a écrit : ah mais... autre supposition, t'as une référence vers un compo externe, lequel contiendrait la classe litigeuse. Va voir dans le menu Project/Reference. T'as une liste avec les librairies référencées. En tête tu as 3x Visual Basic-TrucMuche puis OLE Automation. Ces 4 là sont standard. Les autres cases cochées sont des références spécifiques à ton projet VB. |
Bon, j'ai retrouvé globalHook (il était bien dans les références, et j'ai aussi les sources).
Ca donne ça:
Code :
|
Je vois pas de truc abracadabrant...à part ces affreux masques hexa, mais bo je suppose l'auteur sait ce qu'il fait!
(Toujours pas de référence à ma dll c++, par contre...magique tout ça... )
Marsh Posté le 04-08-2003 à 16:21:12
doit manquer quelque chose car tu as un MCallback utilisé dans les Initialize et Terminate (constructeur et destructeur en VB) mais déclaré nulle part, il s'agit donc d'une variable globale. Si tu as le curseur dessus, tu fais un Shift-F2 et tu atterriras sur la déclaration (View/Definition si tu préfères par le menu).
Marsh Posté le 04-08-2003 à 16:28:23
drasche a écrit : doit manquer quelque chose car tu as un MCallback utilisé dans les Initialize et Terminate (constructeur et destructeur en VB) mais déclaré nulle part, il s'agit donc d'une variable globale. Si tu as le curseur dessus, tu fais un Shift-F2 et tu atterriras sur la déclaration (View/Definition si tu préfères par le menu). |
Trouvé...mais aussi trouvé un fichier texte qui donne un lien vers l'endroit ou mon boss doit avoir trouvé tout ce bordel:
http://www.Planet-Source-Code.com/ [...] 5&lngWId=1
Commentaire:
Citation : |
puis
Citation : |
Résultat, je dis à mon chef de se démerder avec ça?
Marsh Posté le 04-08-2003 à 16:43:12
Mon boss va se démerder avec cette erreur à la con tout seul!
Merci quand même!:jap:
Marsh Posté le 04-08-2003 à 16:54:49
la suite du commentaire était en dessous mais formulée autrement
et effectivement, dès que t'as des hooks, du subclassing et compagnie, faut éviter d'appuyer sur Stop. Celui-ci cleane tout à sa manière mais plus aucun code VB n'est exécuté, dont celui qui est en charge du release du hook, d'où le plantage.
Marsh Posté le 05-08-2003 à 00:11:39
Une "technique" lorsque l'on fait du subclassing c'est de s'envoyer le message WM_QUIT lors de l'unload de la form.
Une autre "technique" consiste à récupérer l'adresse de la fonction de hook/subclassing et de l'arreter via SetWindowLong(hwnd, GWL_WNDPROC, adresse_WindowProc) et d'ensuite envoyer le message WM_QUIT.
Ces deux "techniques" fonctionnent chez moi.
Marsh Posté le 05-08-2003 à 11:48:08
oui mais pour cela il faut que le code VB soit exécuté. Si le bouton Stop est pressé comme c'est très probablement son cas, aucun code VB ne sera plus exécuté. C'est le danger des techniques de hooking et subclassing, ça marche bien en EXE mais faire gaffe à ce que l'on fait en debug.
Marsh Posté le 06-08-2003 à 00:47:44
Non, ce que j'ai dit fonctionne tres bien depuis le RAD et en debuggant. Il faut cliquer sur la croix et non sur le bouton Stop.
Marsh Posté le 06-08-2003 à 10:01:25
karlkox a écrit : Non, ce que j'ai dit fonctionne tres bien depuis le RAD et en debuggant. Il faut cliquer sur la croix et non sur le bouton Stop. |
ooops mal exprimé
je parlais pour lui, pas pour toi
Marsh Posté le 04-08-2003 à 15:26:49
Bon, j'y connais pas des masses en VB et je suis censé débugger une petite appli qui permet de tester une dll (la question risque d'être savoir si c'est le prog VB ou la dll C++ qui fait planter le brol).
C'est pas très long, je vous mets le code:
Lorsque j'exécute ce machin ca fonctionne très bien, jusqu'à ce que je veuille l'arrêter...et là VB (VB6, au fait) me fait une op non conforme bla bla bla...
Je vois pas d'où ca peut venir, j'ai essayé en commentant le contenu de Form_Unload, mais ca ne change rien...