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

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

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

c ya, cPanther

Was möchtest Du denn erreichen?

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)

* 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

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.

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.