aspose file tools*
The moose likes Swing / AWT / SWT and the fly likes Trying to resolve some odd resizing behavior of objects in GridBagLayout Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Trying to resolve some odd resizing behavior of objects in GridBagLayout" Watch "Trying to resolve some odd resizing behavior of objects in GridBagLayout" New topic
Author

Trying to resolve some odd resizing behavior of objects in GridBagLayout

Jon Swanson
Ranch Hand

Joined: Oct 10, 2011
Posts: 206
I have a GUI that has three components stacked in a GridBagLayout and contained on the right side of a JSplitPane. I found that if I made the right split pane panel smaller, at some point the top component popped to a bigger size. I was seeing this reducing either the width or the height in my GUI. If you run the code below and decrease the window width, once the window is small enough, the components suddenly pop to taller size. If you decrease the window height, once the window is small enough the components pop to a larger size and then the bottom component basically disappears while the top component only gets a little bit smaller. Notice that weighty on the top component is 0.25 and weighty on the bottom component is 0.75, as I want the bottom component to get any extra space. If both weights are 1, then I see 'expected' behavior in the vertical dimension in that both components shrink identically. In the actual GUI, where the components are different objects, setting weighty to 1 for all the components does not help, the top component still pops to a larger size when the vertical height is reduced and the top window doesn't really shrink until the windows below it disappear.

Is there a way to get better behavior on resizing these components?


Rob Camick
Ranch Hand

Joined: Jun 13, 2009
Posts: 2227
    
    8
I have no idea what you are trying to do:

1) first you talk about a split pane, but the posted code has no split pane
2) The nesting of panels is so confusing. It looks like you have 4 levels of nested panels to display a couple of components.
3) I counted 5 levels of nested layout managers. Again I don't understand the need of all these.
4) There is no need to extend a JPanel just to add components to the panel.
5) You reference the comboLabels variable in the lowest level nested panel even though the variable is defined in the top panel.

I can't begin to understand the need for all these levels of nesting, nor can I explain the interaction of all these different layout managers.

The only comment I have is that I believe GridBagLayout respects the minimum size of a component. Maybe you need to fix the minimum size to be the preferred size.
Jon Swanson
Ranch Hand

Joined: Oct 10, 2011
Posts: 206
I could reproduce the problem behavior without the split pane, so I left it out. I was seeing odd behavior in the way that my GUI panels resized when I moved the divider in the split pain. I see the same problem with a similar component just in a frame, that is, the width is reduced and that causes the component to get taller. So I removed everything but one component (including the split pane).

There are a lot of other things left out from the original GUI. For example, there are images behind the component panel. The component panel consists of not one but three smaller components managed by another GridBagLayout, each with an image, each a different width. The nesting was necessary to get the objects in each smaller component to align horizontally with each other. GridBagLayout gives different sizes to combo boxes, labels, text fields and radio buttons. GridLayout makes them all the same size, but I need it inside a GridBagLayout so the components that get created can have their widths different. I'll post a picture.

The actual GUI also passes arguments to the constructors. For example, the lists that will go in the combo boxes. I removed all the parameters as well and just hard-coded some dummy values. I had to define the dummy lists somewhere, but they are only there to allow the example to run, so I guess I didn't pay that much attention to where they went.

Try running the example and just making the width really small. It seems really odd that decreasing the width makes the components suddenly taller.
Jon Swanson
Ranch Hand

Joined: Oct 10, 2011
Posts: 206
Here are images, I hope. Getting a lot of 'you caught us with our pants down' messages.



[Thumbnail for LayoutOfPanels.png]


[Thumbnail for ExampleResizing.png]

Darryl Burke
Bartender

Joined: May 03, 2008
Posts: 4664
    
    5

Notice that weighty on the top component is 0.25 and weighty on the bottom component is 0.75, as I want the bottom component to get any extra space.

If you want the bottom component to get all the extra space, the weighty for the top component should be zero and for the bottom component, any non-zero value.

It's important to remember that weightx and weighty determine how any extra space is distributed after the preferredSizes of the components are catered to.


luck, db
There are no new questions, but there may be new answers.
Jon Swanson
Ranch Hand

Joined: Oct 10, 2011
Posts: 206
Sorry, what I meant to say was I set weighty as 0.25 for the top component and weighty of 0.75 because I wanted the bottom component to get most of the extra space. However, as a result of doing this, when I make the window smaller, the top component (weighty 0.25) gets most of the space and the bottom component (weighty 0.75) shrinks almost to nothing before the top component starts getting smaller. I found this counter-intuitive. In fact the top component actually gets bigger when I shrink the vertical height! If I set weighty of 1 on both, they shrink equally and I don't see the behavior of one component getting bigger (at least on the vertical- still happens on the horizontal). I was hoping there was an explanation/workaround/alternate way to do the sizing that would provide more intuitive behavior on shrinking the window.

Have a look at the example picture. On the far right, the top component (weighty 0.25) has become clearly bigger than the bottom component (weighty 0.75).
Darryl Burke
Bartender

Joined: May 03, 2008
Posts: 4664
    
    5

Post an SSCCE for better help sooner. Just two components in a GBL, that demonstrate the behavior that's troubling you.
Ranganathan Kaliyur Mannar
Bartender

Joined: Oct 16, 2003
Posts: 1096
    
  10

Also, I had earlier warned you against having the gbc variable at a class level and sharing it across in this thread. Try to use 'local' gbc variables as mentioned in the thread, otherwise you will have a hard time keeping track of which component has which constraints associated with it.


Ranga.
SCJP 1.4, OCMJEA/SCEA 5.0.
Darryl Burke
Bartender

Joined: May 03, 2008
Posts: 4664
    
    5

In any case, GBL makes a copy of the passed-in constraints, so you can use the one GBC, setting its fields to appropriate values, for adding all components.
Jon Swanson
Ranch Hand

Joined: Oct 10, 2011
Posts: 206
My real code has one class per file. So the GBC constraints aren't so global as they might appear when I concatenate everything together to post it here. I had been using this sort of paradigm, each file is a graphical component defined something like this:



A lot is left out, but basically the gbc would be shared by a panel that had may be a table with a status bar below it. Or the three pieces of my 'package' panel. Am I understanding correctly that this would be better-



Darryl, I am not sure I understood what you told me. Is it easy to give a short example?
Ranganathan Kaliyur Mannar
Bartender

Joined: Oct 16, 2003
Posts: 1096
    
  10

Darryl Burke wrote:In any case, GBL makes a copy of the passed-in constraints

Oh ok. I was not aware of this.
However, still, we do need to keep track of what we are passing if we share the same variable. For example, I may pass a gbc.fill=BOTH for one component and then when I am using the same variable for another component at a different place, I will have to reset this value to NONE if that was my intention. When we share a variable, we may forget to do this resetting which may lead to undesirable results.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Trying to resolve some odd resizing behavior of objects in GridBagLayout