Zweite WndProc in eigenem Thread
-
SchlechterInformatiker schrieb:
Was sind das für Nachrichten. Die Windows API kennt diese nicht!
Diese Nachrichten sind in der WinUser.h definiert.
Nachrichten?
Das sind Konstanten für ShowWindow!WM_SIZE bekommst Du und dort erfährst Du z.B. etwas über minimieren und maximieren.
SchlechterInformatiker schrieb:
Du kannst in einem Thread keine Nachrichten für ein Fenster aus einem anderen Thread empfangen oder abarbeiten.
Gibt es da gar keine Möglchkeit? Wenn nicht, dann hab ich ein Problem. Oder kann man anhand von einer Abfolge von WM_ Messages genau sagen, dass das Fenster minimiert wurde?
Wenn das Fenster der Engine minimiert wurde, muss ich den Server (meine DLL) anhalten und darf erst wieder gestartet werden wenn das Fenster der Engine wieder maximiert wurde...
Mit einem Thread bekomst Du das so nicht hin. Du kannst höchstens extern den Stil des Fenster kontrollieren. GetStyle, WS_MAXIMIZE/WS_MINIMIZE
Aber Dein Hauptthread muss doch auch eine Fensterprozedur haben?
Warum verwendest Du diese nicht, oder hast Du keine Kontrolle über die?Ansonsten kannst Du einfach einen subclass auf die Fenster-Prozedur durchführen und selbst auf WM_SIZE reagieren. Das ist mit Sicherhit die eleganteste Methode, wenn Du an die Fenster-Proc. nicht ran kommst.
-
At Martin:
als MVP weißt Du dass bestimmt.
Um Msg in einen seperaten thread handzuhaben mache ich folgendes:
MSG msg={0}; while(!(pw->rss.bDone)){ if(PeekMessage(&msg,pw->wss.hWnd, NULL, NULL, PM_REMOVE)) { pw->pss.dwcDrawWindowCallback(msg.hwnd,msg.message, msg.wParam, msg.lParam); } else { Sleep(10); }Die frage ist nun (rein theoretisch ohne die CPU last zu checken),
ist es effizienter DispatchMsg aufzurufen wenn ich im Thread nur EIN Fenster habe ? (zb ein OpenGL window)...Seit gegrüßt
-
Der Haupt-Thread wird nicht von mir kontrolliert. Wie gesagt, ich schriebe eine DLL welche in ein existierendes Pogramm (die Engine) eingebunden wird.
Das mit den SW_MINIMIZE und SW_MAXIMIZE hab ich dann tatsächlich falsch verstanden. Diese Konstanten sind also quasi dazu da, um zu veranlassen dass mein Fenster minimiert/maximiert wird?!
Ich weiß nicht ob ich das hinbekommen würde mit der SubClass. Ich kann doch nicht diese ganze Engine beerben. Ich weiß ja noch nicht mal in welcher Klasse diese Fensterprozedur drin ist, geschweige denn wie diese zu überladende Fenster-Prozedur heißt.
Ich schau mir mal GetStyle() an...
-
Auch für GetStyle (GetWindowLong) brauchst Du ein Fenster Handle!
Ohne Handle kommst Du nicht weit.
Eine DLL ist ein Container für Code. Eine DLL ist kein Prozess. Eine DLL gehört zu einem Prozess. Eine DLL hat keine Threads. Aber Threads können Code in DLLs ausführen...
-
Das Handle der Engine hab ich.
Aber ich komme mit GetStyle nicht zurecht. Ich finde keine GetStyle(GetWindowLong) bei MSDN. Ich finde nur GetStyle() - ohne Parameter. Und da komme ich mit den includes nicht klar. Ich finde nichts wo ich ein Window Handle übergeben kann.
Kannst du mir sagen wo dieses GetStyle(GetWindowLong) definiert ist, welches du meinst?
-
GetStyle ist in der MFC en Wrapper für GetWindowLong. Dort gibt es einen GWL_STYLE. Das wiederum gibt dir den aktuellen Stil (WS_MAXIMIZE an).
Aber: Wenn Du das Handle der Engine hast (was auch immer das ist), dann mach doch einen Subclass. Dann bekommst Du brav die WM_SIZE Nachricht und kannst diese sofort behandeln.
-
Die Engine erzeugt das Fenster. Und von der Engine kann ich mir das HWND dieses Fensters geben lassen. Ich kann mir auch die HINSTANCE geben lassen.
Kann man daraus eine SubClass machen??
Ich kenne den Begriff nur aus der Vererbung. Verstehst du etwas anderes darunter?
-
Also gut, mit dem WM_SIZE (was ich sowieso schon immer empfangen habe) in Kombination mit einem weiteren Channel,
der mit der Engine mitgeliefert wurde, hab ich es hinbekommen, meine Netzwerk-Channels rechtzeitig anzuhalten.Aber nochmal die Frage anders herum gestellt: Ist WM_SIZE die einzige WindowMessage, anhand der man erfährt, dass das Fenster minimiert worden sein könnte
(mal abgesehen davon, dass WM_SIZE auch dann auftritt, wenn das tatsächlich die Größe des Fensters verändert wurde)?? Wieso gibt es nicht einfach ein WM_MINIMIZE und ein
WM_MAXIMIZE damit die Anwendungen erfahren dass das Fenster gerade minimiert/maximiert wurde?@Martin Richter: Danke für den Tip!
-
Ich frage mal zurück:
Warum soll man noch eine Nachricht einbauen, wenn die Nachricht über die Größenänderung diese Information einschließen muss?Also anders:
Nein! IMHO ist WM_SIZE die einzige Nachricht, die Dir diese Info liefert, außer eben den Style Infos mit denen man diese Info jederzeit abfragen kann.
-
Warum soll man noch eine Nachricht einbauen, wenn die Nachricht über die Größenänderung diese Information einschließen muss?
Weil WM_SIZE ja nicht nur bei Minimieren/Maximieren gesendet wird, sondern auch beim Ändern der Fenstergröße.
In meinem Fall z.B. muss ich den NetzwerkChannel nur anhalten wenn das Fenster minimiert wurde, nicht aber wenn die Größe des Fensters geändert wurde.
Da ich jetzt auf WM_SIZE reagiere wird in dem Fall, dass das Fenster lediglich vergrößert/verkleinert wurde, unnötigerweise den NetzwerkChannel angehalten weil ich ja nicht unterscheiden kann ob das Fenster minimiert wurde oder nur seine Größe verändert wurde.
Daher würde ich es schon sinnvoll finden, für's Minimieren/Maximieren eigene Messages zu senden - und zwar nur dann wenn eben minimiert/maximiert wird und sonst nicht.
Es sei denn, es gibt eine bestimmte Abfolge an Messages, anhand der ich erkennen kann dass das Fenster minimiert/maximiert wurde und nicht die Größe geändert wurde, wie z.B.
WM_SIZE
...
WM_KILLFOCUSfürs Minimieren und
WM_SIZE
...
WM_ACTIVATEfürs Maximieren
(nur als Beispiel - kein Anspruch auf Richtigkeit!)Gibt es solche Abfolgen, ahand denen man ein Minimieren/Maximieren des Fensters erkennen kann? Wenn ja, wie lautet die Abfolge bzw. gibt es irgendwo im Internet eine Doku darüber oder muss ich mir das mit viel Debugging und den wenigen Informationen bei MSDN zu den Benachrichtigungen selber irgendwie zusammenspinnen?