Get your CodeRanch badge!*
The moose likes Swing / AWT / SWT and the fly likes Weird problem in Windows 7 and Ubuntu 10.10 in a java application Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Weird problem in Windows 7 and Ubuntu 10.10 in a java application" Watch "Weird problem in Windows 7 and Ubuntu 10.10 in a java application" New topic
Author

Weird problem in Windows 7 and Ubuntu 10.10 in a java application

Jeferson Siqueira
Greenhorn

Joined: Feb 08, 2011
Posts: 9

Hi.

I'm dealing with a really weird problem with an project that I've started to work on at work, a kind of a 'Paint' in java; until now, I've just implemented the single lines and rectangles tools.. and it works fine at my Ubuntu 10.10 but, when i try to run the project in windows 7, happens a kind of 'recursion' in my JPanel that shows the draws.. does someone knows why it happens ?,, here comes the screenshot


James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

You have a bug in your code but how can anyone help without seeing the code?


Retired horse trader.
 Note: double-underline links may be advertisements automatically added by this site and are probably not endorsed by me.
Luigi Plinge
Ranch Hand

Joined: Jan 06, 2011
Posts: 441

You need to call super.paintComponent() in your paintComponent() method. It's not a bug - you just haven't coded your method as per guidelines.
James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

Luigi Plinge wrote:You need to call super.paintComponent() in your paintComponent() method. It's not a bug - you just haven't coded your method as per guidelines.


If that is the cause of the problem, and I am not convinced, how is that "not a bug" ?
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36513
    
  16
Welcome to the Ranch, anyway bug or no bug
Luigi Plinge
Ranch Hand

Joined: Jan 06, 2011
Posts: 441

I just meant it's not a bug in Swing, since the behaviour is unspecified if you don't call super.paintComponent().
Jeferson Siqueira
Greenhorn

Joined: Feb 08, 2011
Posts: 9

yes, I'm not calling the super.paintComponent(g); but i guess it's not the cause of the problem; because it runs fine both Ubuntu 10.10 and Windows XP, the problem its just happening in the Windows 7 Ultimate; what is the problem with the seven?
Luigi Plinge
Ranch Hand

Joined: Jan 06, 2011
Posts: 441

There is no problem with Windows 7 - you're just doing it wrong.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19544
    
  16

Jeferson Siqueira wrote:yes, I'm not calling the super.paintComponent(g); but i guess it's not the cause of the problem; because it runs fine both Ubuntu 10.10 and Windows XP, the problem its just happening in the Windows 7 Ultimate; what is the problem with the seven?

I still say it's the absent super.paintComponent. In most cases of painting issues when paintComponent is overridden, an absent super.paintComponent is the reason.

Moving to our GUI forum.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Luigi Plinge
Ranch Hand

Joined: Jan 06, 2011
Posts: 441

If you google "java override paintcomponent" the top result is the Sun documentation which says:

subclasses of Swing components which have a UI delegate (vs. direct subclasses of JComponent), should invoke super.paintComponent() within their paintComponent override
...
If for some reason the component extension does not want to allow the UI delegate to paint (if, for example, it is completely replacing the component's visuals), it may skip calling super.paintComponent(), but it must be responsible for filling in its own background if the opaque property is true, as discussed in the section on the opaque property.
James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

Luigi Plinge wrote:If you google "java override paintcomponent" the top result is the Sun documentation which says:

subclasses of Swing components which have a UI delegate (vs. direct subclasses of JComponent), should invoke super.paintComponent() within their paintComponent override
...
If for some reason the component extension does not want to allow the UI delegate to paint (if, for example, it is completely replacing the component's visuals), it may skip calling super.paintComponent(), but it must be responsible for filling in its own background if the opaque property is true, as discussed in the section on the opaque property.


But this says nothing to indicate that failure to call super.paintComponent() may produce the recursive look experienced by the OP.

I have never had that recursive look. I write cross platform Swing programs which draw in the paintComponent() method and some of them do not call super.paintComponent(); I then paint the background.

Until either you or the OP produce code to show it does I will not be convinced that a failure to call super.paintComponent() can cause the recursive look. Start coding!
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3378
    
    9
It can, but it's only the illusion of a recursive look. The issue is usually caused when you drag a window which has "opaque" components that do not paint all the pixels within their bounds.

When you drag the window, artifacts from the last time the window was painted will remain in the 'unpainted' pixels, giving it the appearance of a window in a window.

In this case it looks like the window was dragged very quickly. However, these artifacts may be caused by other things as well, maybe data remaining in the GPU's memory?

I also suspect the problem is caused by failing to call super.paintComponent(). If this is not the problem, then I would be *very* curious to learn what else it might be.

Waiting for the original poster to post an SSCCE.
Luigi Plinge
Ranch Hand

Joined: Jan 06, 2011
Posts: 441

If you want a short example see my thread http://www.coderanch.com/t/526505/GUI/java/Why-getting-copy-button-JPanel

Stick in a super.paintComponent and it works fine.
Jeferson Siqueira
Greenhorn

Joined: Feb 08, 2011
Posts: 9

oh.
yes, I'm calling the super.paintComponent(g); now, but only once, because i want to keep everything I've already draw in my jpanel, but the weirdest thing, is that, today's morning, the problem was 'apparently' solved, but now, its happening again; I'll post the code of my JPanel and JFrame, that I'm developing using windowBuilder in eclipse





James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

Luigi Plinge wrote:If you want a short example see my thread http://www.coderanch.com/t/526505/GUI/java/Why-getting-copy-button-JPanel

Stick in a super.paintComponent and it works fine.


Running your example in Ubuntu 11.04 with JDK1.6.0_26, Windows XP with JDK1.6.0_26 and Windows 7 with JDK1.6.0_25 (all 32 bit) I don't see this problem. Is it possible that it is a graphics card 'feature'?
Luigi Plinge
Ranch Hand

Joined: Jan 06, 2011
Posts: 441

See Rob Camick's article here for how to keep the contents. Bascially, you have to either re-draw the entire contents, or keep a BufferedImage in memory that you copy in.

James Sabre wrote: Is it possible that it is a graphics card 'feature'?

I don't know. My machine has an nVidia GTX 260 card.

Edit: someone else with the same problem here: http://www.coderanch.com/t/538767/GUI/java/Weird-displaying-issues-between-computers. Looks like Vista there.
James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

Jeferson Siqueira wrote:oh.
yes, I'm calling the super.paintComponent(g); now, but only once, because i want to keep everything I've already draw in my jpanel,


You can't do that. You must completely draw all the lines, shapes etc every that would be inside any corrupted area within the visible rectangle every time the paintComponent() is called. This means that for simple systems it is normally best to draw everything whenever paintComonent() is called.
Jeferson Siqueira
Greenhorn

Joined: Feb 08, 2011
Posts: 9

so, now I'm calling the super.paintComponent(g); but the problem persists, but it just paint the last line that i draw, erasing all the old ones, so, I'm made an boolean variable for it be called only once, but, the problem of the recursive screen persists, even now that i thought that change the JRE the problem could be solved, now i changed the JRE to the 1.6.23, and the problem persisted, but in Ubuntu 10.10, 11.04, windows xp home edition, and professional it worked fine, so now, i bet, that the problem is not with my code, does someone mind what is happening ?
Luigi Plinge
Ranch Hand

Joined: Jan 06, 2011
Posts: 441

Read Rob Camick's article that I linked to a couple of posts above. It deals with your problem exactly.
Jeferson Siqueira
Greenhorn

Joined: Feb 08, 2011
Posts: 9

alright, I'm reading an i will implement a buffered image for my draws, but i was wondering, i the future, in this project, i'm thinking to manage the images by the mouse, as it was at 'Paint' or something, the buffered image solution would get me in trouble, wouldn't be?
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3378
    
    9
Please post your paintComponent method so we can have a look at what you're doing.
Jeferson Siqueira
Greenhorn

Joined: Feb 08, 2011
Posts: 9


Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18136
    
    8

Jeferson Siqueira wrote:so, now I'm calling the super.paintComponent(g)


Not in that code, you aren't.
Jeferson Siqueira
Greenhorn

Joined: Feb 08, 2011
Posts: 9

oh, I'm sorry, the code that was on my computer was different from the other one, so here goes the right;

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Weird problem in Windows 7 and Ubuntu 10.10 in a java application
 
Similar Threads
JMagick 6.4.0 + IBM Websphere v6.1 + Ubuntu 10.10
Ubuntu 10.10 installation Problems
code from the Head-First-Java Book don't run
Ubuntu 10.0 Maverick Meerkat
wsimport with amazon problem