Java Forum / GUI / November 2006
problem with setting a panel size within a frame
Adam Sandler - 28 Nov 2006 15:56 GMT Hello,
I'm trying to make a GUI which looks like this:
|----------------------------| |Please Wait... o O X | |----------------------------| | | | |----------------------| | | | | | <--- centerPanel | |----------------------| | | | |----------------------------|
|____________________________| | | frame
Here's the code:
public class MyFrame extends JFrame { private static final long serialVersionUID = 1L;
public void showFrame() { setTitle( "Please Wait..." ); setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
JPanel centerPanel = new JPanel(); centerPanel.setBorder(BorderFactory.createLoweredBevelBorder()); centerPanel.setSize(new Dimension(50, 25));
Dimension screenDim = Toolkit.getDefaultToolkit().getScreenSize(); Rectangle winRect = getBounds(); setLocation((screenDim.width - winRect.width) / 2,(screenDim.height - winRect.height) / 2);
getContentPane().add(centerPanel); setSize(225, 100); setVisible(true); } }
The problem is that centerPanel is taking on the same dimensions as the frame. I've read in this NG that setPreferredSize can be problematic and my use of "centerPanel.setSize(new Dimension(50, 25));" seems to be either ignored or overridden somehow. How can I size centerPanel to my needs?
I also tried creating another panel without setting the size, putting it in the frame and then putting centerPanel in that other panel. I got the same results.
Suggestions are greatly appreciated!
Thanks.
Michael Dunn - 28 Nov 2006 16:44 GMT > Hello, <snipped>
try this
import java.awt.*; import javax.swing.*; class MyFrame extends JFrame { private static final long serialVersionUID = 1L;
public void showFrame() { setTitle( "Please Wait..." ); setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); setLayout(new GridBagLayout()); JPanel centerPanel = new JPanel(); centerPanel.setBorder(BorderFactory.createLoweredBevelBorder()); //centerPanel.setPreferredSize(new Dimension(50, 25)); centerPanel.setPreferredSize(new Dimension(50, 25)); //Dimension screenDim = //Toolkit.getDefaultToolkit().getScreenSize(); //Rectangle winRect = getBounds(); //setLocation((screenDim.width - winRect.width) / //2,(screenDim.height - winRect.height) / 2);
//getContentPane().add(centerPanel); getContentPane().add(centerPanel,new GridBagConstraints()); setSize(225, 100); setLocationRelativeTo(null);//<----- setVisible(true); } public static void main(String[] args){new MyFrame().showFrame();} }
Adam Sandler - 28 Nov 2006 17:41 GMT > try this Thanks for the reply.
A couple of things... I thought GridBag was going in away in favor FormLayout. Also, with regard to using setPreferredSize, see http://groups.google.com/group/comp.lang.java.gui/browse_thread/thread/199fe8082 5ff337/0e96c1a7ea07b03b
So while your code works (thanks again!), I'm wondering what is the root cause behind why the original code doesn't. If there's some serious issues regarding the use of GridBag and setPreferredSize, then perhaps another solution needs to be sought.
Thanks!
Fred Kleinschmidt - 28 Nov 2006 18:55 GMT >> try this > [quoted text clipped - 10 lines] > > Thanks! The default layout manager for the content pane is a BorderLayout. CENTERed objects will expand/contract as necessary to fill the available space - BorderLayout ignores any positioning or sizing information of its CENTER child.
 Signature Fred L. Kleinschmidt Boeing Associate Technical Fellow Technical Architect, Software Reuse Project
Michael Dunn - 28 Nov 2006 19:35 GMT >> try this > [quoted text clipped - 8 lines] > serious issues regarding the use of GridBag and setPreferredSize, then > perhaps another solution needs to be sought. default layout for contentPane is borderLayout, default placement is CENTER, and default behavior for CENTER is to occupy all remaining space after NORTH,SOUTH,WEST,EAST are set, so getContentPane().add(centerPanel); means centerPanel will occupy all of the size, regardless of its preferredSize
I could have added a panel (holdingPanel) and added centerPanel to that, then added holdingPanel to the contentPane - the effect of this would be that holdingpanel would take up the additional space in CENTER, and centerPanel would get its preferredSize, but centerPanel would appear at the top center - not what you want.
GridBagLayout was used so centerPanel would be 'centered', left/right and top/bottom. The effect would have been the same if holdingPanel was set as a GridBagLayout, and contentPane remained as BorderLayout.
experiment, changing as described above, to see the differences (or no differences)
Adam Sandler - 28 Nov 2006 20:07 GMT > >> try this > > [quoted text clipped - 26 lines] > > experiment, changing as described above, to see the differences (or no differences) Thanks!
Oliver Wong - 28 Nov 2006 20:52 GMT > Also, with regard to using setPreferredSize, see > http://groups.google.com/group/comp.lang.java.gui/browse_thread/thread/199fe8082 5ff337/0e96c1a7ea07b03b I disagree with the claim that setPreferredSize() is evil. IMHO, that method is not incompatible with Layout Managers (whereas something like setSize() is).
- Oliver
Andrew Thompson - 29 Nov 2006 01:47 GMT > > Also, with regard to using setPreferredSize, see > > http://groups.google.com/group/comp.lang.java.gui/browse_thread/thread/199fe8082 5ff337/0e96c1a7ea07b03b > > I disagree with the claim that setPreferredSize() is evil. Babu did qualify that statement directly after that, WTE 'unless absolutely necessary'. AFAIR, the only times I have absolutley needed to set the preferred size of components is when I override paint()/paintComponent().
>...IMHO, that > method is not incompatible with Layout Managers (whereas something like > setSize() is). Yes. But I still think that any case of setting the preferred size, or setting a null layout* should be something that you can argue exactly *why* it needs setPreferredSize().
If you cannot justify it's use, you probably *should* not use it, and instead investigate other possible ways to get what you want - which usually comes back to, 'fix the current layout'.
It seems far too many people approach it the other way around, thinking that setting the preferred size of a component will fix a broken layout.
* Only reason I can think of is 'implementing a custom LayoutManager'.
Andrew T.
Andrew Thompson - 29 Nov 2006 01:55 GMT > Hello, > [quoted text clipped - 14 lines] > | > frame ....
> The problem is that centerPanel is taking on the same dimensions as the > frame. This post is a follow on to my post to Oliver. Please read it first.
In this situation, I would ask.. "So what is going to go *inside* centerPanel, and why is it not logical for centerPanel to be the exact preferredSize of its *contents*?"
As a wider question, is this 'Please Wait' message more suited to a JProgressBar in a floating JDialog or JOptionPane?
Andrew T.
Adam Sandler - 29 Nov 2006 03:44 GMT > This post is a follow on to my post to Oliver. > Please read it first. [quoted text clipped - 9 lines] > > Andrew T. A JProgressBar is very well suited if you have a task where the duration, or the criteria for finishing a task is known. What about those times where the completion of a task isn't so clearly known?
I'm translating a "busybar" from a couple of other languages I work with over to Java. So instead of building a left to right stack of rectangles to the end of the dialog (as in JProgressBar), I have two rectangles that bounce back and forth in "pong"-like fashion until the thread dies. IMHO, this is better feedback for the users than simply waiting on an hourglass cursor (again, only when the length of the task completion is unknown); they see the application is performing an action and they can relate to that. What I have in these other languages is pretty elegant. I grew frustrated with seeing all the hacked flavors of progressbars out there, rife with code smells and bugs, and decided to emulate one instead. It involves drawing two contrasting rectangles (and one the same color as the background to 'erase' tracks) and using some remainder division and a timer to control the scrolling back and forth.
Andrew Thompson - 29 Nov 2006 04:45 GMT ...
> > As a wider question, is this 'Please Wait' message > > more suited to a JProgressBar in a floating > > JDialog or JOptionPane?
> A JProgressBar is very well suited if you have a task where the > duration, or the criteria for finishing a task is known. What about > those times where the completion of a task isn't so clearly known? <http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/JProgressBar.html> "To indicate that a task of unknown length is executing, you can put a progress bar into indeterminate mode."
Did you even attempt to RTFM?
Andrew T.
Adam Sandler - 29 Nov 2006 13:17 GMT > Did you even attempt to RTFM? Thanks for your help thus far.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|