Closing the application Powered by Dolphin Smalltalk
Sebastian Sastre
I'm having an irregular problem closing a pair of application recently
deployed.
The thing is when you close the main window expecting that the program
to be closed and it corresponding OS process.
A) In one case the window closes and the process is still alive (looking
in the Windows's task manager).
B) In other case it happends only sometimes, I mean, sometimes close the
window AND the process (like you allways want to), and sometimes only the
main window leaving the process alive.
C) In the case that allways was leaving the process alive when closing
it's window, I figure out that starting from a fresh image and loading all
the packages againg I can turn a C case into a B one.
Any clue?
best regards,
--
Sebastián Sastre
ssa...@seaswork.com.ar
www.seaswork.com.ar
Jochen Riekhof
> The thing is when you close the main window expecting that the program
> to be closed and it corresponding OS process.
I experienced the same with my apps and I simply put the method
------------------------------
onViewClosed
super onViewClosed.
SessionManager current isRuntime ifTrue: [SessionManager current quit]
------------------------------
into my application frame presenter.
For me it works great so far.
Ciao
...Jochen
Bill Schwab
To Jochen's reply, I'll add that the archives should contain some fairly
recent discussion of similar problems.
Have a good one,
Bill
--
Wilhelm K. Schwab, Ph.D.
bi...@anest4.anest.ufl.edu
Sebastian Sastre
I forgot to tell that this problem occurs only on win98 systems, on XP
everything is ok,
I'm using the code you mention but the problem persist on win98.
regards,
Seb
"Jochen Riekhof" <joc...@riekhof.de> escribió en el mensaje
news:3f96...@news.totallyobjects.com...
Bill Schwab
> I forgot to tell that this problem occurs only on win98 systems, on XP
> everything is ok,
>
> I'm using the code you mention but the problem persist on win98.
Sounds like time for #outputDebugString: and DebugView from
www.sysinternals.com. It's ugly, but it eventually works. Also, are you
getting any unhandled exceptions on either OS?
Peter Goodall
I'm having a problem with my app in a similar area. I've built a window with
three buttons, that launch three
tool windows used for tagging some objects with attributes. The launcher
window keeps a reference to the
opened tool window, of which only one is allowed to be open at a time. If
one tool window is open, and the
button for another is pushed, the old tool window is closed , and the new
opened.
This works fine in the development image, but in the stripped deployment
image, closing an open tool window
by either pressing a launcher button, or the close widget on a tool window,
closes the whole application.
(Which ruins the whole effect :). The SessionManager I'm using simply opens
the launcher window.
Any ideas as to what is changing during the image stripping process? Or why
close suddenly becomes global?
Thanks,
--Peter Goodall
"Jochen Riekhof" <joc...@riekhof.de> wrote in message
news:3f96...@news.totallyobjects.com...
Peter Goodall
The tool windows were originally stand-alone & the had a little test that
asked the SessionManager if it isRuntime when the closed. If that was true,
they quit the SessionManager.
Pardon me.
--Peter Goodall
"Peter Goodall" <ne...@petergoodall.com> wrote in message
news:3f98521b$0$28121$afc3...@news.optusnet.com.au...
> Hi All,
>
> I'm having a problem with my app in a similar area. I've built a window
with
> three buttons, that launch three
> tool windows used for tagging some objects with attributes. The launcher
> window keeps a reference to the
> opened tool window, of which only one is allowed to be open at a time. If
> one tool window is open, and the
> button for another is pushed, the old tool window is closed , and the new
> opened.
>
> This works fine in the development image, but in the stripped deployment
> image, closing an open tool window
> by either pressing a launcher button, or the close widget on a tool
window,
> closes the whole application.
> (Which ruins the whole effect :). The SessionManager I'm using simply
opens
> the launcher window.
>
> Any ideas as to what is changing during the image stripping process? Or
why
> close suddenly becomes global?
>
> Thanks,
> --Peter Goodall
[...]
Sebastian Sastre
"Peter Goodall" <ne...@petergoodall.com> escribió en el mensaje
news:3f98d5a2$0$497$afc3...@news.optusnet.com.au...
Sebastian Sastre
onViewClosed
super onViewClosed.
SessionManager current isRuntime ifTrue: [SessionManager current
primQuit:0].
regards,
--
Sebastián Sastre
ssa...@seaswork.com.ar
www.seaswork.com.ar
"Bill Schwab" <bi...@anest4.anest.ufl.edu> escribió en el mensaje
news:bn9ivn$v6vcf$1...@ID-58434.news.uni-berlin.de...
Blair McGlashan
You wrote in message news:bnbg1d$ulkt1$1...@ID-71120.news.uni-berlin.de...
> Perhaps, but it's working OK with this code:
>
> onViewClosed
> super onViewClosed.
> SessionManager current isRuntime ifTrue: [SessionManager current
> primQuit:0].
I wouldn't recommend using #primQuit: directly, since it will exit the image
without running any cleanup code. On the whole this doesn't matter, since
the OS will clean up after a Process reasonably well (at least on NT, 2K,
XP). If #quit is not working this suggests that something that happens after
that point (i.e. in the housekeeping performed before shutdown) that is
preventing #primQuit: being called. I would recommend investigating why,
perhaps by making use of the debug trace device (send output to the Trace
global stream from the image, and use the sysinternals dbgview.exe tool to
view the output).
The following news article explains a bit more about the shutdown sequence
in Dolphin, and how to initiate it:
Regards
Blair