Sign in to follow this  
ankhd

Windows XP home and WM_LBUTTONDOWN(Fixed Gumppy user the window was in the back groun

Recommended Posts

ankhd    2304
Hi all, I have a app that works on XP Pro, but when the app is ran on XP Home the mouse input does not work, it uses the windows message pump and the WM_LBUTTONDOWN, WM_MOUSEMOVE, uit works on windows 98. Do I need to call SetCapture(hwnd) and if so where do I call this function at the start up or as I use the mouse but when I use it In the WM_MOUSEMOVE it locks up the app and there is no mouse input please help. Thank you all. Here is the Message Pump
/-----------------------------------------------------------------------------------------------
// Here is our WndProc (Window Procedure).  We'll send it messages 
// we receive and have it deal with them. 
//------------------------------------------------------------------------------------------------
LRESULT CALLBACK WndProc(HWND hwnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{

	// Pass mouse messages to the ArcBall so it can build internal matrices
       ArcBall.HandleMouseMessages( hwnd, Msg, wParam, lParam );
      Window.MenuManager.MessageHandler(Msg, wParam, lParam);

	// This checks what the message is.  Below is some of the message that windows might return.
	// There of course are HUNDREDS of potential messages.
    switch(Msg)											
    {	
		// The only message that you NEED to deal with, is the WM_DESTROY.  The rest you don't have to check for.  
									

		case WM_PAINT: // This message is sent to the WndProc when the window needs to be repainted.  
			{
				//PAINTSTRUCT ps;
				//HDC hdc = BeginPaint(hwnd, &ps);

				//TextOut(hdc,200,10,"Hello World",11);

				//EndPaint(hwnd, &ps);

			ValidateRect( hwnd, 0 );

			}break;

		 //   break;										

			case WM_DESTROY: // This message is sent when it's time to destroy the window.
			{	// Here you would handle deinitialization, freeing memory, etc.

				//
				//ReleaseCapture(); 

				Window.Release();//must call this
		

				 // Cleanup COM
				//CoUninitialize(); 

			// If you look back up top at our window loop you notice a piece of code like this:
			//	if(msg.message == WM_QUIT)
			//		break;
			// PostQuitMessage() sends the WM_QUIT message.  The parameter we pass is 
			// the exit code we want to report to the operating system.  By 
			// passing zero we're saying "Zero errors occured in the application." 
			PostQuitMessage(0);								
															
			}break;
				case WM_KEYDOWN:
			{
				int key =  (int) wParam;
	
				if(key == VK_F1)
				{
					//MessageBox(hwnd,g_PortStr,"Message Test",MB_OK);
					if(Window.MenuManager.SetMainMenu())
					{
					
					}
				}

				
								     Window.MenuManager.ScrollControls(key);
												}break;
			case WM_COMMAND: 
			{
				HWND h = (HWND)lParam;
				

			}break;//end command
			case WM_LBUTTONDOWN:
				{
					//SetCapture(hwnd);
					int x = GET_X_LPARAM(lParam); 
					int y = GET_Y_LPARAM(lParam); 
					AppMouse.LBDown = true;
					AppMouse.LBDTime = timeGetTime();

										Window.MenuManager.LeftClick(x,y);

				
				}break;
				case WM_RBUTTONDOWN:
				{
					//SetCapture(hwnd);
					int x = GET_X_LPARAM(lParam); 
					int y = GET_Y_LPARAM(lParam); 
					

					//Window.PlayerNamesDlg.DialogRighClick();
					Window.MenuManager.RighClick();

				
				}break;
				case WM_LBUTTONDBLCLK:
				{
					//MessageBox(hwnd,"jtrh","Message Test",MB_OK);
					//SetCapture(hwnd);
					int x = GET_X_LPARAM(lParam); 
					int y = GET_Y_LPARAM(lParam); 
					//Window.PlayerNamesDlg.DialogLeftDoubleClick(x,y);
					Window.MenuManager.LeftDoubleClick(x, y);

				}break;
				case WM_LBUTTONUP:
				{
					AppMouse.CheckLBDown();

					//Window.PlayerNamesDlg.DialogOnMouseUp();
					Window.MenuManager.OnMouseUp();


					//ReleaseCapture(); 
				}break;
				case WM_MOUSEWHEEL:
				{
					//fwKeys = GET_KEYSTATE_WPARAM(wParam);
					short zDelta = (short) HIWORD(wParam);//GET_WHEEL_DELTA_WPARAM(wParam);

					//MessageBox(hwnd,"","Message Test",MB_OK);
					//Window.PlayerNamesDlg.DialogMouseWheel(zDelta);
					Window.MenuManager.MouseWheel(zDelta);


				}break;
				//case WM_NCMOUSEMOVE:
				//{
				//	MessageBox(hwnd,"MOUSE MOVE ","WM_NCMOUSEMOVE",MB_OK);
				//}break;
				case WM_CAPTURECHANGED:
				{
					MessageBox(hwnd,"MOUSE CAPTURE CHANGED","WM_CAPTURECHANGED",MB_OK);
				}break;
				case WM_MOUSEMOVE:
				{
					//SetCapture(hwnd);
					int x = GET_X_LPARAM(lParam); 
					int y = GET_Y_LPARAM(lParam); 
					float ang = 0.01f;

					AppMouse.Update(wParam, lParam);

					//Window.PlayerNamesDlg.DialogOnMouseMove(x, y);
					Window.MenuManager.OnMouseMove(x,y);

										//ReleaseCapture();
				}break;
			/*case WM_SYSCOMMAND:
			{// Prevent moving/sizing and power loss in fullscreen mode
				switch( wParam )
				{
					case SC_MOVE:
					case SC_SIZE:
					case SC_MAXIMIZE:
					case SC_KEYMENU:
					case SC_MONITORPOWER:
					{	if( false == Window.FullScreen )
							return 1;
						else
							return DefWindowProc(hwnd, Msg, wParam, lParam);
						
					}break;
				}
			}break;
		*/
		// So what if we get a message that we don't explicitly handle?  This is where 
		// the default window procedure comes in.  All messages we don't handle ourselves,
		// should get sent to the DefWindowProc().  It will apply a default Windows behavior
		// to the message.  For example, lets say somebody clicks the 'X' in the upper-right
		// hand corner of the window.  We could handle that message ourselves and set a quit 
		// message to the window or we could simply let the default window procedure handle it
		// for us.
		default:
		
			return DefWindowProc(hwnd, Msg, wParam, lParam);											
	}//end message													

	// Typically if you handle a message in the WndProc, you return zero.
	return 0;  
				
}//end winproc		
///////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////




[Edited by - ankhd on August 17, 2007 12:15:14 AM]

Share this post


Link to post
Share on other sites
jpetrie    13100
You should post the code. You do not need to do anything special to handle those messages on XP (although SetCapture can be useful), but you might be doing something funky that used to work on 98 and no longer works on XP (probably because it was undocumented / wrong).

Share this post


Link to post
Share on other sites
Endurion    5407
Quote: // Typically if you handle a message in the WndProc, you return zero.

Wrong, very wrong.

1) Move the default case out of the switch/case. Return DefWindowProc for every message, even if you handle it. If you want a message not passed on read up in on it in the MSDN and return the correct value. 0 is not useful for a lot of messages.

The focus works if you pass the mouse messages on to DefWindowProc, which doesn't happen right now.

2) Call BeginPaint/EndPaint in WM_PAINT. I think ValidateRect only does a certain extent of what is needed to properly process a WM_PAINT. Also, if you did 1) you will have to return 0 to indicate that the message was properly handled (and not pass it on).

Share this post


Link to post
Share on other sites
Mike2343    1202
Quote:
Original post by Endurion
Quote: // Typically if you handle a message in the WndProc, you return zero.

Wrong, very wrong.

1) Move the default case out of the switch/case. Return DefWindowProc for every message, even if you handle it. If you want a message not passed on read up in on it in the MSDN and return the correct value. 0 is not useful for a lot of messages.

The focus works if you pass the mouse messages on to DefWindowProc, which doesn't happen right now.


Actually, according to MSDN, which I kinda trust for some silly reason... A lot of messages are expected to return 0 if you handle them. Like WM_CAPTURECHANGED for instance expects you to return 0 if you process it.

But I agree, you shouldn't have a return 0 at the end of your switch statement... return on each message handled. Otherwise you will run into bugs later as you add in more support for other messages. I've never read, nor seen anyone returning DefWindowProc for every message either. Documentation from Microsoft that says this someplace? They don't even do it in any example code I've seen.

Share this post


Link to post
Share on other sites
ankhd    2304
Hey all, I fixed the message pump to how you all said and the guy with XP home still say's the buttons and the mouse has no effect unless he move's it really fast, what would cause this or is this guys computer got a problem, like another app has the mouse focus. could this be it.
but the strange thing is it works fine on windows 98 p2 300 and with a frame rate of 3 and it works great so whats up with this.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this