how to finish a java applet when I change of url in IExplorer

[davidgrs]

I have a problem with a java applet that has inside a thread, when I
change of page, the java applet is still runing, and then when I load
another page tha cotaints this java applet, I have two instances
running in my internet explorer.

I am aware of this because my java application uses tcp sockets
communications, and the tcp activity is still alive when I changed of
paged in the Internet Explorer.

Thanks a lot.


David Rodriguez

 

[Sebastian Scheid]

I have a problem with a java applet that has inside a thread, when I
change of page, the java applet is still runing, and then when I load
another page tha cotaints this java applet, I have two instances
running in my internet explorer.

I am aware of this because my java application uses tcp sockets
communications, and the tcp activity is still alive when I changed of
paged in the Internet Explorer.

Did you override the stop()-method? You should stop the communication and
the thread there. Be aware that stop is called when loading another page,
quitting the browser or minimizing the browser window. When displaying the
page again (by jumping back in history or restoring the window) start() is
called. Test this behaviour with different browsers. Perhaps you can use the
destroy()-method, too.

Regards
Sebastian

 

[Andrew Thompson]

Did you override the stop()-method? You should stop the communication and
the thread there. Be aware that stop is called when loading another page,
quitting the browser or minimizing the browser window.

Be aware that while compatible browser/VM combinations are
*supposed* to call the stop() method on page exit, many don't.

You can never absolutely rely on stop() being called.

To the OP. You might be able to get around this problem by
applying the singleton design pattern here. Only one instance
of the applet will exit in any one VM.

Of course, if a browser choses to load mulitple VM's, all bets are
off, and you are better off to check for the original socket being
occupied to trigger an error/information message.