Page 2 of 2
If start() is called again, then it means that this was only a resize. Stop and nullify the killThread before it wrecks everything. Resume all the suspended threads, and continue running.
Here are the final versions of the applet's start() and stop() methods:
public void start() {
// If we were in the middle of kill thread
(caused by resizing)
// stop the killthread and start (i.e. resume)
extraThread.
// Otherwise just start as normal
if (killThread != null) {
killThread.stop();
System.out.println ("KILLTHREAD STOPPED");
killThread = null;
}
// Now start running the extraThread thread
if ( extraThread == null ) {
extraThread = new Thread(this);
extraThread.start();
}
else
extraThread.resume();
}
public void stop () {
// First suspend the extraThread thread
if ( (extraThread != null) &&
(extraThread.isAlive()) ) {
extraThread.suspend();
}
// Fire up a killthread, which will kill the
extraThread thread
// in 5 seconds unless start is called
if (killThread != null)
System.out.println ("ERROR - killThread
shouldn't exist");
else {
killThread = new KillThread(this);
killThread.start();
}
}
(NOTE: This assumes that we keep track of killThread and extraThread as object variables somewhere, which we would most likely be doing anyway.)
There you have it! With this stuff installed, you will never mess up an applet by resizing a Netscape browser again.
You might want to experiment with other browsers, although if they don't do things the way Netscape does, chances are this code will not affect things adversely. Also, the 5-second time limit may need to be shortened or lengthened, depending on the speed of different systems. So far, 5 seconds seem to do it okay on all the systems we've worked with.
I've seen a lot of applets out there that will "break" if you resize your browser window; this fix should put an end to that problem. If anyone knows of a more elegant solution besides launching a killThread, I'd love to hear about it! Happy coding.