FAQ
Cover
\
Build
\
Source
\
Bugs
\
Reference
\
Libraries
\
Tools
The bugs database has moved
here
.
Bug 77 : stop() method not being called consistently (and therefore no dispose() called for libs)
Last modified: 2010-06-05 10:29
P
roject:
processing
trash
Version:
unspecified
Co
m
ponent:
android
book
core
libraries
pde
reference
tools
web
Status:
RESOLVED
Resolution:
DUPLICATE of bug
131
Pr
i
ority:
P3
Severity:
normal
Platform
All
O
S:
All
Windows
Mac OS
Linux
Other
Reporter:
fry
Assigned To:
fry
Attachment
Type
Created
Size
Actions
Description
: Opened: 2005-07-15 16:41
doesn't seem to be actually stopping things
Additional Comment
#1 From fry 2005-07-15 16:48
meaning that libraries and whatnot aren't getting dispose() called properly
either
Additional Comment
#2 From fry 2005-11-30 12:10
the stop() method may not be called consistently, especially in browsers.
also in the p5 environment, or when the close box is hit on an external frame.
this is separate from the issue of hitting stop causing things to lock up,
bug #126
.
Additional Comment
#3 From fry 2005-11-30 12:13
ok, to clarify again, there are two issues.
1) stop() is not getting called consistently (whether by browsers or the p5
environment)
2) as a result (though there could be contributing factors), the dispose()
methods on libraries are not being called either, meaning that threads may
keep going.
Additional Comment
#4 From fry 2005-12-27 21:46
***
Bug 264
has been marked as a duplicate of this bug. ***
Additional Comment
#5 From fry 2005-12-27 21:48
bug #264
has an example of this being a problem for the Capture class, where the capture
continues even after stop is hit.
may need to at least cover the issue of the stop button being hit in the environment and
killing things off.
Additional Comment
#6 From fjen 2007-11-24 03:18
os-x 10.4, processing 133, java 1.4.2, powerbook g4, speed link usb camera
same problem, just thought i'd add my workaround ...
i have a really cheap camera which is going to be used for tracking. i runs on the macam
(
http://webcam-osx.sourceforge.net/
) quicktime component which works fine so far except
for one problem. most of the time when i restart (close window and reopen) the sketch it
will report:
quicktime.std.StdQTException[QTJava:
6.1.7g],-9405=couldntGetRequiredComponent,QT.vers:7168000
at quicktime.std.StdQTException.checkError(StdQTException.java:38)
java.lang.NullPointerException
at Temporary_5218_3151.stop(Temporary_5218_3151.java:76)
at processing.core.PApplet.die(PApplet.java:2492)
at processing.core.PApplet.die(PApplet.java:2511)
at processing.video.Capture.<init>(Capture.java:219)
at Temporary_5218_3151.setup(Temporary_5218_3151.java:11)
at processing.core.PApplet.handleDisplay(PApplet.java:1384)
at processing.core.PGraphics.requestDisplay(PGraphics.java:690)
at processing.core.PApplet.run(PApplet.java:1556)
at java.lang.Thread.run(Thread.java:552)
things i tested that did not work:
1)
registerDispose( cam );
2)
public void dispose()
{
cam.dispose();
}
3)
public void stop()
{
cam.stop(); // this is only called for applets, right?
}
4)
instead of just closing the window:
pressing stop or play buttons in processing, hitting command-q
workaround i found:
Capture cam;
void setup () {
size( 320, 240 );
cam = new Capture( this, width, height, 24 );
}
boolean videoAvailable = true;
void draw ()
{
if ( videoAvailable ) { /* normal draw code */ }
else if ( !videoAvailable )
{
cam.dispose();
System.exit(0);
}
}
void keyReleased ()
{
if ( key == 'q' )
{
videoAvailable = false;
}
}
// now hitting 'q' kills the running sketch and successfully stops capture ...
Additional Comment
#7 From fjen 2007-11-24 23:27
found another workaround to the problem described before (camera not working a second time
because dispose was not called) ... in case someone needs it.
void setup()
{
try { quicktime.QTSession.open(); }
catch ( Exception e ) { /* ignore */ }
quicktime.QTSession.close();
// ...
}
Additional Comment
#8 From fry 2010-06-05 10:29
*** This bug has been marked as a duplicate of
131
***