   Why can't the game idle proc be launched by a message ?
  Hi guys,I have a classic loop using PeekMessage, which I use on a prototype :void doStuff(){  // A final version would be along the line of :  // idle();  // render();  cout << "Doing stuff..." << endl;  Sleep(500);  cout << "done." << endl;}// ...// in function main :MSG msg;bool bQuit = false;while(!bQuit){  doStuff();  while (PeekMessage(&msg, hwnd, 0, 0, PM_REMOVE))  {    if (WM_QUIT == msg.message) bQuit = true;    else    { TranslateMessage(&msg); DispatchMessage(&msg);    }  }}// ...// in my WndProc : (this is the msg proc of a window spawned by a console)case WM_CHAR:  cout << "Char Msg:" << toConsoleDisplayable(wparam) << endl;  break;Everything is fine here. The console output of this when I press 'A' once in a while (or with passion :p), when the window has focus is a nice stream of :Doing stuff...done.Char Msg:aChar Msg:aDoing stuff...done.Char Msg:aand so on.Then I wanted to mess around a little with only GetMessage() calls and tried this instead :#define WM_DOSTUFF (WM_USER+1)// in function main :MSG msg;PostMessage(hwnd, WM_DOSTUFF, 0, 0);while (GetMessage(&msg, hwnd, 0, 0)){  TranslateMessage(&msg);  DispatchMessage(&msg);}// in my WndProc :case WM_CHAR:  cout << "Char Msg:" << toConsoleDisplayable(wparam) << endl;  break;case WM_DOSTUFF:  doStuff();  PostMessage(hwnd, WM_DOSTUFF, 0, 0);  break;and... using the second way, no input message was ever processed. My output was a succession of "Doing stuff..." / "done.", no matter how hard I pressed a key :pNow, I have no problem with using PeekMessage and leaving my game loop as it was, I just wanted to understand why the second approach wouldn't work.Thanks !   
  Sorry, haven't dig myself into your post, but this shouted at me:WM_DOSTUFF:  doStuff();  PostMessage(hwnd, WM_DOSTUFF, 0, 0);this posts a message to itself. If nothing else posts the same message, you never get here. If once something posts the message, you will get a beautiful form of infinite loop. Maybe that's you intent, but that1s the most stupid (sorry) way to make a message loop. If it works at all. (Again, haven't dig myself into it) What's your problem with the ordinary way?EDIT: yup I read your post, it's just a theoretical question.I don't know the answer...   ;  You might want to use a timer. SetTimer(hWnd, ID, millisec, NULL), and then you receive a WM_TIMER message in your WndProc, where wParam is the ID.Not sure about PostMessage, perhaps it places the message in front of the queue.. or for some other reason keeps other messages from getting the chance to be handled when constantly posting a new message.   ;Quote:Original post by Erik RufeltYou might want to use a timer. SetTimer(hWnd, ID, millisec, NULL), and then you receive a WM_TIMER message in your WndProc, where wParam is the ID.Not sure about PostMessage, perhaps it places the message in front of the queue.. or for some other reason keeps other messages from getting the chance to be handled when constantly posting a new message.Yup, MSDN doesn't mention, if the message if put in front of the queue or at the end. If the latter, the OP's code should work I think...   ;Quote:Original post by szecsthis posts a message to itself.Indeed :) and intended so.Quote:Original post by szecsIf nothing else posts the same message, you never get here.Indeed :) But I post it once, right before the message pump.Quote:Original post by szecsIf once something posts the message, you will get a beautiful form of infinite loop.Indeed :) and intended again. That's basically what a game loop is, isn't it ?The question is, why is no other message processed except this one ? I'm assuming the message queue is a *queue*, i.e. a FIFO. And I'm assuming PostMessage() enqueues it and do not call WndProc right away.Thus when I PostMessage() to execute this part again, I shouldn't prevent any message posted before (e.g. during the sleep()) to execute first.Is that assumption correct ?Is there something else preventing WM_CHAR messages here from being queued at all ?;  How does you windproc look like? The whole stuff.Remember, handled messages should return zero, unhandled messages DefWindowProc;Quote:Original post by szecsHow does you windproc look like? The whole stuff.Remember, handled messages should return zero, unhandled messages DefWindowProcYup, well those cases are handled...I was typing the code directly on the forum to get rid of a lot of less-useful stuff, but here is a strict copy/paste :// The WndProc for the Window that we eventually open upLRESULT CALLBACK WndProc( HWND hwnd, UINT message, WPARAM wparam, LPARAM lparam ){    switch( message )    {   case WM_CREATE:  cout << "WINDOW SPEAKING TO YOU THROUGH THE CONSOLE." << endl;  return 0;  break;   case WM_PAINT:  // paint event  cout << "PAINT EVENT!" << endl;  // Test : Repaint will be managed by DefWindowProc.  break;   case WM_LBUTTONDOWN:    // left clicking on the client area of the window (white part)  cout << "Left Mouse Button DOWN at x=" << LOWORD(lparam) << " y=" << HIWORD(lparam) << endl;  return 0;  break;   case WM_NCLBUTTONDOWN:  // NONCLIENT area leftbutton down (click on "title bar" or edges parts of window)  cout << "Left Mouse Button DOWN on Non-client area." << endl;  // Do not return, let DefWindowProc() manage this.  break;case WM_KEYDOWN:// Key presscase WM_SYSKEYDOWN:// Alt+Key presscase WM_KEYUP:// Key releasecase WM_SYSKEYUP:// Alt+Key release    cout << "Key : " << getDbgVirtualKeyFromParam(wparam);    {unsigned short nRepeatCount =(unsigned short)lparam; // bits 0 to 15unsigned short nScanCode =(unsigned short)((lparam & 0x00FF0000) >> 16); // bits 16 to 23bool bExtendedKey =(0 != (lparam & 0x01000000)); // bit 24bool bAltKeyDown =(0 != (lparam & 0x20000000)); // bit 29bool bKeyPreviouslyDown =(0 != (lparam & 0x40000000)); // bit 30bool bKeyBeingReleased =(0 != (lparam & 0x80000000)); // bit 31cout << " Repeat=" << nRepeatCount << " ScanCode=" << nScanCode <<" Ext?" << bExtendedKey << " Alt?" << bAltKeyDown <<    " Prv?" << bKeyPreviouslyDown << " Rel?" << bKeyBeingReleased << endl;    }  return 0;    break;   case WM_CHAR: // character key   case WM_SYSCHAR:   // system character key (same, with Alt pressed)    cout << "Char : " << getDbgCharFromParam(wparam);    {unsigned short nRepeatCount =(unsigned short)lparam; // bits 0 to 15unsigned short nScanCode =(unsigned short)((lparam & 0x00FF0000) >> 16); // bits 16 to 23bool bExtendedKey =(0 != (lparam & 0x01000000)); // bit 24bool bAltKeyDown =(0 != (lparam & 0x20000000)); // bit 29bool bKeyPreviouslyDown =(0 != (lparam & 0x40000000)); // bit 30bool bKeyBeingReleased =(0 != (lparam & 0x80000000)); // bit 31cout << " Repeat=" << nRepeatCount << " ScanCode=" << nScanCode <<" Ext?" << bExtendedKey << " Alt?" << bAltKeyDown <<    " Prv?" << bKeyPreviouslyDown << " Rel?" << bKeyBeingReleased << endl;    }  return 0;  break;case WM_MOVE:   // moving the window  cout << "Window moved to x=" << LOWORD(lparam) << " y=" << HIWORD(lparam) << endl;  return 0;  break;   case WM_SIZE:  cout << "Window resized to width=" << LOWORD(lparam) << " height=" << HIWORD(lparam) << endl;  return 0;  break;   case WM_DOSTUFF:    // Time to work...  doStuff();  PostMessage(hwnd, WM_DOSTUFF, 0, 0);  // Plan to work again...  return 0;  // (Tried without, doesn't work either)  break;   case WM_DESTROY:    // killing the window    cout << "Window destroyed !" << endl;  PostQuitMessage( 0 );  return 0;  break;    }    // Let the default behaviours happening when we do not return before.    return DefWindowProc( hwnd, message, wparam, lparam );};  can you check, if the app gets other messages? Not just WM_CHAR, but any others.EDIT: posted before refreshing. you don't always return with zero. Always return with zero. BTW the break after the zero is pretty much useless...Do you get WM_KEYDOWN?   ;Quote:Original post by szecscan you check, if the app gets other messages? Not just WM_CHAR, but any others.No message at all (and the window is unmovable, meaning even the default window-handling messages are not sent).Quote:Original post by szecsyou don't always return with zero. Always return with zero.OkayQuote:Original post by szecsBTW the break after the zero is pretty much useless...Yeah well I know, I left those just in case I need to comment a return during my tests and not worry about putting the break back.Quote:Original post by szecsDo you get WM_KEYDOWN?No, ofc not ^^, my console display is really only a stream of "Doing stuff..." / "done.";  Then my guess is that PostMessage places the message in the beginning of the QUEUE.So you can't use the stuff this way.Go with the "normal way": it's more intuitive, more readable. I see no point in your solution at all.EDITED.   