Re: CF Service Packs impacting registry auto start functionality?

From: Paul G. Tobey [eMVP] (ptobey_no_spam_at_instrument_no_spam.com)
Date: 04/27/04 

Date: Tue, 27 Apr 2004 16:11:51 -0700

At a guess, what is probably going on is that something in the startup code
for SP2 is counting on an OS capability being up-and-running, but, at the
time when you are being launched, it's not yet there. As to what that
capability (or API), that might be, I have no idea. If it were me, I'd
adjust the list of dependencies in the Init keys to load your program as
late during startup as possible, in hopes that the API will be ready by
then. Are you absolutely sure that *none* of the parts of your program that
you wrote is being executed? If your main routine is being run, you could
P/Invoke the IsAPIReady() call to wait for the right thing to be running,
assuming we can figure out what that right thing is...

Paul T.

"Tristan Leonard" <trisco2001@hotmail.com> wrote in message
news:5f7bc8aa.0404271449.3722025c@posting.google.com...
> This is a question I posed to Jon Box, someone some of you might
> recognize. He then suggested I post my question on this group (which
> he refers to as "The Newsgroup") which I had been previously unaware
> of!
>
> My problem, in a nutshell, is this: After installing CF SP2 to fix one
> problem another problem has arisen that I cannot effeciently get
> around.
>
> To go slightly further, the new problem is about the registry loosing
> the ability to auto-start my application upon soft reset in order to
> keep the user from interacting with the operating system normally.
>
> Now, to go beyond the nutshell, I am trying to develop a Kiosk Mode
> system for mobile applications and part of its functionality was to
> add a path to itself in the registry (specifically, the Init key
> within HKEY_LOCAL_MACHINE) so that it would start automatically upon a
> soft reset. Under Service Pack 1 of the Compact Framework, this method
> worked wonderfully; the application would start itself even before the
> Start Menu and the 'desktop' (i.e. the Today Screen) was shown. But
> there was a problem: the button control did not support KeyDown,
> KeyPress or KeyUp events which another class of mine that handles key
> configuration used to handle input from the device's hardware buttons.
> Thankfully, this issue was solved in the Compact Framework's Service
> Pack 2; now all controls carry the key events and buttons can receive
> the focus and still process events from the hardware keys such as
> Calendar or Tasks (when the messages have been intercepted using the
> Game API).
>
> But another problem cropped up afterward: now the entry into the
> registry which specifies when my software loads during startup is
> being completely ignored; our software fails to load at all. I have
> tried this on the HP iPAQ running Windows Mobile 2003 and on an
> Intermec i700 running Pocket PC 2002. I have hard reset both of them
> and noticed that, upon deployment, the program will load but input
> will cease to work once a button control has received focus but, at
> this point, the program will load on startup. Then I will install the
> SP2 patch for the Compact Framework and input will work after a button
> control has received focus but the program will not load on soft
> reset. I will then uninstall SP2 and redeploy (the original version of
> the CF will load during deployment) and the original behavior returns.
>
> I am a little curious as to why the Service Pack of the Compact
> Framework would change the behavior of something which seems to be
> operating system specific rather than software development specific. I
> am able to confirm that my edit to the registry is made in both cases;
> it appears that under SP2 the registry is simply being ignored. Has
> anyone else had this problem? Are there any other solutions besides
> HKEY_LOCAL_MACHINE\Init that could help me here? We are aware that we
> may put the application or a shortcut to it inside the
> \Windows\Startup folder but, for that to work, the shell must load
> first and that reveals the start bar to the user (if only for a
> moment) and that's a drawback we would prefer to avoid.
>
> Any information would be helpful, and I'm glad to have found this
> place. Thanks a lot.
>
> Tristan Leonard