Is it alright to show a ProgressDialog in a shell's #onViewClosed?

Hi all,

In the #onViewClosed of my main application shell, I'm showing a  
ProgressDialog (for OmniBase users, I'm running the OmniBase GC). But it  
seems that this causes the #onViewClosed to be sent again for this shell.  
Below is a package which prints messages to a debugger. I only managed to  
trace it to GUISessionManager>>windowSystemShutdown (BTW, if Andy/Blair is  
reading, there's a typo in the comment, "releave" should be "release"). Is  
this something that shouldn't be done?

Is there a way to test-run session managers? It was rather painful  
process, deploying and running the package again and again and reading  
debug outputs until I realise it was that ProgressDialog. Thank you.

========================
| package |
package := Package name: 'AAProgessDialog'.
package paxVersion: 0;
        basicComment: ''.

package imageStripperBytes: (ByteArray fromBase64String:  
'IVNUQiAxIEYPDQAEAAAASW1hZ2VTdHJpcHBlcgAAAAAAAAAAUgAAAA8AAABBQVByb2dlc3NEaWFs
b2dSAAAAEwAAAEFBUHJvZ2Vzc0RpYWxvZy5leGWaAAAAAAAAALABAABSAAAAEAAAAEFBU2Vzc2lv
bk1hbmFnZXLvvyUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==').

package classNames
        add: #AASessionManager;
        add: #AShell;
        yourself.

package binaryGlobalNames: (Set new
        yourself).

package globalAliases: (Set new
        yourself).

package allResourceNames: (Set new
        yourself).

package setPrerequisites: (IdentitySet new
        add: 'Object Arts\Dolphin\Base\Dolphin';
        add: 'Object Arts\Dolphin\MVP\Base\Dolphin MVP Base';
        add: 'Object Arts\Dolphin\Lagoon\Lagoon Image Stripper';
        yourself).

package!

"Class Definitions"!

Shell subclass: #AShell
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        classInstanceVariableNames: ''!
RuntimeSessionManager subclass: #AASessionManager
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        classInstanceVariableNames: ''!

"Global Aliases"!


"Loose Methods"!

"End of package definition"!

"Source Globals"!

"Classes"!

AShell guid: (GUID fromString: '{FC5C4C0B-6ABE-461A-8539-639AA88CCA01}')!
AShell comment: ''!
!AShell categoriesForClass!MVP-Presenters! !
!AShell methodsFor!

onViewClosed
        KernelLibrary default outputDebugString: 'onViewClosed'.
        ProgressDialog showModalWhile:
                        [:progress |
                        1 to: 100
                                do:
                                        [:i |
                                        Processor sleep: 30.
                                        progress
                                                value: i;
                                                text: i displayString , '%'].
                        'completed'].
        super onViewClosed! !
!AShell categoriesFor: #onViewClosed!event handling!public! !

AASessionManager guid: (GUID fromString:  
'{F9554393-E54C-4E1C-A535-FECDC6801A16}')!
AASessionManager comment: ''!
!AASessionManager categoriesForClass!System-Support! !
!AASessionManager methodsFor!

main
        AShell show! !
!AASessionManager categoriesFor: #main!operations!public! !

"Binary Globals"!

"Resources"!

===========================


--
Regards
Hwee Boon
MotionObj

"Yar Hwee Boon" <[hidden email]> wrote in message
news:[hidden email]...
> Hi all,
>
> In the #onViewClosed of my main application shell, I'm showing a
> ProgressDialog (for OmniBase users, I'm running the OmniBase GC). But it
> seems that this causes the #onViewClosed to be sent again for this shell.
> Below is a package which prints messages to a debugger. I only managed to
> trace it to GUISessionManager>>windowSystemShutdown (BTW, if Andy/Blair is
> reading, there's a typo in the comment, "releave" should be "release"). Is
> this something that shouldn't be done?

No, you can't use a ProgressDialog from #onViewClosed, because when this is
triggered by Windows sending a WM_QUERYENDSESSION message (i.e. a system
shutdown request), Windows is expecting a synchronous reply within a fairly
short time. ProgressDialog blocks the calling process, and forks off another
(all dialogs do this with the standard implementation of
DialogView>>runModalLoop). ProgressDialog has the additional complication of
starting another process to perform the operation who's progress is
monitored. Anyway the new UI process will start processing more messages,
and so Windows will think the application is still responding, but has not
processed the WM_QUERYENDSESSION, which (I think) makes it send it again.

You will get exactly the same problem if you use a non #taskModal message
box from the #onViewClosed (see e.g.
http://groups.google.co.uk/groups?selm=ak6beo%241geh1o%241%40ID-50941.news.dfncis.de&output=gplain).
The fact that a #taskModal message box will work in this case suggest to me
that you could create a custom DialogView subclass (and using that a custom
ProgressDialog view) which overrides #runModalLoop with 'self
runModalInProcessLoop', and that may allow you to show a progress dialog on
view closure, however I haven't tried this.

Why do you want to display a ProgressDialog on shutdown anyway, it seems an
unusual UI design? If your application takes a significant time to terminate
on system shutdown (more than 20 seconds), then Windows will display one of
its 'kill this application now?' prompts regardless of whether you have a
progress dialog up. Also do you think your users will like having to wait
for a lengthy process to run every time they shutdown your application? I'd
suggest allowing the user to run the housekeeping operation on demand - you
could prompt them on a regular basis and ask them if they would like it
initiated. Alternatively you could run it as an offline process scheduled to
run at particular times of day.

>
> Is there a way to test-run session managers? It was rather painful
> process, deploying and running the package again and again and reading
> debug outputs until I realise it was that ProgressDialog. Thank you.

No, although you can reduce the cycle time by either turning off most
stripping options or using RuntimeSessionManager class>>deploy: (see the
comment in that method). The latter in particular will allow you to create
an unstripped runtime image almost instantly. Assuming your problem is not
related to image stripping, this will allow you to diagnose runtime problems
much more quickly.

Regards

Blair

On Mon, 20 Sep 2004 12:46:44 +0100, Blair McGlashan <[hidden email]> wrote:

Thanks for the prompt reply and explanation regarding WM_QUERYENDSESSION  
handling and #taskModal.

> Why do you want to display a ProgressDialog on shutdown anyway, it seems  
> an
> unusual UI design? If your application takes a significant time to  
> terminate
> on system shutdown (more than 20 seconds), then Windows will display one  
> of
> its 'kill this application now?' prompts regardless of whether you have a
> progress dialog up. Also do you think your users will like having to wait
> for a lengthy process to run every time they shutdown your application?

Ahh.. It's to run the OmniBase garbage collector. In the light of your  
explanation, I can't risk doing that anymore, since that and things like  
committing changes etc might well take more time than that if the hardware  
is slow. I did consider alternatives like doing it on startup, but figured  
that it is less irritating to wait during shutdown rather than startup. As  
for housekeeping on demand, I wanted to insulate users from these more  
technical aspects as much as possible and the GC fast enough if it ran  
everytime the application ran. I'll play around with these and other  
alternatives again and see which is the most suitable.

> No, although you can reduce the cycle time by either turning off most
> stripping options or using RuntimeSessionManager class>>deploy: (see the
> comment in that method). The latter in particular will allow you to

Thanks for the tip.

--
Regards
HweeBoon
MotionObj