SystemState StateChanged Subscription Must Occur on UI Thread?
jonfroehlich
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
<ctacke/>
(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).
--
Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com
"jonfroehlich" <jonfro...@gmail.com> wrote in message
news:1193422785.9...@v29g2000prd.googlegroups.com...
jonfroehlich
As always you provide super valuable feedback to the community. I
appreciate it.
Jon
On Oct 26, 1:06 pm, "<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote:
> 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).
>
> --
>
> Chris Tacke, eMVP
> Join the Embedded Developer Communityhttp://community.opennetcf.com
>
> "jonfroehlich" <jonfroehl...@gmail.com> wrote in message
>
> news:1193422785.9...@v29g2000prd.googlegroups.com...
>
> > 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.stat...