Re: User interface and services.exe

Today screen applets can do just about anything. Some display their entire
interface right on the Today screen. Others fork off another process when
you tap on them. I would think that it would be possible to, instead of
firing another application in response to a click, just display a dialog,
but I don't do much with Windows Mobile, so I can't tell you that for sure.

Were it me, I'd be *really* sure that this is actually going to be a problem
before building my entire structure around the assumption that devices will
constantly be running into the 32 process limit (I'm a fairly sophisticated
user of my WM phone and I've *never* hit it, not once). It would seem to me
that an enterprise device is very tightly controlled with respect to what's
installed upon it, so you should know in advance exactly how many free
process slots there should be and, if there's at least one available, you're
set. Ignoring the limit is far and away the easiest and most-maintainable
method of doing things.

Paul T.

"atomic928" <csmith1a@xxxxxxxxxxxxxx> wrote in message
news:204b759b-003a-49c8-beb9-4cb2d5d1b882@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Great stuff thank you.
To explain this app a little more. This app is deployed by Enterprises
to devices they own/control, so the enterprise requirement is that
this app is deemed manditory on each device. The current user does not
have the option of turning this app off. Also this app will have
mostly an menu type interface with several screens for the user to
enter information or respond to yes/no dialogs. So with this in mind
what architectural approach would you suggest? You mentioned a Today
screen applet, would this still allow for some user interaction and
dialog screens?
Cheers

On Apr 22, 8:31 am, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
Yes, services.exe is a process that should probably always be running,
however, it was not designed to host user interfaces. You need, in my
opinion, to address the situation where there actually *are* 33 processes
and not try to sneak in the back door by co-opting services.exe. It's
probably not as big a problem as you seem to be fearing.

I suppose that you might make your code into a Today screen applet. That
would be loaded by the shell and has some form of a user interface.
Without
knowing the requirements on your application, that's about as far as we
can
go. You could also make your application start early in the boot process,
using Init keys in the registry. Usually, it's just better to let the user
deal with the case of having too many processes running. He knows what's
important to him and, if your program happens not to be important, that
should be his choice to stop running it.

Paul T.

"atomic928" <csmit...@xxxxxxxxxxxxxx> wrote in message

news:f74629c1-6e3e-4ff1-a3b1-b8f614623ce6@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Apr 21, 12:01 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:





It might be physically possible by launching a new thread for a message
loop, etc., but you definitely *shouldn't* do it, even if it's
theoretically
possible. Are you saying that you want the configuration program or
whatever for the service to be part of the service DLL itself? That's
definitely not the way it's intended to work; write a separate Control
Panel
applet or configuration application. Or are you saying that you want to
have a program that acts as a background service and has some UI? If
that's
it, you should consider not doing this as a service, but just as an
application.

Paul T.

"atomic928" <csmit...@xxxxxxxxxxxxxx> wrote in message

news:d1b6c962-d3f4-4a65-b9c5-55d4b8cf4942@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Is there any reason I can not run a GUI from my dll that I load into
services.exe. I do not really want a client/server architecture, I am
trying to keep this as simple as possible with one app/dll for the
whole project.
Thanks for any help- Hide quoted text -

- Show quoted text -

This project is ultimately for windows mobile 5 devices and as you
know wm devices are limited to 32 processes. I want to make sure I am
loaded and not bumped out of the startup if I am process 33. My
understanding is that services.exe is a process that will run the dll
as a thread thusly assuring loading of the dll. Now if I run the app
as a separate or stand alone client I am back to the '33' process
dilemma. Or is there some architecture procedure I am missing that I
can assure that I am started as one of the 32 processes?

Thanks- Hide quoted text -

- Show quoted text -


.