🔒 Locked

Modal loop problems

Started by ProgrammerZ Jun 28, 2010 at 8:08 PM 5 replies 1.8k views

Original Post

Jun 28, 2010 at 8:08 PM

I recently modified some code in my Win32 engine to implement the handling of modal loops (specifically, so my apps can render while the window is being dragged). I added these lines to my WinProc function:

switch (message){	// snipped	case WM_ENTERSIZEMOVE:	case WM_ENTERMENULOOP:		{			ModalLoop = true; // entering a modal loop			SetTimer(hWnd, 0, (1000/60), NULL);		} break;	case WM_EXITSIZEMOVE:	case WM_EXITMENULOOP:	case WM_CAPTURECHANGED:		{			ModalLoop = false; // exiting a modal loop			KillTimer(hWnd, 0);		} break;	case WM_TIMER:		{			if (m_bInModalLoop)			{				RenderStuff();			}		} break;}

However, I've noticed a couple of problems with this code.

The first problem is something that no one would probably notice during any kind of normal gameplay, but it bugs me anyway. When I click on the icon on the upper left hand corner of my window's title bar, the system menu (or Windows menu, or whatever) pops up. I can click on any of the items in this menu just fine, but if I press the Esc key to dismiss the menu, my program gets stuck in a modal loop and doesn't exit until I click on the window or otherwise give it focus. To add to the confusion, this bug does not occur if I right-click on the window's title bar, then press Esc. I'm guessing there are probably some messages somewhere that I should be processing.

The second problem I noticed is mainly just an aesthetic thing, but it makes me think I might be doing something wrong somewhere. I've noticed that if I bring up one of the aforementioned menus and my menu animation behavior is set to "fade," then the menu tends to flicker as it fades in. This problem is intermittent, and seems dependent on how many CPU cycles my program is taking up.

I guess I probably should be asking these questions in separate threads, but I guess they're somewhat related, and I just typed this all up anyway. :)

Any help would be much appreciated.
-- ProgrammerZ

iMalc

Jun 29, 2010 at 12:57 AM

That code snippet suggests that you're doing some drawing outside of a WM_PAINT handler.
You should be doing all drawing between BeginPaint and EndPaint in a WM_PAINT handler.
If you need to be drawing repeatedly, then have your message loop call UpdateWindow frequently. I'm not at my own PC right now so I can't post a code sample. However it might also be useful for you to post more of your code.

jwezorek

Jun 29, 2010 at 11:25 AM

What iMalc said.

I'm confused about how your application is rendering when it isn't in a modal loop. Are you just grabbing a device context and drawing to it in your main message loop? -- because that's going to have all sorts of problems.

ProgrammerZ

Jun 30, 2010 at 5:20 PM

Hey guys, thanks for the replies.

jwezorek, I'm not sure what you mean by a "device context," but this is essentially my main message loop code:

while (1){    while (PeekMessage(&msg, 0, 0, 0, PM_REMOVE))    {        TranslateMessage(&msg);        DispatchMessage(&msg);    }    Update();    RenderStuff();}

This code works fine; it's the code in my original post that seems to have problems.

iMalc, I originally tried putting my modal loop rendering code in a WM_PAINT handler, instead of the WM_TIMER handler that it's in now. But, I found that if I had another window partially in front of mine, and then I clicked on my window's title bar, bringing it to the front, its client area wouldn't redraw until I released the mouse button. Perhaps should I be calling InvalidateRect when I receive a WM_SETFOCUS message or something?

ProgrammerZ

Jul 3, 2010 at 9:08 PM

Anyone? I hate to bump this, but I can't imagine there isn't anyone here who knows how this stuff is commonly done... Evil Steve maybe?

jwezorek

Jul 4, 2010 at 12:50 AM

Are you talking about a DirectX rendering or regular Win32 painting?

Shinkage

Jul 4, 2010 at 9:45 AM

Quote:
Original post by ProgrammerZ
I can click on any of the items in this menu just fine, but if I press the Esc key to dismiss the menu, my program gets stuck in a modal loop and doesn't exit until I click on the window or otherwise give it focus. To add to the confusion, this bug does not occur if I right-click on the window's title bar, then press Esc. I'm guessing there are probably some messages somewhere that I should be processing.

Hitting escape once doesn't do what you seem to think it does. To illustrate, get the system menu to drop down and hit escape, but then hit the down arrow key on your keyboard right after hitting escape. The result might surprise you. Then do the same thing, but instead of hitting escape once, hit it twice, and you'll get the result you want.

Quote:
Original post by ProgrammerZ
The second problem I noticed is mainly just an aesthetic thing, but it makes me think I might be doing something wrong somewhere. I've noticed that if I bring up one of the aforementioned menus and my menu animation behavior is set to "fade," then the menu tends to flicker as it fades in. This problem is intermittent, and seems dependent on how many CPU cycles my program is taking up.

I don't think there's really anything you can do about this. It's just an artifact of how Windows draws the menu fade interacting with an app drawing in a continuous loop, rather than in the WM_PAINT handler where Windows expects it. It's really just something you'll have to live with as far as I'm aware, but really, how often do you expect users to be having menus fading in over your program?

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.