Page 1 of 1

Problem restoring today screen

PostPosted: Jun 13, 2002 @ 6:52pm
by jasjenl
Previous projects I have developed using gapidraw were partly based on the samples that come with the SDK and were using MFC based classes to create the main application window. In an attempt to make things somehow cleaner in my latest project I decided to ditch the mfc classes like CMainFrame and such and create my own window manually using plain CreateWindowEx. However, now when my application exits, the right lower part of the today screen isn't properly restored. You have to manually click on the button that is on the right of the lower bar of the today screen to have it redrawn correctly again. So I guess I'm doing something wrong when exiting my app, but I'm not sure what. What I'm doing when exiting the app is this:
first, delete the CGapiDisplay object
then, call SHFullScreen(m_hWndMain , SHFS_SHOWSTARTICON |SHFS_SHOWTASKBAR | SHFS_SHOWSIPBUTTON);
then, call DestroyWindow (m_hWndMain)

So, what am I missing here?

PostPosted: Jun 13, 2002 @ 7:38pm
by Ionitor
What exactly do you have on your Today screen, and what isn't being redrawn? Are you talking about the command bar across the bottom, or is it some Today plug-in, or are you using one of the Today replacements? I often have trouble with the Today bar redisplaying itself correctly, even when exiting from non-GAPI apps. I think that a lot of plug-ins have redrawing issues.
One option would be to, before exiting your app, find the current window and force it to redraw by sending a WM_PAINT message targeted at the entire surface--it's possible that the system isn't doing that for some reason.

-Ionitor

PostPosted: Jun 13, 2002 @ 7:56pm
by jasjenl

PostPosted: Jun 13, 2002 @ 8:18pm
by Ionitor

PostPosted: Jun 13, 2002 @ 8:35pm
by Hosed

PostPosted: Jun 13, 2002 @ 9:29pm
by Ionitor
Hosed,

I realize that your code snippet is editted to make your point clear, but I thought I would point out to others that might use it as a sample that PeekMessage should generally be put in an inner loop to make sure that all messages are processed. That way, especially if your frame rate is particularly low, you'll process multiple button/stylus presses that occur during a single frame.

Also, your idea makes sense and brings up a good point--you should always ensure that no additional game code is run after a window is destroyed.

-Ionitor