Sign in to follow this  
derek7

how to window do ui job?

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites


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.


Share this post


Link to post
Share on other sites
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 Procedure

LRESULT 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 messages

bool 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 window

main()
{

...

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]

Share this post


Link to post
Share on other sites
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.

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