Je suis en train de mettre en place un hook système.  
J'installe le hook (SetWindowsHookEx) dans une appli MFC (DialogBased).  
Le problème est le suivant : le hook n'est actif que sur le thread de l'appli installant le thread.
Il me semble pourtant avoir fait ce qu'il faut pour que la portée du hook soit au niveau du système, à savoir :
- extraire dans une dll la fonction filtre du hook (MouseProc en l'occurence)
- lors de l'appel à SetWindowsHookEx, préciser le HMODULE de la dll chargée depuis l'appli principale (3e paramètre de la fonction)
- lors de l'appel à SetWindowsHookEx, ne pas indiquer de thread (4e paramètre à zéro)
 
Pourtant, seuls les messages de souris adressés à mon appli sont filtrés par mon hook. Quelqu'un voit une raison possible à ça ?

Personne ne s'interresse aux hooks ? Vous devriez, c'est caotivant comme truc, et ça offre des possibilités assez énormes.

Il ressemble à quoi ton filtre ?

J'ai pas le code ici, mais le problème est le même en réduisant le code au strict minimum, c'est à dire :
- définition de la fonction MouseProc comme demandé dans la MSDN.
- cette fonction retourn 0, tout simplement (normalement elle devrait retourner CallNextHook, mais ne pas le faire a juste puor effect de corrompore le fonctionnement d'éventuels autres hook de souris installés).
Bref, je pense pas que ça vienne de la fonction filtre.

En fait, je veux savoir comment tu sais si ton hook fonctionne ou pas ?
As-tu un lien quelconque avec ton appli d'origine (handle...), utilises-tu les MFC dans ta dll ?

Je sais si mon hook fonctionne ou pas parce qu'il a effectivement un lien avec mon appli principale : il affiche les coordonnées du pointeur à chaque message de souris reçu.
Pour cela, la dll possède un pointeur vers l'instance "CMouseCommanderApp" (donc, oui, j'utilise les MFC dans mon appli, ET dans ma dll). pourquoi ?
 
Apparement, ce que je faisais ne pouvait pas fonctionner : je ne précisait pas explicitement que le pointeur vers "CMouseCommanderApp" contenu dans la dll était une donnée partagée (fixé avec un pragma). Maintenant que je le fais, ça semble la même chose : les données ne semblent pas être partagées.

EDIT :
Le modèle de pragma utilisé est le suivant :
http://www.flounder.com/hooks.htm

Tu ne peux pas appeler une fonction de ton process depuis ta dll hook.
Cette dll est mappée dans l'espace d'adressage de tous les processus qui appelent son code quand il faut (enfin, Windows le leur fait appeler).
Donc, il faut voir le code de ta dll comme s'il était exécuté depuis une autre appli. Et cette autre appli, quand elle tente d'appeler une fonction de ton process, je te laisse deviner la suite.  
Il faut donc utiliser un mécanisme cross-process pour communiquer entre ta dll et ton appli.
Pour cela, code en Win32 pur dans ta dll (car je ne pense pas que les MFC soit chargées dans les autres applis) et communique avec ton appli via des messages. Ta section shared ne doit contenir que le handle Win32 et pas un CWnd * de ton appli.
Tout ça est bien expliqué dans l'article de flounder. Faut lire jusqu'au bout...

Hé oui, j'suis en multi-process en fait, vu que ma dll est attachée entant que hook à chaque thread. Du coup ça devrait quand même être possible en synchronisant avec des mutex et tout le toutim, non !?
Evidement, c'est beaucoup plus simple de communiquer simplement par messages.
Merci beaucoup.

L'adresse de la fonction du process A n'a de sens qu'au sein du process A. Si le process B effectue un appel à cette adresse, il n'appelera pas la fonction de A, mais soit une fonction à lui (B) soit ça plante. Chaque process a son propre espace d'adressage privé.
Ta dll stocke un pointeur d'instance de classe créé par A.
Ce pointeur n'a aucun sens au sein du process B. Sinon, ça voufrait dire que si le process A crée une instance de ta classe X, celle-ci est créée dans tous les autres process...

ok, compris.
Par contre, ça y est, j'ai mis en place une communication par messages : je transmet un message de mon cru à ma fenêtre principale à chaque fois que mon filtre attrappe un message de souris. Mais ça pose encore PB dès que des messages viennenent d'un autre thread que celui de mon appli. J'comprend pas !!!
Je poste mon code d'ici 2 minutes...

Voila le code de mon Hook, au plus simple :
 

 
 
Et voici le code (enfin, la partie qui nous interressé) de mon appli principale :
 

Utilises déjà le message enregistré sinon ton g_WmHook ne sert à rien vu que tu l'utilises pas.
T'as besoin que de g_hMouseHook et de g_hWndMC en shared.

Non, mais j'en ai pas besoin du message enregistré. Je sais que je l'utilise pas, c pas grave.
Dans mon MyHooks.h, j'ai un

Que j'attrape bien dans la fenêtre à laquelle jel e passe.

Met des MessageBeep dans ta MouseProc pour savoir si c'est un pblm de hook ou d'envoie de message.

C'est super chiant à débugger les hook système : VC++ aussi reçoit des messages de souris.
En fait, en l'état,le comportement est le suivant :
Tant que je reste dans ma fenêtre principale, ou dans une fenêtre fille (les différents contrôles de ma fenêtre), ça marche nickel. Dès que je sors mon pointeur de la fenêtre (les messages de souris filtrés par le hook sont issus d'un autre thread), j'ai un plantage plutôt violent : tout se freeze, et je ne peux plus rien faire. Juste redémarrer le PC avec le bouton reset. Pas simple à débugger tout ça. :-(

J'ai testé ton WM_USER+1 dans les MFC en debug, hop, assertion failed. Il veut du register message.
 
Au fait, c'est quoi ton OS ?

 
Mon WM_USER passe très bien chez moi, tant que j'suis dans la fenêtre courante, mais je doute que ce soit lié. D'ailleurs j'utilise courament ce type de message en MFC. ton assertion doit venir d'autre chose.
 
Mo OS c'est XP (donc NT).

Fait un truc genre MessageBeep dans ta dll pour savoir si le hook fonctionne ou pas.
Si oui, c'est un pblm d'envoie de msg à ton appli.
Je pense à un truc aussi, remplace SendMessage par PostMessage.
Il se pourrait que tu entre dans un truc récursif.

 
Apparement, l'envois de message est OK :  
Si je supprime tous les traitements effectués lorsque mon appli principale reçoit le message, ça semble mieux...