-processing 1.0.3

void setup() {
noLoop();
}

void draw() {
}

void stop(){
println("stop!");
super.stop();
}

--------------
output on close
--------------
stop!
stop!
--------------

when the sketch was closed, stop() event was called 2 times.
if commentout noLoop() , stop() is called once.
Why?

Is this is an exported applet? An application? How is it that you're "closing" the sketch?

at running in IDE, stop() event was called 2 times.
at running as Application, stop() event was called 0 times.

>How is it that you're "closing" the sketch?
Pushing the top-right corner "X"(CLOSE) button on Windows.

When running in the Processing 1.0.9 IDE on OSX 10.6.2 closing the applet
using the red X on the applet window calls stop() twice. Closing the applet
with <command>-q usually calls stop() twice, but intermittently only calls
it once. Closing the applet with the IDE stop button or selecting Quit from
the menu bar does not call stop().

I went through and added a bunch of Println statements into Papplet.java
and recompiled to see what was going on. When noLoop is on and you quit the
sketch exit() calls stop() explicitly, followed by exit2():

// if not looping, need to call stop explicitly,
// because the main thread will be sleeping

stop sets thread = null and finished = true, exit2() executes
System.exit(0) which somehow causes run() to execute. Run calls stop again
because finished == true, but this time stop returns void. I commented out
stop altogether in exit() and the applet seems to close normally, though
run is not called on System.exit(0) so stop() never executes.

Finally took a minute to sort this out.

When noLoop() is on and you quit, exit() is called. In exit() the main thread is assumed to be
asleep so stop() is called explicitly, followed by exit2(), which calls System.exit(0). This
System.exit(0) does not throw an exception, but something odd is happening because it calls
run() one last time instead of exiting. Because everything was shutdown in the first stop()
call, run() skips its primary function and begins closing down the applet. Here, stop() is called
again from run(), followed by exit2(), which completes as expected.

The second stop() called in run() seems odd, but its not hurting anything. It checks to see if it
was already run, and then exits without doing anything in this instance because it has.

A few questions:
Is this really an issue? Stop() is normally called when the program is closing and again by
destroy(), just in case the user has overwritten stop accidentally.

If this is an issue, why don't we move the stop() and exit2() calls from the end of run to the
looping case for exit()? Right now we explicitly take care of this when looping is off, but when
looping is on we let things run for one more frame and then stop? Seems cleaner to do both in
exit(), but I can't test it right now.

thanks, this is helpful. it's clear that stop/exit/exit2 all need to be
sorted out, and done alongside the applet state calls (start() and stop()
being called by the applet context).

putting this on the list for the next major release, and will try to get a
pre-release out soon with some fixes since it affects a lot of basic things
so it'll need testing.