Intégration de HWND dans un processus externe en utilisant SetParent

Question

J'essaie d'intégrer une fenêtre de mon processus dans la fenêtre d'un processus externe en utilisant la fonction SetParent et j'ai rencontré quelques problèmes que j'espère que quelqu'un peut m'aider avec. Tout d'abord, est ici un aperçu de ce que je suis en train de faire pour intégrer ma fenêtre dans l'application:

HWND myWindow; //Handle to my application window 
HWND externalWindow; //Handle to external application window 

SetParent(myWindow,externalWindow); 

//Remove WS_POPUP style and add WS_CHILD style 
DWORD style = GetWindowLong(myWindow,GWL_STYLE); 
style = style & ~(WS_POPUP); 
style = style | WS_CHILD; 
SetWindowLong(myWindow,GWL_STYLE,style); 

Ce code fonctionne et ma fenêtre apparaît dans l'autre application, mais présente les questions suivantes:

• Quand mon focus d'entrée sur les gains de la fenêtre, la fenêtre principale de l'application du processus externe perd le focus (c.-à-barre de titre change de couleur)
• commandes de raccourcis clavier de l'application principale ne fonctionne pas alors que ma fenêtre a le focus

Est-ce que quelqu'un sait une solution de contournement pour cela? Je voudrais que ma fenêtre soit traitée comme une autre fenêtre enfant de l'application principale.

Answer 1

Eh bien, j'ai finalement trouvé la réponse à ma question. Pour résoudre ce problème, vous devez utiliser la fonction AttachThreadInput pour attacher le fil de la fenêtre intégrée au fil d'application principal.

En outre, on peut utiliser la fonction TranslateAccelerator en réponse aux messages WM_KEYDOWN pour garantir le déclenchement des messages d'accélération de l'application principale.

Answer 2

J'ai trouvé quelques informations à ce sujet au Catch22.net en utilisant le message WM_NACTIVE.

C'est dans la section Empêcher la désactivation de la fenêtre. Espérons que cela aide.

Answer 3

Je ne sais pas si vous êtes toujours intéressé par ce sujet après presque trois ans. Je travaille sur une application similaire. Ma solution consiste à modifier le style de la fenêtre avant d'appeler SetParent. Avec cette solution, je n'ai pas besoin d'appeler AttachThreadInput. Toutefois, l'un des principaux problèmes liés à l'hébergement de fenêtres enfants à partir d'un processus externe est que si le processus externe se bloque en réponse à un clavier ou à une entrée de souris utilisateur, l'application principale se bloque également. La boucle de message dans l'application principale est toujours en cours d'exécution. Cependant, il ne reçoit plus les événements d'entrée de l'utilisateur. Par conséquent, il semble que c'est suspendu. Je crois que c'est le résultat direct de AttachThreadInput puisque les événements d'entrée des deux threads sont maintenant synchronisés. Si l'un d'eux est bloqué, les deux sont bloqués.

Answer 4

J'ai rencontré le même problème, après avoir lu attentivement doc MSDN, j'ai trouvé une solution facile.

Vous devez supprimer WS_POPUP et ajouter WS_CHILD AVANT vous appelez setParent

Il est indiqué dans MSDN:

Pour des raisons de compatibilité, SetParent ne modifie pas les styles fenêtre WS_CHILD ou WS_POPUP de la fenêtre dont le parent est être changé. Par conséquent, si hWndNewParent est NULL, vous devez également effacer le bit WS_CHILD et définir le style WS_POPUP après avoir appelé SetParent.Inversement, si hWndNewParent n'est pas NULL et que la fenêtre était précédemment un enfant du bureau, vous devez effacer le style WS_POPUP et définir le style WS_CHILD avant d'appeler SetParent.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms633541(v=vs.85).aspx