"Warrick Wilson" <warrick@cwwilson.com> wrote in message
news:47448922$1@newsgroups.borland.com...
> Gambit - Outstanding! I reworked the code as you outlined,
> and it's working. Sadly, I don't know _why_ it's working.
The biggest change I made was to simply remove your manual message loop and
let TService handle its own message loop internally for you.
> When you say "Most of your code is better suited for the
> OnStart and OnStop/Shutdown events anyway", how did you know that?
Because I have created several of my own service projects and am well versed
in how TService works internally. Besides, the remaining code I left was
either startup code or shutdown code, and so didn't need to all be in one
place since TService exposes separate events for those types of operations.
> Most of what I saw with my search results basically said "you can do
> either/or".
Although OnExecute is technically available for use, I do not recommend ever
using it. Most people don't understand how to manage a service's message
queue properly, and then wonder why their services don't work correctly.
TService has its own message loop internally when OnExecute is not assigned,
and that loop is adequate for most people's needs. Any logic that a user
would normal put into OnExecute is usually better put into a separate thread
instead, that is started in the OnStart event and terminated in the
OnStop/Shutdown events.
> I have to convert a couple more applications (since we'd like our new
> system
> to run automatically without needing someone/some account signed in) AND
> some of the new apps have a UI (kiosk display sort of thing).
Do not put a UI into a service. Not only is it discouraged by Microsoft in
XP and earlier versions (though technically possible), it is actually
forbidden in Vista. If a service needs a UI, it is best to put the UI into
a separate non-service application that runs in the user's logged in account
and communicates with the service when needed. The service itself should be
background non-visual logic only.
Gambit
