wood burning stoves*
The moose likes Swing / AWT / SWT and the fly likes background bleed-through when using getInsets. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "background bleed-through when using getInsets." Watch "background bleed-through when using getInsets." New topic
Author

background bleed-through when using getInsets.

Brett Thomas
Greenhorn

Joined: Aug 25, 2011
Posts: 6
Hi all, I'm new to Java programming, and I'm Eclipse Indigo on a WinXP machine. I'm reading a beginner's book and learning to use the Swing classes. I notice that when I use getInsets on a JFrame subclass that the border region somehow contains the background of my desktop behind it. That border region is not actively transparent because I can drag my frame around on my desktop and the image in the border region does not change - it remains looking like the background of whatever the desktop looked like when the frame first appeared. If I drag another window (say Word) on top of my frame and then move it off the frame, then the border region of the frame is suddenly opaque as expected. Is there anything I can do to stop the border region of my frame from copying in images of the desktop behind it?

Thanks!
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39478
    
  28
Welcome to the Ranch

I shall move this thread to the GUIs forum, where we usually discuss such questions.

Have you tried setting the Frame opaque?
Do you get flickering or anything? If so, have you tried double-buffering (I think you can do that to Panels, not Frames).
Which operating system are you using? The latest version of openSuse which I use tends to have slight transparency of the edges of windows, but I don't get a "memory" of the background carried when I drag a window.
Be prepared to give us more information, particularly if any of those suggestions don't help.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39478
    
  28
I see you are on WinXP. I have never noticed transparency on WinXP myself.
Darryl Burke
Bartender

Joined: May 03, 2008
Posts: 4642
    
    5

Sounds like you're not respecting Swing's single threaded rule. To get better help sooner, post a SSCCE (Short, Self Contained, Compilable and Executable) example that demonstrates the problem.

edit @Campbell: it's not transparency. For whatever reason, some part of the frame isn't being painted at all when first displayed. Dragging a wndow doesn't force a repaint, but covering and exposing it does.

I'd bet that minimizing and restoring the frame would also get rid of the pseudo 'transparency'

luck, db
There are no new questions, but there may be new answers.
Brett Thomas
Greenhorn

Joined: Aug 25, 2011
Posts: 6
Thanks. I attached the actual .Java file taken directly from the book's web site. That exact code causes the psuedo-transparency issue on my WinXP machine. I find it interesting that there are two setVisible(true); statements.

Also, if I put setVisible(false); just before the second setVisible(true); statement, then the issue goes away! Thanks for any thoughts.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18712
    
    8

I'm not seeing any attachment. But that's okay because an attachment is an inferior way of putting code on the site. Just copy it from your source and paste it here in a post... inside the "code" tags which you get by clicking the "Code" button.
Brett Thomas
Greenhorn

Joined: Aug 25, 2011
Posts: 6
Thanks. I'll try pasting the code directly in this post. The transparency issue in the border region gets resolved if I put a setVisible(false) statement right above the setVisible(true) statement that is at the bottom of ColorSliders' constructor method (I'm not sure why there is also one near the top of that same method).

Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39478
    
  28
Is that straight out of the book?
I am not convinced that having the Frame implementing ChangeListener is a good idea, but I may be mistaken.
I am sure, however, that you should never write == true, which is not only poor style, but also nastily error-prone if you mistakenly write = instead of == by mistake. Similarly != true; you should write if (!source.getValueIsAdjusting())...

I had no transparency problems with it on Ubuntu10.10
Brett Thomas
Greenhorn

Joined: Aug 25, 2011
Posts: 6
Thanks Campbell. Yeah, that code was pulled directly off the website for the beginner's book I'm reading. I'm enjoying the book, but I wish the author had commented his code more. Thanks for the tip on == and !=. I'm not sure why I'm getting that transparency issue. For now I'll add a setVisible(false) above a setVisible(true) to get out of it.

I have programmed in VB6 quite a bit, but this is my first foray into OOP. Wow, lots to learn. I do sorta miss how easy it was to click on things in VB6's toolbox and plop them down on a form. Writing code for every button, label and text field feels tedious. And sometimes I forget exactly how the window will look - so I have to run the Java program just to see. In VB6 it looked largely the same in the IDE as it did when run. But I'm sure I'll get used to this difference with time. I do have a couple of quick questions for you if you don't mind:

1. I think I heard that there are some Java IDEs that are a little more graphically oriented like how the VB6 IDE was - i.e. I would be able to drag objects (buttons, labels, etc.) from a toolbox and plop them down where I want them. Is that true? I'm fine with doing everything in code (in Eclipse Indigo) if that's the better way of writing Java programs though.

2. In the code that I submitted I noticed that the author used names like "redLabel" for label objects. But I sorta like calling something like that "labelRed". That is, I like to put the object type first. So I might have things like "buttonHelp" and "buttonSave". But does that go against standard Java naming practices?

Thanks!
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18712
    
    8

There's an ongoing controversy about GUI builders in Java. One faction says that you should start by doing all of that grunt work, so that you learn how things work, and the other faction says that using GUI builders is okay because you don't learn anything from doing the grunt work anyway. Those are caricatures of the arguments of course, but the point is that the experts don't agree. The answer probably depends on your problem domain -- if you're going to be churning out dozens of simple GUIs then use the builder, if you're going to be writing a small number of complex GUIs then write them by hand.

There's also a habit in the VB world of starting your variable names with the type of the variable. I believe it's called Hungarian notation. Anyway that's definitely out of fashion in Java and there are some people who are actively hostile to it. Standard naming practices in Java basically reduce to "Choose meaningful variable names", apart from the convention that you start with a lower-case letter and camel-case the words in the name.

So in your case "redLabel" is a meaningful name, whereas "labelRed" isn't.
Darryl Burke
Bartender

Joined: May 03, 2008
Posts: 4642
    
    5

Remove the setVisible(true) at the 4th line of the constructor (line 17 in your posted code). It has no business being there and is the root cause of the stated problem.

It also explains your observation a setVisible false/true at the end changes anything. setVisible(true) when already visible doesn't do anything.

Also, your book is probably dated. Current Swing programming norms dictate that all Swing components should be constructed and altered only on the EDT. Change your main(...) method to

edit Also, I wouldn't share the same instance of a layout manager between containers.
Darryl Burke
Bartender

Joined: May 03, 2008
Posts: 4642
    
    5

Brett Thomas wrote:I notice that when I use getInsets on a JFrame subclass ...


You're not using (aka invoking, calling) getInsets(), you're overriding the method. Do you know the difference?
Brett Thomas
Greenhorn

Joined: Aug 25, 2011
Posts: 6
Thanks for the replies.

@Darryl, unfortunately that didn't solve the transparency issue. There must be something about my WinXP set up that is causing that. Very strange. I appreciate your alternate main method. The book hasn't taught us yet about threads and "runnable", so maybe the author will change how he does things after he teaches us that. I know (barely) about the concept of "overriding". It was taught earlier in the book. Powerful concept - and I sorta wish the author had put a comment in the code about it. Comments for us beginners really helps solidfy new concepts. Thanks again!





 
Don't get me started about those stupid light bulbs.
 
subject: background bleed-through when using getInsets.