tags:

views:

300

answers:

4

Theres some reason for this code not reach the first else? I got it exactly the same from vairous sources. Than I did my own encapsulation. Everything goes fine. Window is created, messages are treated, events are generated to keyborad input in the client area, the gl canvas works fine (when I force it to draw).

The only problem is that message loop never leaves the first if. :/ I'm really stuck.

while (!done)          
{
 if (::PeekMessage (&msg, NULL, 0, 0, PM_REMOVE))
 {
  if (msg.message == WM_QUIT)     
  {
   done = TRUE;       
  }
  else          
  {
   ::TranslateMessage (&msg);    
   ::DispatchMessage (&msg);    
  }
 }
 else          
 {
  // Code is never reaching this!
  draw ();
  ::SwapBuffers(hDC);
  idle ();
 }
}
return msg.wParam;
A: 

May be there is always a message waiting ?

Emmanuel Caradec
A: 

PeekMessage will return 0 only if there are no messages in the message queue. Since there are messages to be dispatched in the message queue, it is returning a non-zero value and your else condition is never executed.

Naveen
I guess he is asking about this - why doesn't it ever happen that there're no messages left.
sharptooth
+6  A: 

In your case the message queue must never be empty - why? Well it depends on what the rest of your program is doing. Some possibilities:

  1. Your code is posting new messages to the queue in a manner such that the queue doesn't get empty. I'd suggest logging out the message ids as they are handled.

  2. You aren't handling paint messages - from msdn: "The PeekMessage function normally does not remove WM_PAINT messages from the queue. WM_PAINT messages remain in the queue until they are processed. However, if a WM_PAINT message has a NULL update region, PeekMessage does remove it from the queue."

Hope this helps.

[Edit] To handle WM_PAINT either call BeginPaint and EndPaint or forward to DefWindowProc

morechilli
looks like thats the problem. But, the my MainWndProc is returning 0 from WM_PAINT. What I know is that every message you treat, you return 0. So, in theory, no message should be left.
Ruben Trancoso
He's handling WM_PAINT because he's seeing things appearing.
Daniel Earwicker
Added this code and it start to work as expected. But would like to have some explanation if possible please. case WM_PAINT: BeginPaint(hwnd, EndPaint(hwnd, return 0;
Ruben Trancoso
WM_PAINT isn't a real message - it's just a flag on the window that says it has invalidated regions (WM_PAINT never handled.) As long as that flag is present, WM_PAINT will be generated.
Michael
there isnt another way to acomplish that? looks like this will just add more processing to my program instead if just discard the message.
Ruben Trancoso
looks like you can also do it by forwarding wm_paint to DefWindowProc but it probably does the same thing
morechilli
+2  A: 

Make sure you are processing the WM_PAINT correctly.

By this I mean make sure you are calling BeginPaint and EndPaint from inside the WM_PAINT message, otherwise you will be confusing Windows into thinking your application still needs to be painted.

jussij