> When the user closes the applet window, destroy() is called, which runs to
> the end of that method and then program execution terminates...
> Except if the browser is closed (or was already closed) before destroy()
> ends, in which case program execution terminates before destroy() is
> finished executing.
> This prevents my client applet from carrying out a normal sign-off from my
> server application. Is there anything I can do to preserve a normal applet
> termination when the browser is closed early?
Without really knowing the answer to your question, I'm going to take an
educated guess and say no. If the answer was yes, I could make my applet
persist in memory for as long as I wanted, which would be a really bad
thing as far as performance goes. Being able to persist your applet
indefinitely *seems* like it would go against the idea of sandboxing. But
I could be wrong.
I would be interested to see if anyone else has any concrete answers for
you.

Signature
Of making better designs there is no end,
and much refactoring wearies the body.
Oliver Wong - 08 Nov 2005 21:13 GMT
>> When the user closes the applet window, destroy() is called, which runs
>> to
[quoted text clipped - 19 lines]
> I would be interested to see if anyone else has any concrete answers for
> you.
Benji's point makes sense. I just wanted to additionally say that when
writing client/server applications, you should write code to handle
unexpected disconnections, because it's fairly typical in a networked
environment.
- Oliver
> ..Is there anything I can do to preserve a normal applet
> termination when the browser is closed early?
No. You might wrap your applet in JWS to give it a more
predicatable environment, though.