Haftungsausschluss: Ich bin nicht mit der Win32-API vertraut, insbesondere mit der Funktionsweise von Windows.

Ich möchte das Fenster eines Prozesses zu einem untergeordneten Fenster eines anderen Prozesses machen. Die beiden Prozesse sind auch Eltern und Kind. Aber ich denke nicht, dass das wichtig ist. Bisher funktioniert alles wie ein Zauber - Bis ich den Hauptthread des Kinderfensters einfriere.

Stellen Sie sich eine container.exe vor, die notepad.exe und someApplication.exe hostet

Wenn ich den Hauptthread von aussetzesomeApplication.exe für ein paar Sekunden ist sein Fenster für diese Zeitspanne eingefroren. Das ist durchaus verständlich. Aber das Fenster voncontainer.exe werdenebenfalls für die gleiche Zeit hängen. Die untergeordneten Fenster anderer gehosteter Prozesse (znotepad.exe) wird weiterhin gut funktionieren.

Ich benutze dieSetParent Befehl, um ein reguläres nicht untergeordnetes Fenster zu einem untergeordneten Fenster von my container.exe zu machen:

SetParent(
    childProcess.HWND,
    myOwnHWND
);

Danach benutze ichsetWindowPos:

SetWindowPos(
    childProcess.HWND,
    HWND_TOP,
    someXPos,
    someYPos,
    0,
    0,
    SWP_FRAMECHANGED or SWP_NOSIZE or SWP_SHOWWINDOW
)

Als dieMSDN-Artikel zu SetParent schlägt vor, ich lösche auch dieWS_POPUP Stilattribut und fügen Sie einWS_CHILD Attribut. Da das auch nicht geholfen hat, fügte ich noch einen hinzuWS_EX_NOACTIVATE erweitertes Stilattribut, beide mit demSetWindowLongPtr Befehl. Schließlich habe ich versucht, beide Fenster aWM_UPDATEUISTATE und dann aWM_CHANGEUISTATE Nachricht, aber das hat auch nichts geändert.

Was mich verwirrt ist, dass das Fenster des übergeordneten Prozesses weiterhin normal gezeichnet wird, bis ich es berühre. Dann friert es vollständig ein, bis sich das untergeordnete Fenster öffnet. Ich vermute so etwas wie eine'eingabewarteschlange'. DasMSDN-Artikel über einenWM_ACTIVATE Nachrichtenstatus:

Wird sowohl an das aktivierte als auch an das deaktivierte Fenster gesendet. Wenn die FensterVerwenden Sie dieselbe Eingabewarteschlangewird die Nachricht gesendetsynchronzuerst zur Fensterprozedur des Fensters der obersten Ebene, die deaktiviert wird, dann zur Fensterprozedur des Fensters der obersten Ebene, die aktiviert wird. Wenn die Fenster unterschiedliche Eingabewarteschlangen verwenden, wird die Nachricht asynchron gesendet, sodass das Fenster sofort aktiviert wird.

Aus diesem Grund hatte ich große Hoffnungen auf dieWS_EX_NOACTIVATE erweitertes Stilattribut.

Fazit: Ist es tatsächlich möglich, das Fenster eines anderen Prozesses zu hosten und das eigene Fenster nicht einzufrieren, wenn das untergeordnete Fenster einfriert?