D5.1 exe shutdown problem; patch URLs

Blair,

I'm taking another run at changing to 5.1, and hit a snag with a deployed
app not shutting down.  It has one shell which appears to close properly,
but then #keepAlive is never called.  Despite running on 2k, I thought I'd
try patches 1249 and 1272, but can't get them.  Are they deliberately not
available, or simply victims of permission problems on the new server?  The
URLs I found for them are:

http://www.object-arts.com/Lib/Update/Dolphin/5.1/1272.st
http://www.object-arts.com/Lib/Update/Dolphin/5.1/1249.st

The image is at PL1.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
> I'm taking another run at changing to 5.1, and hit a snag with a deployed
> app not shutting down.  It has one shell which appears to close properly,
> but then #keepAlive is never called.  Despite running on 2k, I thought I'd
...

I am afraid I can only offer anecdotal experience, but I ran into a similar
problem with my application.  I think I first ran into it a few versions or
patches ago, but also believe I experienced it in the latest version with a
different application.  I now routinely add

SessionManager current isRuntime ifTrue: [SessionManager current exit].

to the onViewClosed method of my main Shell to ensure that the image closes
when the shell closes.  I am not sure if this is due to the complexity of my
application doing something odd, or if it is a Dolphin problem.  I have not
looked at the issue in detail since it is a pain to test, and the above
workaround worked for me.  Have others been seeing this issue (check the
task list, and see if your applications are still running after all views
are closed)?

Chris

"Bill Schwab" <[hidden email]> escribió en el mensaje
news:[hidden email]...
> Blair,
>
> I'm taking another run at changing to 5.1, and hit a snag with a deployed
> app not shutting down.  It has one shell which appears to close properly,
> but then #keepAlive is never called.

I have the same problem, but I fixed it with a ProgressDialog on
#onViewClosed

onViewClosed
    super onViewClosed.
    self showProgressDialog.
showProgressDialog
   (ProgressDialog create: 'No cancel view' operation:
[:progress |
1 to: 100 do: [:i | Processor sleep: 10.
progress value: i.].])
caption: 'Desconecting ...';
allowCancel: false;
show.

Do not ask me why it works. I have some ideas but i'm not sure ...

Regards
Bruno

> I forgot it, but > I have the same problem, but I fixed it with a
ProgressDialog on
> #onViewClosed

I forgot it, but this is quick and dirty.

Blair,

Since Chris and Bruno are both reporting similar problems, I dug around a
little more, and finally tried an experiment with 5.1, reverting its #uiIdle
method to that in 5.0.  With no other changes, the offending exe shuts down
correctly.  Would you describe that as dangerous, or a reasonable hot fix?

You've heard of dumb questions.  You've heard of rhetorical questions.  This
might be the world's first dumb rhetorical question<g>: how can you have new
input if there are no open windows?  Ok, there might be other stuff in the
queue, but it's something to think about.  My "point" is that 5.1 seems to
be checking for new input after it's verified that there are no windows
open, which strikes me as a potential problem.

Another possible source of trouble is that GetMessage() can apparently block
even though GetQueueStatus() shows that input is in the queue.  The trouble
is that PeekMessage() and GetMessage() can filter out some messages that
GetQueueStatus() will report as being in the queue - the end result is a
blocked call.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill

You wrote in message news:[hidden email]...
> ...
> Since Chris and Bruno are both reporting similar problems, I dug around a
> little more, and finally tried an experiment with 5.1, reverting its
#uiIdle
> method to that in 5.0.  With no other changes, the offending exe shuts
down
> correctly.  Would you describe that as dangerous, or a reasonable hot fix?

It isn't dangerous if you only need to run on NT systems. On 9x you will
intermittently run into #1272 "Idle time UI validation stalls intermittently
on Windows 98". Basically the fix for #1272 is causing this issue of delayed
idle time shutdown of applications. I say "delayed" because if you are
patient the application will eventually shutdown.

The idle time shutdown mechanism was originally designed for embedded server
style applications that don't have any visible windows, and acts as a ping
to check whether the server should shut down. In this case immediate
shutdown is less of an issue, and some delay is inherent anyway. Later this
mechanism seems to have become the accepted means of shutting down all
applications, even though it is not 100% guaranteed to work (e.g. in an
application that opens hidden windows that remain open when the main app.
window has been closed by the user). It is good practice to initiate an
explicit session exit when the user attempts to close the application, even
though the majority of our samples don't do this, with the development
system being one notable exception. In many cases, e.g. as in the
development system, a confirmation prompt is appropriate when the user
closes the main application window, and this is an appropriate place to
insert that explicit exit.

Obviously the delayed shutdown needs to be addressed, but a reasonable
workaround is to include an explicit shutdown (by sending #exit to the
SessionManager) when the main app. window is closed.

>
> You've heard of dumb questions.  You've heard of rhetorical questions.
This
> might be the world's first dumb rhetorical question<g>: how can you have
new
> input if there are no open windows?

And the dumb answer is: It may have hidden windows, such as the those used
by COM. A thread may also be sent messages through the message queue that
are not destined for any window. But...

>...Ok, there might be other stuff in the
> queue, but it's something to think about.  My "point" is that 5.1 seems to
> be checking for new input after it's verified that there are no windows
> open, which strikes me as a potential problem.

This is probably where the issue lies, yes. Originally the idle process
runnning in InputState just checked for any input, new or otherwise, but
this caused #1272 since there is a bug in the Windows 9X implementation of
GetQueueStatus() such that it may start to report that input is available
every time it is called, regardless of whether that is actually the case.

I don't quite understand what you mean though since the existence of visible
windows is only checked after the system has determined that there is no
input available. However I can see that one potential issue here is that
having identified the absence of visible windows the loop will still quiesce
(i.e. go to sleep on the input Semaphore).

>
> Another possible source of trouble is that GetMessage() can apparently
block
> even though GetQueueStatus() shows that input is in the queue.  The
trouble
> is that PeekMessage() and GetMessage() can filter out some messages that
> GetQueueStatus() will report as being in the queue - the end result is a
> blocked call.

Which is why the system only uses GetQueueStatus() as a cheap indication
that there may be a message available to process. It doesn't call
GetMessage() until it has first called PeekMessage() to see if there is
really a message available. See InputState>>isInputReady: where this is all
explained.

Regards

Blair

Blair,

> > Since Chris and Bruno are both reporting similar problems, I dug around
a
> > little more, and finally tried an experiment with 5.1, reverting its
> #uiIdle
> > method to that in 5.0.  With no other changes, the offending exe shuts
> down
> > correctly.  Would you describe that as dangerous, or a reasonable hot
fix?
>
> It isn't dangerous if you only need to run on NT systems.

That would suffice to get me started.


> On 9x you will
> intermittently run into #1272 "Idle time UI validation stalls
intermittently
> on Windows 98".

Interesting: how long has this been with us?  Is it new to 5.1, or does it
go back further?


> Basically the fix for #1272 is causing this issue of delayed
> idle time shutdown of applications. I say "delayed" because if you are
> patient the application will eventually shutdown.

That explains why it worked once.  I assumed I had managed to run the wrong
app or something.


> The idle time shutdown mechanism was originally designed for embedded
server
> style applications that don't have any visible windows, and acts as a ping
> to check whether the server should shut down. In this case immediate
> shutdown is less of an issue, and some delay is inherent anyway. Later
this
> mechanism seems to have become the accepted means of shutting down all
> applications,

It seemed like the thing to do at the time :)


> even though it is not 100% guaranteed to work (e.g. in an
> application that opens hidden windows that remain open when the main app.
> window has been closed by the user).

That's probably my problem: sockets and/or COM.  FWIW, I've never had a
problem with it prior to 5.1.


> It is good practice to initiate an
> explicit session exit when the user attempts to close the application,
even
> though the majority of our samples don't do this, with the development
> system being one notable exception. In many cases, e.g. as in the
> development system, a confirmation prompt is appropriate when the user
> closes the main application window, and this is an appropriate place to
> insert that explicit exit.

Ok.  I should be able to factor out a method or two from my #keepAlive
override and make that work.  I already half-heartedly started on it (making
the #keepAlive route conditional) and got some weird behavior, but if it's
the preferred approach, I'll clean it up and make it work.


> Obviously the delayed shutdown needs to be addressed, but a reasonable
> workaround is to include an explicit shutdown (by sending #exit to the
> SessionManager) when the main app. window is closed.

That's ok with me.  The only caveat is that it assumes that I know which
shell should clobber the session - not that I can think of a situation in
which that's a problem for any of my apps.


[snip]
> I don't quite understand what you mean though since the existence of
visible
> windows is only checked after the system has determined that there is no
> input available. However I can see that one potential issue here is that
> having identified the absence of visible windows the loop will still
quiesce
> (i.e. go to sleep on the input Semaphore).

If you have doubts about my "logic" but see another explanation for the
problem scenario, then following your hunch is probably the right course.

Thanks!

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Blair,

> a reasonable
> workaround is to include an explicit shutdown (by sending #exit to the
> SessionManager) when the main app. window is closed.

The offending exe is happy with a forced exit.  My only regret about this is
over the loss of an idiot-proof solution to deciding when to shut down.  I
should be able to rig up a generic test based on the expected shell class,
dispatching that through the session manager to avoid short-term problems.

One question though: #exit works, but #quit is giving me trouble.  Is that
expected?  I used #quit in previous versions w/o incident.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Blair,

> a reasonable
> workaround is to include an explicit shutdown (by sending #exit to the
> SessionManager) when the main app. window is closed.

My first thought on how to recognize "the" main shell didn't work out, at
least not easily.  However, something similar to the #mainShell: method
below _appears_ to be working - I added it to each startup method that
creates a shell.  It's not exactly as shown below, because my trigger sends
#forceQuit which does some preliminary shutdown, and then sends #exit.

I'm suspicious that #quit is broken.  While there usually turn out to be
good reasons for this kind of thing, I had lots of trouble super-sending
from a #quit override, and even w/o the override, #quit does not seem to
close the sessions; the same code sending #exit works as expected.

Have a good one,

Bill



!RuntimeSessionManager methodsFor!

mainShell:aPresenter
 "New for D5.1, #keepAlive isn't always called, at least not in a timely
manner, so
 runtime sessions tend to get stuck in memory.  Blair recommends explicit
shutdown
 via #exit called from 'the' shell.  This method represents an attempt to
let
 sessions decide for themselves which shell should close them."

 aPresenter presenter when:#viewClosed send:#exit to:self.
 ^aPresenter.
! !
!RuntimeSessionManager categoriesFor: #mainShell:!public! !

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill

You wrote in message news:bgdml3$n4o5l$[hidden email]... sends
> #forceQuit which does some preliminary shutdown, and then sends #exit.

#quit is not the "officially blessed" way to shut down a GUI application
with open windows. #exit should be used to initiate an orderly shutdown in
the Microsoft approved away (i.e. via PostQuitMessage). However #quit (well
#quit:, so you should override that and not #quit), does eventually end up
getting called as an indirect result of a #exit message.

> I'm suspicious that #quit is broken.  While there usually turn out to be
> good reasons for this kind of thing, I had lots of trouble super-sending
> from a #quit override, and even w/o the override, #quit does not seem to
> close the sessions; the same code sending #exit works as expected.

Well, as I say #quit: is indirectly called by #exit anyway. The order of
events is like this:

    - SessionManager>>exit is sent
        - #exit calls UserLibrary PostQuitMessage() API
    - App. continues, returning to event loop
    ...
    - Event loop detects WM_QUIT when UserLibrary GetMessage() API call
returns FALSE, and sends #onQuit: to the SessionManager.
    - SessionManager>>onQuit: sends self #quit: (although some such as
DevelopmentSessionManager may override to prompt user for confirmation here)
    - SessionManager>>quit: gives the session a final change to abort
termination by returning false from its onExit method, the base
implementation of     which is responsible for triggering the
#sessionStopped event, and performing shutdown operations initiated from the
#shutdown method.
    - SessionManager>>quit: invokes the VM quit primitive (#primQuit:),
which exits the application and never returns to Smalltalk

You certainly wouldn't be able to supersend #quit and expect to have any
code after the supersend run, since SessionManager>>primQuit: does not
return.

#quit: must be basically working, since it is the only way to exit Dolphin
short of deliberately raising an unhandled exception and waiting for
Microsoft's dialog :-), and indeed I find that evaluating the following
expression in a workspace is pretty terminal:

        SessionManager current quit

Regards

Blair