WinAPI-Fenster in Direct3D Anwendung einblenden und bedienen?!
-
Hi!
Ich will es eigentlich schon ausprobieren, frage aber doch lieber kurz hier nach, ob es nicht sowieso unmöglich ist, was ich vorhabe:
Anwendung 1 erzeugt ein normales Fenster mit dem WinAPI, mit ein paar Controls.
Anwendung 2 ist im Direct3D (8 und 9) Vollbildmodus.Man kann nun am Desktop ganz normal das Fenster von Anwendung 1 bedienen.
Genau das soll man aber auch in der Direct3D-Vollbildanwendung tun können. Eben genau dieses Fenster soll eingeblendet werden und bedienbar sein, als wäre man am Desktop.Ich dachte mir das so, dass per IPC (Inter-process communication) die Daten ausgetauscht werden:
Anwendung 1 schickt einmalig die Pixeldaten des Fenster-DC (DeviceContext) an Anwendung 2. Diese blendet dadurch das Fenster (client area reicht erstmal) in Direct3D ein.
Anwendung 2 checkt per DirectInput die Mauskoordinaten. Liegen sie im eingeblendeten Fenster, schickt sie die Koordinaten/Klicks an Anwendung 1. Diese setzt virtuelle mouse-moves/clicks um. Dadurch soll eben virtuell bedient werden.
Anwendung 1 schickt außerdem bei jedem WM_PAINT die relevanten Daten an Anwendung 2, damit diese (nur die nötigen) Areale neu zeichnet.Kann das funktionieren? Kann man so in Direct3D das Fenster der Anwendung 1 "virtuell" bedienen? (Auch, wenn das Fenster der Anwendung 1 unter Windows versteckt (ShowWindow(..., false)) ist?)
-
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Spiele-/Grafikprogrammierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Kann theoretisch natürlich funktionieren. Es gibt sogar Hacks um an die Textur des Fensters im DWM zu kommen (setzt natürlich voraus dass Compositing aktiviert ist).
-
Ohne Desktop-Composition wirst du nicht so einfach an die "Pixeldaten" des Fensters drankommen, wenn es verdeckt oder hidden ist.
-
Wenn es minimiert oder gar versteckt ist, wird es natürlich schwer, ansonsten bietet sich
PrintWindow
an (funktioniert bei mir zumindest unter XP auch bei verdeckten Fenstern reibungslos).Da ich auch etwas an diesem Thema interessiert bin, habe ich mal ein wenig rumgespielt:
Natürlich kannst du nicht die WM_MOUSEMOVE und WM_LBUTTON..-Nachrichten direkt senden, stattdessen musst du einen Umweg um selbstdefinierte Nachrichten gehen.
Der LPARAM, also die Cursorkoordinaten müssen natürlich umgerechnet werden. Das heißt, falls das Fenster auch noch einen Rahmen hat, müssten mittels GetSystemMetrics die x- (SM_CXBORDER) und y-Koordinate (SM_CYCAPTION) verändert und der geänderte LPARAM als z.B.msg-WM_MOUSEMOVE+WM_USER
gesendet werden.
Die Anwendung, die diese WM_USER-Nachrichten empfängt, müsste nun ihrerseits das betroffene Childfenster bestimmen (ChildWindowFromPoint), und die Nachricht wieder als WM_MOUSEMOVE bzw. WM_L/R_BUTTON.. an das Control senden.
Mit selbstdefinierten Controls hat das bei mir alles wunderbar geklappt, Windows hat aber noch eine zusätzliche Logik, wahrscheinlich werden WM_LBUTTON..-Nachrichten nur ausgewertet, wenn das Control auch den Fokus hat, da bin ich mir jedoch nicht ganz sicher.* Wenn das so wirklich so ist, kannst du natürlich keine Standard-Controls nehmen, da SetFocus nur funktioniert, wenn das Top-Level-Fenster den Focus inne hat.
Komplizierter wird es natürlich noch mit den WM_NC-Nachrichten, dazu müsste wahscheinlich noch WM_NCHITTEST gesendet und ausgewertet werden, in dieser Richtung habe ich jedoch auch nichts probiert.
Insgesamt passt dein Nick zum Thema
*Funktioniert doch,
aber einige Controls wie eine Combobox, setzen den Focus auf ihre Listbox, die Vollbildanwendung würde minimiert werden. Daher(Edit: Trotzdem) fallen alle Controls dieser Kategorie natürlich flach.Edit2: Die Listbox wird nur im Vordergrund angezeigt, der Fokus wird nicht neu gesetzt.