Auto start up app on soft reset

  • Thread starter Thread starter Kath
  • Start date Start date
K

Kath

Hi,

I am writing an application for the XDA II (PPC 2003), and I'd like my
application to automatically start up when the device soft resets.
I've tried this in a couple of ways, but haven't yet got a solution.

I can achieve it by putting a shortcut in the Windows/StartUp folder,
but this isn't enough because 1) it doesn't give the user a chance to
enter a PIN to activate the phone, which is needed because my app uses
GPRS, and 2) the user can still access other programs when the app
closes.

I've read about using the "/init" in the registry, and tried adding a
launch value, but this didn't make my app run on soft reset. I'm using
the opennetcf registry component to set the registry:

myRegLaunch = OpenNETCF.Win32.Registry.LocalMachine.CreateSubKey("\init")
myRegLaunch.SetValue("Launch150","\Program_Files\Testing\Final38.exe")

I set the launch 'number' to 150, as the highest current number is
149, and I think I need it after the connmgr (which is 70) because my
app uses GPRS. I have read that in PPC 2003 you have to launch your
app after shell32, which is launch50, so that should be ok.

I'm obviously missing something, but I'm not sure what. It may be
because I haven't added a Depend value for my app, which I haven't
done because I can't see how to work out the correct hex value. I
can't find any information on how or what to set the value to (i.e. so
it depends on the other launches). Does anyone know how to work out
and set these hex values?

Also, am I correct in thinking I don't need to use the SignalStarted
API in my app, because it has no dependencies?

Assuming I can get this to work, so my app starts automatically on
soft reset (and it is full screen, so the user can't access the Start
menu), is it the norm to keep the app running indefinately? If I let
it be closed, then this would reveal the Start menu etc.

Lots of questions, I know! Any help/ideas would be greatly
appreciated!

Thanks,
Kath
 
Yeah, the Depend statement had me thinking for a minute too.
Basically, you should first be very sure that the path to your program
is quite correct. Having an improper path will not generate an error
message (from what I've seen). Also, to ensure that your program is
the last thing to start up, you may need to use the depend statement;
my implementation often failed to work without it.

The depend statement works like this: If you want to start your
program only after another program in the init key has finished
loading, you check its launch code. For example, if something is set
to be Launch50, and your program is Launch60 (and, for the love of
God, don't depend on a program later in the startup queue), your init
key will look something like this:

Launch50 = Shell32.exe
Launch60 = YourAwesomeApp.exe
Depend60 = 32 00

Why? Because 32(hex) equals 50(dec). (3 * 16 + 2 * 1 = 50)

The 00 following it seems to be a delimiter. So if you want to have,
say, dependancies on, say, more than one thing in the queue:

Launch50 = Shell32.exe
Launch70 = connmgr.exe
Launch80 = YourAwesomeApp.exe
Depend80 = 32 00 46 00

That will depend on both of them. Most Launch items should have an
attributed Depend item, so you'll probably be safe by sticking your
program at the end of the queue and depending on the thing right
before it. Assuming, of course, the path to your application is
correct.

If getting rid of the start-menu is your goal, you might want to check
out P/Invoking the FindWindow and ShowWindow API from the coredll. Use
Remote Spy++ to check out pertinant window informations.

Starting the application as late as possible may reveal the start menu
for a crucial few seconds, but I have not, as yet, found a way around
this for Windows Mobile 2003 and .NET CF SP2. Experimenting with
TopMost Window functionality also P/Invoked from coredll may make this
a moot point for you.

Lastly, hiding the start bar in this fashion will prevent the start
bar from reappearing if your program closes or crashes. If you stick
your program into the startup queue like this, it'll hide the start
bar again. For a development environment, this is not exactly optimal.
Be sure to put the start bar-hiding functionality and the auto-startup
functionality into two different spots of your development time-line
and test both of them separately until your ready to finish your
product.

Also, from what I've read, hiding the start bar in this fashion and
removing the ability to exit from your app makes your application
ineligable for the "Certified for Microsoft Windows Mobile Sticker",
if you care. There's a set of guidelines on what your program can and
can't do to be eligible for this sticker (and it's rather long).

Hope some of this helps. : )
Tristan
 
Thanks for your help Tristan, that cleared it up for me! It's now
working fine.

I'm now using the SHFullScreen API to hide the Start Menu, but it only
works for the form I call it from (which makes sense, as it uses that
form's handle in the API call).

Is there a way to disable to StartMenu on the PDA, no matter which
apps are running? I ask because my app starts up automatically, then
gets covered immediately by the PDA asking for a PIN for the phone
(it's an XDA2, a PDA phone), which the user enters and this takes them
back to my app, which is in the background. This works fine, but when
the PDA asks for the PIN for the phone, the start menu is available.
Is there a way to disable this?
(I don't want to take out the PIN request).

I've seen some code using EnableWindow and EnumChildWindows, could
this be of use?

Thanks!

Kath
 
Again, check out the FindWindow and ShowWindow functionality. They are
two functions p/invoked from Coredll. FindWindow takes two parameters:
the class name and caption of any given window in the entire system.
Using a tool that is provided by eMbedded C++ software called "Remote
Spy++" will allow you to connect to an emulator or device and see both
the class and caption names of all windows on the system (including
child windows such as buttons and textboxes).
Once you find the window and get the handle back, use the
ShowWindow function with the param set to SW_HIDE, which is defined
somewhere in the C header files. It also has to be somewhere on this
forum (this is a pretty common question). Anyway, that'll hide the
start menu until it's explicitly called back. Even if your program
were to crash, the start bar would still be hidden away. The only
thing that would bring it back (besides a subsequent call to
ShowWindow()) is a soft-reset, which your program now handles.

Best of all, this solution applies to forms outside of the main
form, so you don't have to call SHFullScreen more than once.

Good luck,
Tristan
 
To clarify - I want to disable just the StartMenu without disabling
the rest of the taskbar - is this possible? Is the Startmenu a control
on the taskbar?

The code I found to get the handle for the Startmenu is from another
NG and is not for the CF, so I think the CF may not work in this way
(i.e. able to get the handle for just the Startmenu).
http://groups.google.com/groups?q=p...UTF-8&selm=uj5F8Y9S$GA.259@cppssbbsa04&rnum=1

This would allow users to open the phone using the green hardware
button and then close (minimise) it using the x in the top corner of
the taskbar, whilst not allow them access to the start menu.

Alternatively, I suppose I will have to look at using the hardware
buttons to close the phone (somehow?!) or 'open' (bring to front) my
app, although I'm less keen on doing this.

Thanks, Kath
 
Back
Top