Today Screen plugin focus

[ppcStudios]

I'm working on the final issue with Baseball Today before sending it through Beta testing, but at the moment I'm stumped.

Does anyone happen to know what WM_* message gets passed (if any) to a plugin when another plugin or another application gains focus? In other words, when the user is playing Baseball Today and he decides to use another plugin such as his contact list, I want to pause the game and suspend sound.

Thanks!

[ppcStudios]

I hate replying to my own message, but hopefully it will generate some ideas. On the desktop, I can look at WM_ACTIVATE to determine if the application is becoming active or inactive. I can also look at WM_SETFOCUS and WM_KILLFOCUS to do the same thing. But on the ppc (at least under PPC2000) these don't seem to have any effect.

Is there equivalent functionality under WinCE? I simply need a trigger telling me its time to enable/disable sound and gameplay.

[Kzinti]

WM_SETFOCUS and WM_KILLFOCUS are related to keyboard focus and should not be used to detect if your application is active or not.

WM_ACTIVATE is the proper message to handle. As to why it doesn't work on PPC2000 is a mystery to me. I guess Today's plug-ins are handled in a different way.

[ppcStudios]

Thanks Thierry. Set and Kill Focus were shots in the dark after WM_ACTIVATE didn't do the trick. I don't think the Today plugin framework was designed with graphics and sound in mind.

I'll probably send it off to the first round of beta testing as is and continue working on the issue. There must be some way of knowing when another application has taken over focus.

I was quite surprised to find that Today plugins continue functioning even when another application is brought to the foreground. This opens the door for many interesting projects.

[InexorableTash]

WM_ACTIVATE won't work because it is sent only to the top-level window that is activated. The Today screen itself is a top level window and your plugin is a child window of it, so you won't be notified.

So you need to put on your thinking hat. If you were writing an app with a child window, how would that child window know if the app was active or not? There are three possibilities:

1. The OS sends a message to each child window
2. The child window detects whether or not the app is active or not without relying on anyone to tell it
3. The app window sends the child window a special message

So investigate all 3.

For (1) you won't get WM_ACTIVE, but you will get told to paint (WM_PAINT) when your window becomes visible. So if you just need to detect the hidden-->visible transition, you could use this. You might want to use an even earlier message, like WM_NCPAINT or WM_ERASEBKGND

For (2) you could use a polling mechanism and come up with a mechanism to determine if the app window is on top. Since it sounds like you're animating, you have a polling mechanism already. Now you just need a way to tell what's on top, and that's just standard window management functions.

For (3) you need to consult the API specifications for Today plugins. The ones I remember are case WM_TODAYCUSTOM_CLEARCACHE and WM_TODAYCUSTOM_QUERYREFRESHCACHE. I don't think there's any message when the window goes hidden, but consult the known resources (MSDN, etc) and see what you can find. I have these URLs sitting around from when I was dorking around with a Today plugin:

http://www.microsoft.com/mobile/develop ... dayapi.asp

http://msdn.microsoft.com/msdnmag/issue ... PC/PPC.asp

http://msdn.microsoft.com/library/defau ... 122001.asp

Good luck!

[ppcStudios]

Thanks Joshua!

You came to exactly the same conclusion that I did. The Today Screen launcher DLL is the parent, and is apparently absorbing the WM_ACTIVATE messages that I presumed should be going to the individual plugins. WM_TODAYCUSTOM_CLEARCACHE and WM_TODAYCUSTOM_QUERYREFRESHCACHE don't provide any help in this case either as you've pointed out.

Last night I started looking into using WM_PAINT as my trigger to knowing when I've lost focus. As you say, WM_PAINT won't fire if the plugin doesn't have focus, so I'm using that along with my FPS timer to monitor the situation. I think this will work - certainly not the nicest way of solving this problem, but better than nothing.

I've really enjoyed working on this project. The Today Screen is an interesting sub-platform to develop for, having its own unique set of features and problems. Here's some screenshots of Baseball Today as it looks going into Beta testing:

[InexorableTash]

[ppcStudios]

It wasn't my intention to confuse anyone - I use the generic term 'focus' due to my old-school Motif/OpenLook/XWindow background.

Let me provide an update as I did solve the problem I was having. Basically, the Today Screen parent absorbs many of the notification events you would expect your child plugin to receive. There are absolutely NO notifications that your plugin has been covered by another window. The API GetForegroundWindow() ALWAYS returns an HWND different from your plugin (probably the HWND of the parent in most cases, but not verified that is the always the case), so thats not an option either. Thus far I've determined there are NO WM_ACTIVATE messages passed to the plugin (this may not be the case on Phone Edition devices or Smartphone - those have yet to be examined). So, as you can see the Today Screen world is quite a bit different from standard windows development.

You can tell when your plugin has been made visible by watching for WM_ERASEBKGND messages. You will receive one WM_ERASEBKGND message each time your plugin is made visible. However, this isn't of much use when you can't tell if your plugin has been made non-visible in the first place.

Now the solution - at least in the case of Baseball Today. I'm using a WM_TIMER event to control my framerate at 30 FPS. Everytime I get this event I expect a page flip to occur. This in turn triggers a WM_PAINT event. If I do a few page flips and don't get the associated WM_PAINT events I know my plugin has been covered up.

This has been a frustrating problem because of the lack of documentation on Today Screens and the fact that noone has ever tried getting 30+ FPS and mixed sound out of a plugin. Its nice to actually do something noone else has done before.

The results are nothing short of fantastic. The game plays very nicely on everything from an iPAQ 3635 to an ASUS A715. I'm looking forward to having it tried on a WM2003SE device with a rotated screen. I'll be porting it over to Smartphone next week (I'm sure I'll find another load of issues there!), and the Pocket PC version is going to Beta this weekend (YAY!).

I've built up a really nice Today Screen game framework using GapiDraw 3, so if anyone is looking to develop for the Today Screen I'd love to talk to you and work out an arrangement. This has by far been the most enjoyable mobile game I've worked on thus far.

[InexorableTash]

[InexorableTash]

And just to reply to myself... here's a good algorithm to use when dealing with APIs.

If something isn't working as you'd expect...

- Can you phrase what's not working as a problem?
- What assumptions are you making about the problem?
- How can you verify them?
- What is the smallest possible set of steps that reproduces the problem?

As an annecdote, my first real Windows programming task was creating a set of wrapper libraries around Win32 API functions in Java. I made all sorts of horrible assumptions about how Windows should work. (E.g. how to get child controls to update cached system colors, how to get focus to move correctly through nested dialogs, etc.) To work around these perceived problems I added all sorts of hacks and nasty code. (e.g. propagating messages through the entire control tree; writing a custom tab handler, etc.) Years later I can look back and see all of the incorrect assumptions I was making that could have been resolved by simply thinking through the problem more carefully and looking at the documentation. (e.g. don't cache these - memory is more expensive than calling APIs and the overhead of sending a message everywhere is terrible; the Windows DialogProc handles this if you just set the right flags on container controls)

"Don't let this happen to you!"

[rasana]