Deux questions.Problèmes de 'sous-classes de processus croisés'
1) Je comprends que cela doit être un résultat attendu, mais peut-être quelqu'un peut me dire ce que je fais mal; J'essaye de sous-classer toutes les classes de fenêtres dans un hook global et cela fonctionne excepté que je ne peux pas fermer boutique comme je devrais et quand le programme enregistrant le hook désinscrit le hook et quitte, les applications sous-classées commencent à s'écraser.
Voilà comment je suis en train de le faire ..
// stores original wndprocs. In the hook dll, outside the shared memory.
map<HWND, WNDPROC> origWndProcs;
// in an EnumWindows callback, executed for all HWND's, also in the hook dll (UWM_REMOVE_HOOK is a registered unique message)
SendMessageTimeout(hWnd, UWM_REMOVE_HOOK, 0, 0, SMTO_ABORTIFHUNG | SMTO_NORMAL, 15000, res);
// Still in the same hook, in the subclassing wndproc..
if (msg == UWM_REMOVE_HOOK) {
if (origWndProcs.find(hwnd) != origWndProcs.end()) {
SetWindowLongPtr(hwnd, GWL_WNDPROC, (LONG_PTR)origWndProcs[hwnd]);
}
}
// clears the hook..
__declspec(dllexport) BOOL ClearHooks(HWND hWnd) {
BOOL unhooked = UnhookWindowsHookEx(hook) &&
UnhookWindowsHookEx(kb_hook) &&
UnhookWindowsHookEx(mouse_hook) &&
UnhookWindowsHookEx(cbt_hook);
if(unhooked)
hWndServer = NULL;
return unhooked;
}
En DllMain je ne fais rien sur DLL_PROCESS_DETACH. Au lieu de cela, ClearHooks() est appelé depuis le programme enregistrant les hooks à l'origine et seulement après que le hook a envoyé un message signalant qu'il a exécuté l'opération EnumWindows (restaure les wndprocs d'origine, voir ci-dessus).
Je sous-classe des fenêtres dans un crochet WndProc; Toutes les fenêtres visibles qui reçoivent un message et dont le wndproc actuel n'est pas celui de la DLL sont sous-classées.
Fondamentalement toutes (pour autant que je sache) les applications se bloquent à la sortie malgré le fait que les fenêtres semblent remettre l'ensemble wndproc à ce qu'il était lorsqu'il a été remplacé. Quelqu'un at-il une idée de ce que je pourrais faire de mal?
2) J'ai besoin de ceci pour intercepter WM_MINMAXINFO et modifier la taille maximale de la fenêtre chaque fois qu'une fenêtre est agrandie. Malheureusement, je ne peux pas le faire dans la DLL, mais je dois parler avec un programme pour obtenir les informations de taille. Alors, quelle est la meilleure façon de parler à cette fenêtre? J'en ai besoin pour passer en revue quelques informations afin que je puisse modifier la structure fournie avec le message original WM_MINMAXINFO. Une structure de WM_COPYDATA va-t-elle conserver ses données jusqu'à ce que l'appel à SendMessageTimeout soit de retour?
Merci
"Vous supposez qu'aucun autre code ne sous-classe la fenêtre." Touché .. "Mais, la solution de contournement est assez simple: vous utilisez déjà SetWindowsHookEx, vous pouvez en faire un de plus: WH_CALLWNDPROC ou WH_CALLWNDPROCRET, selon ce que vous voulez faire." Je ne suis pas sûr à 100%. Suggérez-vous que je sous-classe toujours dans le hook WH_CALLWNDPROC et unubclass dans un hook WH_CALLWNDPROCRET? Merci quand même, je commence à voir les problèmes avec mon code :) – 72con
Non, ces crochets peuvent faire le travail que vous faites maintenant en sous-classant. –
Je vais devoir modifier la valeur envoyée avec le message (structure MINMAXINFO envoyée avec un message WM_MINMAXINFO), je suppose que je ne serai pas capable de le faire dans une procédure de hook mais je devrais le faire en sous-classant la procédure de fenêtre ? MSDN me dit que ni WndProc ni WndRetProc ne seraient capables de modifier le message. – 72con