Does QuitSystem event handling work?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Does QuitSystem event handling work?

Joachim Geidel
Hi all,

since VW 7.1, VW contains support for responding to QuitSystem events when Windows shuts down. This is described in the release notes of VW 7.2.1. I am trying to use this feature, such that the application asks the user if pending changes should be saved, and to disconnect any database connections. However, it doesn't seem to work, and so far I didn't find out whether I it's my fault or a problem with the feature itself.

Here's what I did to test the feature, following the description in the release notes:
- In a subclass of InputState, there's a method #send:eventQuitSystem: which writes a timestamp to a log file and calls 'super send: window eventQuitSystem: event '.
- An instance of the InputState subclass is installed, such that 'InputState default' answers this instance.
- In a workspace, I evaluated
    ObjectMemory registerObject: true withEngineFor: 'acceptQuitEvents'
  and saved the image.
- When I shut down Windows or end my Windows session, VisualWorks quits, but it does not create any log file.

As I said, I have no idea what's wrong. :-(

Joachim Geidel

Reply | Threaded
Open this post in threaded view
|

Re: Does QuitSystem event handling work?

eliot-2
Hi Joachim,

        all the quit event does is evaluate ObjectMemory quit (see InputState>>send:eventQuitSystem:), and ObjectMemory class>>quit certainly does evaluate ExternalStream commitOpenStreams.  So if you get your log file produced if you test by evaluating
        ObjectMemory quit
youd expect the quit mechanism to produce it also.

ObjectMemory class>>quit notifies Subsystem of the imminent quit so you can add a Subsystem class to add any required additional behaviour.

HTH

[hidden email] wrote:

| Hi all,

| since VW 7.1, VW contains support for responding to QuitSystem events when Windows shuts down. This is described in the release notes of VW 7.2.1. I am trying to use this feature, such that the application asks the user if pending changes should be saved, and to disconnect any database connections. However, it doesn't seem to work, and so far I didn't find out whether I it's my fault or a problem with the feature itself.

| Here's what I did to test the feature, following the description in the release notes:
| - In a subclass of InputState, there's a method #send:eventQuitSystem: which writes a timestamp to a log file and calls 'super send: window eventQuitSystem: event '.
| - An instance of the InputState subclass is installed, such that 'InputState default' answers this instance.
| - In a workspace, I evaluated
|     ObjectMemory registerObject: true withEngineFor: 'acceptQuitEvents'
|   and saved the image.
| - When I shut down Windows or end my Windows session, VisualWorks quits, but it does not create any log file.

| As I said, I have no idea what's wrong. :-(

| Joachim Geidel
---
Eliot Miranda                 ,,,^..^,,,                mailto:[hidden email]
VisualWorks Engineering, Cincom  Smalltalk: scene not herd  Tel +1 408 216 4581
3350 Scott Blvd, Bldg 36 Suite B, Santa Clara, CA 95054 USA Fax +1 408 216 4500


Reply | Threaded
Open this post in threaded view
|

Re: Does QuitSystem event handling work?

Joachim Geidel
In reply to this post by Joachim Geidel
Hi Eliot,

> all the quit event does is evaluate ObjectMemory quit (see
>InputState>>send:eventQuitSystem:), and ObjectMemory class>>quit certainly
>does evaluate ExternalStream commitOpenStreams.  So if you get your log file
>produced if you test by evaluating
> ObjectMemory quit
>youd expect the quit mechanism to produce it also.

Whatever I tried, send:eventQuitSystem: wasn't executed when ending my Windows session. Sending a kill signal on Linux works.

>ObjectMemory class>>quit notifies Subsystem of the imminent quit so you can
>add a Subsystem class to add any required additional behaviour.

Thanks for pointing that out, I hadn't thought of this option. That's much simpler than hacking the InputState. I got it working in almost no time at all. :-)

Best regards,
Joachim