How to quit an application properly?

I've just noticed an odd behaviour on my app...

As part of my "I want to quit" method I simply close the view of my main
Shell:

  self view close.

and this seems to work.  However I came accross an instance yesterday
when doing some testing at a client site where the process wasn't
terminating after closing the view from a certain part of the code:

  sendMessage
    [model sendMessage.
    model closeOnSend ifTrue: [self cancel] ifFalse: [self clearMessage]]
      on: Error do: ["display error messages etc. etc."]


the "cancel" method is the one that closing the view.

I tried adding the following to cancel to no avail either:

  (SessionManager current isKindOf: TXTMailSessionManager)
        ifTrue: [SessionManager current quit: 0]

The strange thing thou, when cancel is valled from:

  processContentKeyPress: aKeyEvent
    aKeyEvent wParam = 27 ifTrue: [self cancel]

the application will close and terminate as expected.

The sendMessage code invokes the Microsoft Outlook ActiveX objects for
sending messages, and the only difference in the two environments
involved having Outlook connected to Exchange, or via SMTP.  ( Exchange
left the dangling process ).

Is there a proper/better way to enforce my application/process to terminate?

Mark Derricutt wrote:

>   self view close.
>
> and this seems to work.  However I came accross an instance yesterday
> when doing some testing at a client site where the process wasn't
> terminating after closing the view

I'm not sure how relevant the following wil be.  Your problem sounds rather
like the one that many people have had at some time or other, but there may be
something special going on too.  Anyway, FWIW...

Closing Dolphin apps is something of a black art.  Dolphin (effectively) has
code to detect when all the windows are closed and automatically exits in that
situation.  That sounds good, but it's actually a problem in that it /nearly
always/ works fine, but sometimes fails.  It's only when you notice it failing
that you realise that you are "supposed" to exit explicitly and modify the
automatic feature to make it work in whatever way your app needs.   (And no,
this isn't documented anywhere properly AFAIK)

This has caught all the regulars out at one time or another, and so there's
quite a lot of discussion of the matter in the archives.  I'd post a Google
link, but they have successfully made it infeasible to post links to newsgroup
threads, so I suggest that you check comp.lang.smalltalk.dolphin for posts in
the last couple of years that include both 'exit' and 'quit'.

Is your app a standalone GUI .exe ?  If not then please ignore the following.
Console applications are (or should be) simpler, and I have no idea what
happens with an embedded ActiveX component.

I have only ever deployed standalone Dolphin apps, bit in such apps, you can
call

    SessionManager current exit: 0

to /ask/ the session to initiate shutdown (which ultimately will call #quit,
but safely).  Also, Dolphin will quit[*] automatically from
SessionManager>>keepAlive when there are no more windows open.  #keepAlive is a
confusing choice of name, it would be better called something like
#quitIfNotActive.  It is called (IIRC) whenever the application has gone idle,
to see if it should now shutdown.

([*] it calls #quit rather than #exit -- I don't know why, it looks iffy to me,
but it does work.)

FWIW, the pattern I use is to:

-   Call SessionManager>>exit: when I want to exit explicitly.
-   Override SessionManager>>exit: with a version sets a "finished" flag and
        then calls super.
-   Override #keepAlive with a version that checks the flag as well as
        duplicates the super logic (refactored but essentially the same).
-   Add some messing around to allow me to popup dialogs and/or exit early from
        main.

But as I said, that only applies to "normal" GUI apps.

    -- chris

Mark,
"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
[...] Chris' advice applies with respect to Outlook Addins, but with some
additional complications.  I'm sure you'll be shocked to learn that Outlook
has some issues with shutting down add-ins properly, and those issues vary
by Outlook version.

Outlook 2003 (to date, at least) doesn't bother to invoke #OnBeginShutdown:,
so you have to monitor Outlook's Explorers collection, and invoke it
yourself when the last one closes; it's not difficult, it's just stupid.

Outlook 2002 (XP) works fine with an explicit SessionManager>>exit in the
#OnBeginShutdown: method.

Outlook 2000 just doesn't seem to shut down properly at all, although it
used to most of the time.  Monitoring the Explorers collection a la OL2003
allows you to shut down your app, but leaves an Outlook process running.
Consequently, when the user restarts the OL UI, it looks like your app
hasn't loaded.  I suppose you could just hide the tray icon when the last
Explorer is closed and unhide it when one reopens, but good grief...  It's
been a couple of years since I've had to use OL2000, but potential customers
still have the dumb thing, unfortunately.

There are third-party utilities to monitor Outlook and kill it when they
deem it appropriate, but that seems a bit heavy handed for me, not to
mention an additional burden and disincentive for potential users/customers
who'd have to install a utility they didn't need until they got your app.
Just to complicate things further, there are times when you're not supposed
to start add-ins (e.g., when some other app starts Outlook as a service).

I revisit this topic periodically (or, actually, aperiodically ;^) in the
so-far vain hope that MS will have resolved the issue.  Hope springs
eternal, I guess.  Anyway, aren't Outlook add-ins fun?

HTH,

Don

>
>
>
>