how to window do ui job?

Started by
7 comments, last by derek7 18 years ago
I seem it use multi thread, one for get user input (mouse ,key ...) one for message loop to handle message(user input) do I guess right? if yes ,what thread or process that in charge of get user input?
Advertisement
No. One thread will be quite enough, Mr 7.
it is not quite right,
It really does not matter how windows do the explorer UI (or any windows application do).

the message loop handler can do all those things you mentioned.

there are times that you want to create another thread to handle another window processing that just need to be on diffrent thread.

a good example will be a disk search. while searching in your and the search it self happen in the context of your message loop you will block any messages arrive to your window and that will freeze your application GUI.

hope thats help,
Nuno1
Quote:Original post by Nuno1
it is not quite right,
It really does not matter how windows do the explorer UI (or any windows application do).

the message loop handler can do all those things you mentioned.

there are times that you want to create another thread to handle another window processing that just need to be on diffrent thread.

a good example will be a disk search. while searching in your and the search it self happen in the context of your message loop you will block any messages arrive to your window and that will freeze your application GUI.

hope thats help,
Nuno1




when I click a menu a wm_comand will post to queue.Does this work still be done by my message loop?

if you do a game ui ,this work will be done by you self.
Quote:Original post by derek7
when I click a menu a wm_comand will post to queue.Does this work still be done by my message loop?

if you do a game ui ,this work will be done by you self.


When you click a menu, you get a WM_COMMAND posted to your windows message queue. That message gets picked up by PeekMessage or GetMessage, and then you send it off to your window procedure with DispatchMessage. Your window procedure can then handle the message if it wishes.

If you make a game UI that doesn't use window messages, then your message loop has no effect on it at all, except you still need to process messages to detect if your window is getting any events from the OS.
Quote:Original post by Evil Steve
Quote:Original post by derek7
when I click a menu a wm_comand will post to queue.Does this work still be done by my message loop?

if you do a game ui ,this work will be done by you self.


When you click a menu, you get a WM_COMMAND posted to your windows message queue. That message gets picked up by PeekMessage or GetMessage, and then you send it off to your window procedure with DispatchMessage. Your window procedure can then handle the message if it wishes.

If you make a game UI that doesn't use window messages, then your message loop has no effect on it at all, except you still need to process messages to detect if your window is getting any events from the OS.


I mean when I click a menu a wm_comand will "post" to queue. Who "post"? I guess windows do it or another thread do it.

int gameloop(){	MSG msg;	::ZeroMemory(&msg, sizeof(MSG));		while(msg.message != WM_QUIT)	{		// message part		if(::PeekMessage(&msg, 0, 0, 0, PM_REMOVE))		{			::TranslateMessage(&msg);			::DispatchMessage(&msg);		}		// game part		else		{						messenger.render();			static float lastTime = (float)timeGetTime(); 			float		currTime  = (float)timeGetTime();			lastTime = currTime;			float timeDelta = (currTime - lastTime) * 0.001f;			if (timeDelta > 0.01f)			{				messenger.update(timeDelta);			}			else			{				Sleep(1);			}		}	}	return msg.wParam;}int main(){	gameloop();}

another quesion:

the window not be created. the peekmessage sometime return 0 ,sometime return !0,
why? I think peekmessage will not get any message.


The key to implimenting a successfull piece of code is to have you're design carfully organized.

There are three points to implimenting a windows pump procedure.

// 1. Windows Procedure - a procedure attached to every window created// 2. A pump mechanism - used to process windows messages// 3. The procedure which initializes the window and runs the pump// #1 - generic Windows ProcedureLRESULT CALLBACK WndProc(	HWND	hWnd,			// Handle For This Window				UINT	uMsg,			// Message For This Window				WPARAM	wParam,			// Additional Message Information				LPARAM	lParam)			// Additional Message Information{	switch (uMsg)									// Check For Windows Messages	{		case WM_ACTIVATE:							// Watch For Window Activate Message		{			if (!HIWORD(wParam))					// Check Minimization State			{				//active=TRUE;						// Program Is Active			}			else			{				//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:								// KILL ZA WINDOW BIZATCHI			PostQuitMessage(0);	}	// Pass All Unhandled Messages To DefWindowProc	return DefWindowProc(hWnd,uMsg,wParam,lParam);};// # 2 - pump procedure (generic, only inquiring to see if WM_QUIT is one of the messagesbool window::pump(){	PeekMessage(&threadMessage,NULL,0,0,PM_REMOVE);	TranslateMessage(&threadMessage); // Translate The Message//****************************************************************//////	a custom switch case message handler can be used here to take //  care of the fact in which the WINDPROC is EXTERNAL and with out//  class context////****************************************************************//	if (threadMessage.message == WM_QUIT) return false;	DispatchMessage(&threadMessage);	return true;};// # 3 - The code implimenting the Pump, and assigning it to a windowmain(){...	WindowRect.bottom=(long)display.dmPelsHeight;	// Set Bottom Value To Requested Height		windowClass.style			= CS_HREDRAW | CS_VREDRAW | CS_OWNDC;	// Redraw On Size, And Own DC For Window.	windowClass.lpfnWndProc	= (WNDPROC) WndProc;					// WndProc Handles Messages	windowClass.cbClsExtra		= 0;									// No Extra Window Data...        RegisterClass(&windowClass);									// Attempt To Register The Window Class		AdjustWindowRectEx(&WindowRect, dwStyle, FALSE, dwExStyle);		// Adjust Window To True Requested Size			windowHandle=CreateWindowEx(	dwExStyle,					"OSL",					"undefined",					WS_CLIPSIBLINGS | WS_CLIPCHILDREN | dwStyle,					WindowRect.left, 					WindowRect.top,					WindowRect.right,			    	        WindowRect.bottom,					NULL,					NULL,					GetModuleHandle(NULL),					NULL);		...   while (pump())   {       gamecode();   }};


You only need one thread, Windows already takes care of handeling the different messages, all you have to do is process them by creating a "pump" mechanism, much like the pump function, after you "pump" the message out of the que, you can handle it in WndProc or you're own handler, like what I have in comments in my Pump function.

If you want to process mouse and keyboard input, try DirectX or look at MSN's site for the platform SDK (it has all the different WM_xxx / windows messages that apply to the mouse and keyboard, but I use DirectX Input right now for keyboard and mouse.

By the way, do you speak a foreign language?


[Edited by - pcxmac on April 17, 2006 2:04:51 AM]
sig
Quote:Original post by pcxmac


By the way, do you speak a foreign language?


yes I am chinese, sorry for unfamiliar English :) I am always improving it.

This topic is closed to new replies.

Advertisement