Hi,
I'm having a problem with drawImage.
What I'm doing is making a simple class that is extends a Panel (did it
with Canvas with same result) and I call this class Picture.
An Image object can be passed into the Picture object and then on paint
the Picture object will draw the Image.
So, the problem is that the painting behavior is weird...
It will paint fine, then if you drag the applet so the Picture gui object
goes off the screen and then you drag it back on (causing redrawing), it
only seems to paint on the first paint event it receives... and
successive draws don't draw anything!
Now, if you again bring the Picture gui object FULLY off screen and then
back on it will again do the same thing (painting the first paint event),
so it seems to work for a full object paint, but not when only part of it
needs to paint.
Note that I've done testing to ensure the paint events are being
sent/received (they are), and that the Image is valid (it is), and that
drawImage method is returning true (it is).
Also Note that a drawString call in the same place as the drawImage call
works fine.
Finally, if I stretch the Image
ie) drawImage(img, 0, 0, 90, 90, obs) instead of
drawImage(img, 0, 0, 100, 100, obs)... assuming the image is 100x100
then it works fine (except that the image is stretched/squished)???
So, why would this behavior happen?
Hopefully I explained it well enough...
Picture class code follows:
-----------------------------------------------------------
package MyPackage;
import java.awt.Panel;
import java.awt.MediaTracker;
import java.awt.Image;
import java.awt.Graphics;
import java.lang.InterruptedException;
public class Picture extends Panel
{
private MediaTracker tracker = null;
private Image image;
public Picture(Image img)
{
tracker = new MediaTracker(this);
setPicture(img);
}
public void setPicture(Image img)
{
image = img;
if(img != null)
{
tracker.addImage(img, 0);
tracker.checkID(0, true);
}
repaint();
}
public void paint(Graphics g)
{
System.out.println("Picture Paint - Start");
try
{
if(!tracker.checkID(0))
{
tracker.waitForID(0);
}
if(!tracker.isErrorID(0))
{
if(g.drawImage(image, 0, 0, this))
System.out.println("Draw=T");
else
System.out.println("Drawn=F");
}
}
catch(InterruptedException ex)
{
System.out.println("Picture Paint - Int.Ex.");
}
super.paint(g);
}
}
-----------------------------------------------------------
Thanks for any and all help.
Andrew Thompson - 17 Jun 2005 23:29 GMT
> I'm having a problem with drawImage.
You'll get more people willing to help if you post an SSCCE..
<http://www.physci.org/codes/sscce.jsp>
OTOH..
> public void paint(Graphics g)
(please replace tabs with 2 or 3 spaces before posting)
> {
> System.out.println("Picture Paint - Start");
.....
super.paint(g);
> }
..that is an odd place to be making a call to super.paint(Graphics).
It would, as I understand, be interfering with the paint process.
Note - Follow-Ups set to comp.lang.gui only.

Signature
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.LensEscapes.com/ Images that escape the mundane
Me - 20 Jun 2005 20:21 GMT
As for the super.paint (as I alluded to in my first follow-up post) it
didn't create problems (since I was inheriting from Panel), not sure if
this is another bug or standard behavior... but anyway, when I changed to
JPanel, yes then super.paint did create an issue, and I dealt with that.
As for SSCCE, I appreciate the setting and enforcement of standards and
working practices such as this, but in this scenario I felt that the
problem was conceptually quite simple and adding a bunch of extra code
simply to create an applet/form/etc. would simply beef up the post and
make it more difficult to read and understand without much if any real
benefit.
PS.
I have seen some of your other responses to posts, and it is good to
govern conduct and standards in an environment like a newsgroup; however,
I do find that your tone is sometimes hostile and unhelpful. In
comparison your response to my post was atleast cordial.
Although I do not presume to know your responsibilities and situation, I
would suggest a less anal, and more constructive and sympathetic
approach.
As I said I do not mean to be presumptious, or hostile myself, but I
found the above needed to be said.
EOM
Andrew Thompson <SeeMySites@www.invalid> wrote in news:b6q84mzxi4e5
$.1qu7cx0ehkbnj$.dlg@40tude.net:
>> I'm having a problem with drawImage.
>
[quoted text clipped - 17 lines]
>
> Note - Follow-Ups set to comp.lang.gui only.
Andrew Thompson - 20 Jun 2005 20:42 GMT
> As for the super.paint (as I alluded to in my first follow-up post) it
> didn't create problems (since I was inheriting from Panel),
That means very little - you were calling super.paint() at the
*end* of your paint() method, so everything you did before that
was potentially being overwritten by the parent method.
Do you understand that much?
It is hard to say for sure without a complete code example, but
it seems you have achieved a solution largely through good luck.
Quick - buy a lottery ticket. ;-)

Signature
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.LensEscapes.com/ Images that escape the mundane
Me - 20 Jun 2005 22:10 GMT
Yes I understood perfectly well what you were getting to with your
super.paint suggestion; however, as I said it doesn't make a difference,
I could (and did try) removing the super.paint with NO change. Plus if
super.paint did make a problem, the problem it would make would most
likely be a full over draw of the component causing NO image to be seen
ever, which was not the case.
Note that as said, now with JPanel instead of Panel the problem with
super.paint does happen and it does draw fully over anything that I might
draw before calling it, and this is the behavior I suspected should
happen... and when writing my original code I thought it would (evidently
with Panel it does not though).
As for finding the solution??? I said I tryed using JPanel instead of
Panel, and it worked fine, I never said I solved the problem.... I did
NOT solve the problem, and therefore have submitted a bug report to Sun,
I also mentioned in my other follow up that I am still wondering why this
behavior is happening.
For the applet I'm writing currently I have a resolution, but NO I did
not find a solution for the problem.
Furthermore your (below) response illustrates the hostile and unhelpful
approach you seem to take (as I mentioned in my follow up to your
original comments), in that other follow up I tryed to be cordial (as I
called it), but in this one I will respond:
GET THAT BUG OUT OF YOUR a.s, BITCH
Andrew Thompson <SeeMySites@www.invalid> wrote in news:u0dnkg8t33lw
$.1snomwhyiqej4$.dlg@40tude.net:
>> As for the super.paint (as I alluded to in my first follow-up post) it
>> didn't create problems (since I was inheriting from Panel),
[quoted text clipped - 9 lines]
>
> Quick - buy a lottery ticket. ;-)
Me - 20 Jun 2005 20:02 GMT
So not sure what was wrong... If I forced the clip region full size on
each paint then it would work, but the origianl clip region values seemed
like they should be fine... anyway, forcing the values is no good.
So I continued to try and figure stuff out... I noticed that the problem
only happens in Java 1.5 (I tested with 1.4.1 & 1.4.2 and they were
fine), also using the Applet Viewer (v1.5) also works fine, so its just
the Java 1.5 browser plugin (tested with IE & Firefox).
I realized that I was extending Panel rather than JPanel, (and since most
my stuff is in swing anyway) I decided to change it to JPanel instead and
now it works (but in JPanel the super.paint cant be called as I had it, I
will instead need to call paintComponents I guess).
So in the end it is now working fine for me... BUT that doesn't solve the
problem that I have found, ie. my diagnosis is that 1.5 has introduced
something in Component (Panel inherits paint from it) that causes this
problem. I suppose with JPanel the underlying JContainer's paint is fine,
even though the same Component class is inherited from (via Container),
but I don't belive it inherits paint directly.
Anyway... not sure if this is a desired or known and ignored behavior or
if its a bug that needs fixing...
[EDITED]
> Hi,
> I'm having a problem with drawImage.
[quoted text clipped - 7 lines]
>
> Thanks for any and all help.
Me - 20 Jun 2005 22:48 GMT
Here is an executable version of the source, chopped it down to just what
is necessary... should run, and should produce the problem.
------------------------------------
package JavaTest;
import java.awt.*;
import javax.swing.*;
import java.net.*;
public class JavaTest extends JApplet
{
Picture picTest = new Picture();
public void init()
{
try
{
URL basepath = getCodeBase();
picTest.image = getImage(new URL
(basepath+"testpic.gif"));
}
catch(MalformedURLException ex){}
picTest.setBounds(new Rectangle(10, 10, 50, 50));
this.setLayout(null);
this.add(picTest, null);
}
public class Picture extends Panel
{
public Image image;
public void paint(Graphics g)
{
g.drawImage(image, 0, 0, this);
}
}
}
-------------------------------
EOM
Andrew Thompson - 20 Jun 2005 23:06 GMT
> public class JavaTest extends JApplet
Change to..
public class JavaTest extends java.applet.Applet
...
There are probably other ways to fix this source,
but for those, perhaps you had better ask someone
that you have not just sworn at..
Note: Follow-ups set to c.l.j.gui.

Signature
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.LensEscapes.com/ Images that escape the mundane