dekai
Messages postés8Date d'inscriptionvendredi 30 mai 2003StatutMembreDernière intervention 4 juillet 2008
-
2 juil. 2008 à 20:18
Gothamma
Messages postés2Date d'inscriptionmardi 21 août 2007StatutMembreDernière intervention17 mai 2011
-
17 mai 2011 à 18:58
Salut à tous,
Je crois que le titre explique bien ce que je souhaite faire : je n'arrive pas à communiquer entre ma dll et mon appli par le biais de SendMessage().
J'utilise XP Pro SP3 et Visual Studio 2008, la solution qui contient 2 projets est disponible : ici
La dll fonctionne, son appel par le biais de pinvoke et la mise en place du hook global aussi.
Apparement une appli console c# ne possède pas de "message pump" donc j'utilise NativeWindow et lui assigne le handle de la fenêtre console pour pouvoir modifier le comportement de WndProc(). Mais malheureusement je ne reçois aucun message.
Je vous demande donc de l'aide.
Question bonus : comment faire pour rendre actif les breakpoints (de ma dll) et pour debug la dll ?
Lutinore
Messages postés3246Date d'inscriptionlundi 25 avril 2005StatutMembreDernière intervention27 octobre 201241 3 juil. 2008 à 21:52
le code de la fonction DllMain est excuté par l'attribut DllImport, il faut bien la chargée la dll.. vu le code dans ta source cpp LoadLibrary et FreeLibrary sont inutiles.
Ce n'est pas SendInput qui bloque apparemment, pas "d'acces denied" non plus.. si tu affiches une vraie forme suivis d'Application.Run tu recevras bien tes messages WM_USER dans la console.
Invisible invisible = new Invisible();
Install( invisible.Handle );
Form f = new Form( );
Application.Run( f );
Je ne vois pas pourquoi Application.Run tout seul ne suffit pas.. J'ai pas testé plus que ça..
dekai
Messages postés8Date d'inscriptionvendredi 30 mai 2003StatutMembreDernière intervention 4 juillet 2008 3 juil. 2008 à 13:23
Merci Lutinore ça avance un peu mais c'est tjs pas complet :
En utilisant ta classe j'arrive maintenant à récupérer les messages de la création de la fenêtre (WM_GETMINMAXINFO, WM_NCCREATE, WM_NCCALCSIZE et WM_CREATE) mais je ne reçois tjs rien de ma dll.
La version initiale du projet est renommée "Hook dll.old" et celle contenant ta classe est "Hook dll.zip" (lien dans le premier message). Si tu as le temps de te pencher dessus... Merci.
Lutinore
Messages postés3246Date d'inscriptionlundi 25 avril 2005StatutMembreDernière intervention27 octobre 201241 3 juil. 2008 à 14:50
J'ai regardé rapidement.. tu installes un hook local ça me semble plutôt normal que tu ne reçois rien dans une appli console, utilises plutôt un hook global WH_KEYBOARD_LL. En C# on utilise quasi jamais LoadLibrary/FreeLibrary, c'est l'attribut DllImport qui gère ça.. Puisque ta dll en C/C++ contient un simple hook clavier tu peux l'écrire totalement en C#.
dekai
Messages postés8Date d'inscriptionvendredi 30 mai 2003StatutMembreDernière intervention 4 juillet 2008 3 juil. 2008 à 16:34
Je crois que tu te trompes, enfin pas tout à fait mais on va éclaircir tout ça :
- Effectivement WH_KEYBOARD_LL est un hook global par défaut, mais j'install bien un hook global pour WH_KEYBOARD. En effet WH_KEYBOARD peut avoir une portée "thread" ou "global" (cf tableau dans remarks). C'est le 4ème argument de SetWindowsHookEx() qui détermine la portée de hook.
- Mon premier point est confirmé : le hook global fonctionne bien. A chaque pression d'une touche au clavier je log dans "c:\log.txt" la valeur 0 qui doit correspondre à HC_ACTION.
Voilà pour le hook
Pour ce qui est de Dllimport bien sur que je l'utilise mais plutôt que
d'exporter plusieurs fonctions de ma dll j'utilise les mecanismes LoadLibrary/FreeLibrary
afin d'executer le code de la fonction DllMain (non joignable
autrement). De toute façon le problème n'est pas là le hook fonctionne
bien.
Réaliser le hook en C# n'a aucun interêt pour moi : en réalité je me fou totalement du type du hook utilisé, à terme j'aurai besoin de WH_CBT, WH_SHELL et WH_SYSMSGFILTER. Mais pour des raisons de tests j'utilise WH_KEYBOARD.
Comme mon titre l'indique c'est uniquement la communication entre ma dll et mon appli console qui m'interesse et me pose problème. Je pense que le soucis est au niveau de la fonction SendMessage (ligne 31 de dllmain.cpp).