   WM_CHAR messages are late
  not only WM_CHAR, all messages are coming late and the latency differs. what could cause this? here''s my code:I call this every 50 miliseconds:void GLWindow:rocessMessages(){MSGmsg;if (PeekMessage(&msg,NULL,0,0,PM_REMOVE)){if (msg.message==WM_QUIT){   Quit=TRUE;}else{TranslateMessage(&msg;DispatchMessage(&msg;}}}and here''s the message handler:LRESULT CALLBACK GLWindow::WndProc(HWNDhWnd,// Handle For This WindowUINTuMsg,// Message For This WindowWPARAMwParam,// Additional Message InformationLPARAMlParam)// Additional Message Information{GLWindow *lpThis = (GLWindow *) GetWindowLong(hWnd, GWLP_USERDATA);   //points to the actual GLWindowswitch (uMsg)// Check For Windows Messages{case WM_ACTIVATE:// Watch For Window Activate Message{if (LOWORD(wParam))// Check Minimization State{lpThis->Active=TRUE;// Program Is Active}else{lpThis->Active=FALSE;// Program Is No Longer Active}return 0;// Return To The Message Loop}case WM_SYSCOMMAND:// Intercept System Commands{switch (wParam)// Check System Calls{case SC_SCREENSAVE:// Screensaver Trying To Start?case SC_MONITORPOWER:// Monitor Trying To Enter Powersave?return 0;// Prevent From Happening}break;// Exit}case WM_CLOSE:// Did We Receive A Close Message?{PostQuitMessage(0);// Send A Quit MessagelpThis->Quit=TRUE;return 0;// Jump Back}case WM_SIZE:// Resize The OpenGL Window{lpThis->ReSizeGLScene(LOWORD(lParam), HIWORD(lParam), lpThis->ZNear, lpThis->ZFar);  // LoWord=Width, HiWord=Heightreturn 0;// Jump Back}case WM_CHAR:// Is A Key Being Held Down?{lpThis->key=wParam;// If So, Mark It As TRUEreturn 0;// Jump Back}}// Pass All Unhandled Messages To DefWindowProcreturn DefWindowProc(hWnd,uMsg,wParam,lParam);}I''m nearly sure there''s no mistake in the code it''s almost fully nehe''s... but the messages come late. what could cause this? 
  What do you mean by late.  I think we need more info.Remeber windows messages are not sent in real time. They are sent when the OS has time to send them.  And they may go to several other windows before your window gets them.Many people on this list use the WM_CHAR handler for keyboard input on their games with no problem. Well windows does have problems with keyboard input if 3 or more buttons are pressed simultaneously.  Fighting games inparticular have been plagued by this.CheersChris ;  My guess is that you''re only able to process one message every 50 milliseconds, but you''re getting many more.  Your ProcessMessages() function should loop and continue to call PeekMessage() until it returns false, or the message is WM_QUIT.  So basically, process all messages that are currently in the queue, then go on with the rest of your program.  50 milliseconds later, process all new messages that are in the queue.  As it is right now, you may be getting a new message once every 25 milliseconds, and processing one once every 50 milliseconds, and the queue keeps getting larger and larger, and you''re just not handling the messages quickly enough. ;  you could also use getasychkeystate() ( or soemthing ) to retrieve all keys, inclduing mouse buttons (VK_LMBUTON is the left i think you can guess / find the rest), whenever you need them. as long as you don''t need first person style mouse (which i believe messages don''t help with anyway) you should check the MSG stuct''s .pt member before you dispatch the message to get the mouse position. or use direct input.but mixing there ;  It seems that you''re calling GLWindow:: ProcessMessages() only once per frame, which could eb leading to this lag. Either in the function or it''s caller, you should make it a while() loop to call PeekMessage as long as there are windows messages to remove the lag. ;yes I changed the if statement to a while statement. it''s really much better now. but not as good as I want.