SystemState StateChanged Subscription Must Occur on UI Thread?

[jonfroehlich]

The Microsoft.WindowsMobile.Status.SystemState class offers a great
way to track a number of interesting and useful device system states
(e.g., incoming phone calls, battery strength, etc.). However,
recently I observed that the SystemState.Changed += new
ChangeEventHandler(OnSystemStateChanged) subscription must be made
from the UI thread. Has anyone else run into this? I attempted to
write a console app that uses many of these system state
notifications; however, none of the events were actually occurring.
Once I switched to a form-based application, everything worked great.

Is this documented somehwere? If so, I couldn't find it. I am
programming in .NET CF 2 for Windows Mobile 5.0 devices.

http://msdn2.microsoft.com/en-us/library/microsoft.windowsmobile.status.systemstate_members.aspx

 

[Guest]

Most of those events come from windows messages being posted at a low level
(FileSystemWatcher works int he same way too). If you never call
Application.Run, no message pump is ever created, so no windows messages are
ever dispatched.

I don't think I've ever seen it documented, but if you walk through the
aygshell source code in Platform Builder (which a lot of these come from
eventually), you'll see that's how they work. I agree that it's a poor
choice, but it's how it was implemented. The workaround is a very long,
tedious process (again, we've done it for file system notifications) of
reimplementing the entire listening system, creating a hidden window for
your app or implementing a Run() that doesn't take a Form (like we did in
the SDF).

 

[jonfroehlich]

Thanks Chris,

As always you provide super valuable feedback to the community. I
appreciate it.

Jon