4. mal wieder wndproc und WM_SIZE

mal wieder wndproc und WM_SIZE

  • A

    Hi

    Habe nun folgendes Problem:

    Ganz simples win32 setup:

    //...
while(PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
   {
   if(msg.message == (WM_SIZE + WM_USER))
     std::cout << "<user defined>" << msg << std::endl;
   TranslateMessage(&msg);
   DispatchMessage(&msg);
   }
// ...

//...
//wndproc
//...
switch(msg_)
   {
	// hier nochmal explizit dargestellt
   case WM_SIZE:
	   PostMessage(hWnd_, msg_ + WM_USER, wParam_, lParam_);
	default:
	   PostMessage(hWnd_, msg_ + WM_USER, wParam_, lParam_);
   }
//...

    ... so ungefähr sieht's aus. Das Problem ist, das PostMessage die Nachricht
    msg + WM_USER _nicht_ in die queue stellt, wenn msg == WM_SIZE ist. Das event
    (msg + WM_USER, also WM_SIZE+WM_USER) wird durch PostMessage (scheinbar) sofort
    an die WndProc geschickt, so das ich's nicht per PeekMessage abfangen kann...

    Hat jemand eine Erklärung für das Verhalten?
    Andere events werden anstandslos in die queue eingefügt,... komisch. 😕

    c ya, cPanther

    0
  • E

    Die Erklärung ist eigentlich so einfach wie nicht-hilfreich: Weil Windows es so will.

    Für selbstdefinierte Nachrichten sollte man nicht WM-Nachrichten addieren. Du weißt ja nicht, welche Nachrichten-ID dabei herauskommt (außer, Du frickelst die winuser.h durch). Für eigene Nachrichten sollten immer jeweilige Konstanten verwendet werden, z. B. WM_OWN = WM_USER + 1

    0
  • A

    mh, per definition sollte aber WM_MSG + WM_USER immer > WM_USER und < 0x7fff sein. Zumindest ist's so im SDK beschrieben...

    Also, im endeffekt heisst's, PostMessage macht schlicht mehr als nur die queue zu befüllen...
    Na toll.. 😞

    c ya, cPanther

    0
  • Mod

    Was hast Du denn erwartet? Zudem hast Du doch hier nur einen Thread. Während WM_SIZE ausgeführt wird, wird eben keine andere Nachricht aus der Queue gezogen und das ist gut so.

    Was möchtest Du denn erreichen?

    0
  • P

    Hmm, normalerweise geht das schon auch mit nur einem Thread.
    Trotzdem ist Martins Frage berechting: wieso willst du die Ausführung verzögern?

    Ist das der "richtige" Code? Was mir an dem geposteten code auffällt:

    * keine break-statements, nach PostMessage fällt die Abarbeitung zum default-Zweig durch
    * kein (expliziter) handler für WM_SIZE+WM_USER
    * Soll die Standard-Behandlung von WM_SIZE ablaufen?

    Ist das Control ein eigenes Fenster, oder abgeleitet / subclassing eines existierenden? (Dann wäre WM_USER falsch)

    0
  • A

    @peterchen

    * keine break-statements, nach PostMessage fällt die Abarbeitung zum default-Zweig durch
    * kein (expliziter) handler für WM_SIZE+WM_USER
    * Soll die Standard-Behandlung von WM_SIZE ablaufen?

    ...ist im Original schon i.O., ganz dämlich bin ich ja nich, ... 😃

    siehe...

    ... so ungefähr sieht's aus.

    😃

    Ich will die Ausführung nicht vorsätzlich verzögern, ich will nur, unabhängig von der WndProc, Nachrichten "abfangen" können.
    So wie's PeekMessage ja auch zur hälfte schon macht... zur hälfte...

    In anderen libs ist's nochmal, events mit nur einer Funktion abzuholen
    (SDL_Pollevent, etc... ...)

    zum "wofür":
    Das ganze ist "nur" prototyping, halt Durchspielen aller irgend möglichen Messaging-Scenarien (auf x-platformen, z. Z. eben unter Win32)

    c ya, cPanther

    0
  • P

    Wie gesagt - sollte funktionieren (wenn du alles richtig machst :D).

    Was fehlt denn? Die Ausschrift in der Message Loop?

    > ich will nur, unabhängig von der WndProc, Nachrichten "abfangen" können.

    Naja, wird so nicht immer funktionieren.
    MessageBoxen und Modale Dialoge (außer denen der MFC/ATL) haben ihre eigene Message Loop.

    also, ich würd' vorschlagen: eigene WNDPROC, subclassen, oder Message Hook.

    0
  • Mod

    PeekMessage fängt keine Nachrichten ab.
    Nachrichten kann man per Subclassing oder per Hook abfangen.
    PeekMessage schaut nurin die Message Queue rein, und in der landet nur ein Bruchteil der Windows Nachrichten (Faustregel: Alles was mit Eingabe des Users zu tun hat, oder IPC).

    0
  • A

    So, hab mir grad die sources einiger anderer frameworks angschaut...
    dort wird alles per PeekMessage abgefangen. was dabei nicht abgefangen wird
    wird in eigenregie ausgelöst. (WM_PAINT != SDL::OnPaint, etc...)

    Hm, per Subclassing hab ich ja das gleiche Problem, die Nachricht kommt in der (na gut,... in einer anderen 😉 ) WndProc an.
    Ich will aber autonom abfangen...

    na egal, ich schau grad, inwieweit ich die WndProc auf ein entspr. interface biegen kann...

    c ya, cPanther

    Edit:
    per Hooks, darauf bin ich ja noch gar nich gekommen,... gleich mal ausprobieren.

    0
Anmelden zum Antworten