order of response to #sessionStopped event

What I'm trying to do is to have my application send a
logout message (via a socket) to the server when the
user closes the last of the application windows.

I think I had this working, perhaps accidentally, in
Dolphin 4.00 pl? with code something like:

     SessionManager current
        when: #sessionStopped
        send: #logOut
        to: UserSession current.

where UserSession>>current would open a socket and
transmit the logout information to the server.

This appeared to quit working when I moved to Dolphin
4.01.3, giving a socket error of some sort (sorry, I'm
posting from Linux at the moment and don't have my full
notes available).  It seems that access to the sockets
had ceased, also in response to the #sessionStopped event,
prior to my attempt to logout.

I noticed Dolphin code in 4.01.3 on WSockLibrary and
SocketAbstract that also expresses an interest in
the #sessionStopped event like this:

   WSockLibrary class>>initialize
      SessionManager current
          when: #sessionStopped send: #onExit to: self.

   SocketAbstract class>>initialize
      SessionManager current
          when: #sessionStopped send: #onShutDown to: self.


So, I thought "aha! I bet that is a change from 4.00" so I
brought up 4.00 and looked at the above two #initialize
methods but they seemed to be just the same.

Any thoughts as to whether something else might have changed
that affects the order of the #sessionStopped event processing
or how I could/should change that order?

The #sessionStopped event is so convenient compared to
keeping track of the opening and closing of my
application's windows.  My quick and dirty compromise is
to catch the close requested event on the main window and
log out, but that can leave the user logged out yet with
some application windows still open, which isn't perfect.


-- Frank
[hidden email]

Frank,

> Any thoughts as to whether something else might have changed
> that affects the order of the #sessionStopped event processing
> or how I could/should change that order?

It might have been that the 4.0 image had an empty slot in the event table
and I think (?) that new events are placed in the first empty slot. This
could mean that your event was triggered first. If the 4.01 image didn't
have this empty slot (a difference in the way the initial image was created
by OA) then your event could be added last.  Just a guess though.

For a fix, 3.5 things spring to mind

1) "Naughty" one first <g> I don't think the order in the
EventsMessageSequence is ever changed, even when the Array is compressed,
the following should (might?) ensure that your shutdown is always
performed first.

SessionManager current
    when: #sessionStopped send: #logOut to: UserSession current.
x := SessionManager current events at: #sessionStopped.
index := (1 to: x size)
    detect: [:index | (x receivers at: index) == UserSession current].
x receivers swap: 1 with: index.
x messages swap: 1 with: index

2) In the #onCloseRequested method of all you shells do a check of the
number of open windows and log off if there is only one left. This might be
a bit dodgy in the development environment, not so sure about a deployed
app. NB I haven't checked if #allInstances is forcibly stripped during
deployment?

Shell1 allInstances size + Sell2 allInstances size = 1
    ifTrue: [UserSession current logOff]

3) I assume you've got a RuntimeSessionManager subclass? If so you can
override #onExit (the SessionManager method that triggers the
#sessionStopped event) to either trigger an event of your own
(#preSessionStopped) or send "UserSession current logOut" directly. Don't
forget the supersend afterwards though!

3.5) There are also quite a few methods in the image that you could modify
to ensure that #logOff is sent at the appropriate time, it's probably best
to avoid that if possible though.

3 looks the best to me but YMMV.

Standard disclaimers about trashed images apply <g>

Regards
    Ian

Frank,

> > Any thoughts as to whether something else might have changed
> > that affects the order of the #sessionStopped event processing
> > or how I could/should change that order?
>
> It might have been that the 4.0 image had an empty slot in the event table
> and I think (?) that new events are placed in the first empty slot. This
> could mean that your event was triggered first. If the 4.01 image didn't
> have this empty slot (a difference in the way the initial image was
created
> by OA) then your event could be added last.  Just a guess though.

Ian is probably right here. The ordering of event triggers is "undefined" so
you can't really rely on them.

Ugh.

> 2) In the #onCloseRequested method of all you shells do a check of the
> number of open windows and log off if there is only one left. This might
be
> a bit dodgy in the development environment, not so sure about a deployed
> app. NB I haven't checked if #allInstances is forcibly stripped during
> deployment?
>
> Shell1 allInstances size + Sell2 allInstances size = 1
>     ifTrue: [UserSession current logOff]

Rather than the #allInstances method why not use a class variable in one of
your shell classes to keep count of all the windows that you open. Then you
can check this in #onViewClosed and do your shutdown as the last window is
being closed.

> 3) I assume you've got a RuntimeSessionManager subclass? If so you can
> override #onExit (the SessionManager method that triggers the
> #sessionStopped event) to either trigger an event of your own
> (#preSessionStopped) or send "UserSession current logOut" directly. Don't
> forget the supersend afterwards though!

This is the best idea IMO.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

>> Any thoughts as to whether something else might have changed
>> that affects the order of the #sessionStopped event processing
>> or how I could/should change that order?
>
> It might have been that the 4.0 image had an empty slot in the event table
> and I think (?) that new events are placed in the first empty slot. Thi

Thanks Ian and Andy.  So, the real mystery was why it worked before
(in 4.00) rather than why it didn't work in 4.01.  And, the theory
about the empty slot explains that nicely.

Thanks for the suggestions, etc.

> 3) I assume you've got a RuntimeSessionManager subclass?

Yes.

> If so you can
> override #onExit (the SessionManager method that triggers the
> #sessionStopped event) to either trigger an event of your own
> (#preSessionStopped) or send "UserSession current logOut" directly. Don't
> forget the supersend afterwards though!

Great.  That sounds like the approach I'll use.


-- Frank
[hidden email]

> Standard disclaimers about trashed images apply <g>

(I wonder what he means by that.  I wonder if I should
consider making some sort of backup.  Nah, why bother.)