java.lang.NullPointerException: arguments || graphics
at sun.awt.windows.WGraphics.devFillPolygon(Native Method)
at sun.awt.windows.WGraphics.fillPolys(WGraphics.java:695)
at
sun.java2d.pipe.ShapeToPolyConverter.sendPoly(ShapeToPolyConverter.java:79)
at
sun.java2d.pipe.ShapeToPolyConverter.doDraw(ShapeToPolyConverter.java:129)
at
sun.java2d.pipe.ShapeToPolyConverter.fill(ShapeToPolyConverter.java:48)
at
sun.java2d.loops.RasterOutputManager.drawTextOutline(RasterOutputManager.java:2653)
at
sun.java2d.loops.RasterOutputManager.drawString(RasterOutputManager.java:2890)
at sun.java2d.SunGraphics2D.drawString(SunGraphics2D.java:2245)
at app2d$1.run(app2d.java:61)
at java.lang.Thread.run(Thread.java:484)
I've created the thread in the paint() method because then the Graphics
object is available. Didn't see a way to put this in init().
The code is basically like this:
public void paint (final Graphics g) {
if ( th == null ) { // First time only, create and
start thread
th = new Thread(new Runnable () {
public void run () {
while (true) {
g.drawString("Count:"+counter++, 10, 10);
}
}
});
th.start();
}
}
Why does the drawString() not work ? Am I overlooking something ?
TIA for any ideas.
Chris
When I look at this code I consider it quite strange. To be honest I'm not sure
you can do what your doing at all.
A way to fix it is to make your applet implement Runnable and then run the
thread on "this" where the run method contains a call to paint and have the
contents of the paint method as g.drawString("Count:"+counter++, 10, 10);
Then when you first run it you create the thread and the first thread does the
counter and then from then on the second thread does the job and its entirely
contained within the same class.
But like I say I've got no real reason why this doesn't work properly, or fails
in the way you describe but I'm sure that not calling update to clear the screen
or using any buffering is a bad plan anyhow.
The Graphics object passed to paint() is only valid until paint() returns. By passing it
to another thread, you end up using it after paint() has returned. At that point (in so
many words), the Graphics object is no longer valid.
--
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
===================================================================
* Check out Database Debunkings (http://www.firstsql.com/dbdebunk/)
* "Where Persistent Prevailing Database Fallacies Are Dispelled"
> When I look at this code I consider it quite strange. To be honest I'm not
sure
> you can do what your doing at all.
>
Yes, it's weird isn't it. Real newbie stuff. Dunno what came over me ;-)
> A way to fix it is to make your applet implement Runnable and then run the
> thread on "this" where the run method contains a call to paint and have
the
> contents of the paint method as g.drawString("Count:"+counter++, 10, 10);
>
Indeed that's what I should have done. And it works, too. repaint() is the
key.
> Then when you first run it you create the thread and the first thread
does the
> counter and then from then on the second thread does the job and its
entirely
> contained within the same class.
>
> But like I say I've got no real reason why this doesn't work properly, or
fails
> in the way you describe but I'm sure that not calling update to clear the
screen
> or using any buffering is a bad plan anyhow.
>
Probably it doesn't work because the Graphics context is only valid within
the
paint() method, as suggested by Lee. A moot point now, as I've seen the
light ;-)
Thanks for helping me out.
Cheers,
Chris
>