dcsimg
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 1 of 5 1234 ... LastLast
Results 1 to 15 of 72

Thread: TIP: Using the GridBag Layout

  1. #1
    Join Date
    Oct 2003
    Location
    .NET2.0 / VS2005 Developer
    Posts
    7,104

    TIP: Using the GridBag Layout

    GridBag Tutorial

    In response to a couple of "yes please"es, I am presenting this post as a basic introduction to using Java's hardest and most confusing layout manager; the gridbag layout. Throughout this article i may refer to it as gridbag, gb, gbl.

    Gridbag is the most powerful and configurable of all the java layout managers. The behaviour of every other layout manager can be mimicked by gridbag, so it's well worth getting to learn.

    Why Use a Layout Manager?
    Lets face it, Layout Managers are a nuisance. Some of us have used visual studio, microsoft's effort at making GUIs easy to build. Or maybe borland delphi. Heck, even Microsoft Access. It's dead simple, you draw your components where you want them and it all looks very nice. Why not just do that in java?

    Well, what happens if you resize the window? Or worse.. what if the user is blind and uses massive fonts?
    The coding necessary to reposition components when a Microsoft Visual Studio GUI resizes, must be put in by the user, and it's a flipping nuisance. Further, it can be a real nuisance trying to get larger fonts in there.
    If you ahve used a Layout Manager then you can be sure that your components will resize properly, and your display will remain usable.

    What are Layout Manager Limitations?
    Well, layout managers only do as they are told, so if you throw together a real messy gui using one, it will always be messy. Further, if you commit any serious style crimes, such as neon pink text on glowing green background, the layout manager wont shoot you for doing so (alas!)



    Tell Me a Bit About Gridbag
    You've used Microsoft Excel, right? It's a spreadsheet.. a grid full of cells, and you can put stuff in those cells. Same goes with gridbag. It draws an imaginary grid of cells ona GUI, and you put stuff in them.

    There's a twist to this particular tale; The size of the cell is largely defined by it's contents. So if you place a JButton in a particular cell, and it is 50 pixels wide by 20 pixels high, then all the cells in that column become 50pixels wide, and all the cells in that row, become 20pixels high.
    If you go and add a JCombobox in the same column, right under the JButton, and that combobox is 100 pixels wide, then your column expands again, to 100 pixels. At this moment in time, your button may do several things, depending on what you ahve programmed. I wont discuss them here, because by the end of the tutorial, youll be able to tell me what that button would have done.

    It is important to note, due to the above flexibility, that the size of the cells in gridbag layout, are not uniform; some are fatter, thinner, taller or shorter, or any combination of that.

    I drew a very simple gui for purposes of demonstration in this tutorial. (I modify it a bit later) Here it is:


    I also drew, in red, the conceptual grid that gridbag placed the components into:


    And this is what they look like overlayed (you never see this when editing a GUI.. your mind has to draw it:





    Behavioural Traits
    So every component that is added to a gridbag influences it in some way.. How do we direct this behaviour?
    By use of constraints. To constrain something, means to limit it in some way. A guy locked up in jail is constrained in terms of his freedom. A colourblind person is constrained in his visual capability; he can still see and drive a car, maybe.. but he wont ever be an electrician in the navy.

    GridBag is constrained too. By default, a gridbag layout has eleven different ways in which a component may behave, and constraints are placed on these behaviours in order to cause the component to behave how you want it. I'll run through all eleven. Here they are in a list (related items are grouped:

    - Anchor
    - Fill
    - GridHeight / GridWidth
    - GridX / GridY
    - Insets
    - IpadX / IpadY
    - WeightX / WeightY

    Thats everything needed to describe how to control a component's behaviour in gridbag.
    I'll discuss each one in turn, so you know what they do, then show a real life GUI and say how it might be made in gridbag.



    Anchor
    I mentioned that a component influences the size of the cell it is in, and hence all the other cells in the row and column. The net result, if you have a situation like I described before, where a wide component is added to a column that already contains a narrow component, is that the column gets bigger.
    There is now some free space for the small component to rattle around in, so anchor tells the component what edge of the cell it should stick to.
    It is essentially like left, right or centre justify for text, only it works for components.
    Anchor has one of 9 values:
    NORTH, NORTHEAST, EAST, SOUTHEAST, SOUTH, SOUTHWEST, WEST, NORTHWEST and CENTER

    Unsurprisingly, if you set the component to stick to the EAST edge of it's cell, then when it is no longer the biggest component in the grid column, youll find it stuck to the lefthand edge of its cell, and centre aligned vertically. For west, the opposite is true. If you want to stick it top or bottom at the same time as left or right, then choose a compound direction, like NORTHEAST (to stick to the top right), SOUTHWEST (to stick to the the bottom left):
    the jButton1 is anchored to the West:


    and now it is anchored to the east:


    demonstrating northwest and southwest, i increased the height of the 2 adjacent textfields to provide some "rattle space" top and bottom. This is northwest:


    and this is southeast:



    Easy huh?

    You should note, that Anchor interacts with Fill, explained next. After reading about Fill, you will probably be able to guess how it cancels out some Anchor settings, but i'll state so anyway.
    Last edited by cjard; January 26th, 2004 at 05:19 PM.

  2. #2
    Join Date
    Oct 2003
    Location
    .NET2.0 / VS2005 Developer
    Posts
    7,104
    Fill

    What if, you didnt want your component to stick to some edge, when the grid column/row got bigger? Suppose you want your component to resize to take advantage of the new rattle space?

    That's what Fill is for.

    It has one of 4 options: None, Horizontal, Vertical, or Both

    A component that does not fill, will stick to wherever it's Anchor tells it to.
    A component that fills horizontally, will resize itself to take advantage of any new space to the left and right, but will stick to where it's anchor tells it, if any new vertical space becomes available

    Similarly, filling vertical, causes it to grow and shrink in height, according to any new space that comes available
    And filling both, causes it to grow and shrink in all directions

    There is a knock-on effect for the Anchor here; filling makes anchoring useless in one or more directions. If you fill horizontally, then it doesnt matter if your component is anchored EAST, CENTER or WEST; you wont see any difference. Similarly, filling vertically cancels any effects that anchoring NORTH, CENTER or SOUTH has, and if you fill both directions, it doesnt matter what edge of the cell you anchor (stick) your component to; it will always fill the entire cell.
    Note for aligned components: Some components are internally aligned anyway. Like a label, may have its text on the left, centre or right. The anchor has absolutely no bearing on this. If you left-justify the text in a label, then set it to fill BOTH and anchor it to SOUTH EAST, the text will always be stuck to the western (left) edge of the component.. So watch out for that. Anchored when Filled, anchors the whole component after it has been resized (thanks to Fill), not before!

    Some Fills. Look at the jButton1. All are anchored in the centre:

    Vertical:


    Horizontal:


    None:


    Both:
    Last edited by cjard; January 26th, 2004 at 05:20 PM.

  3. #3
    Join Date
    Oct 2003
    Location
    .NET2.0 / VS2005 Developer
    Posts
    7,104
    Grid Width/Grid Height

    This factor has nothing to do with the actual size of the component, although it MAY affect the appearance of the component to the extent that the component changes size. Confused? I'll explain a little more:

    In HTML or Excel, you can have a table(or grid) where some cells of the table, span more than one row or column. So we get something like this (made in excel using the merge cells function):



    Gridheight and gridwidth settings are like that. If you set your gridheight to 2, then that cell that the component is in, has its top aligned with the top of the cells to it's left and right, but the bottom is aligned with the bottom of the next cell down in the grid. (It spans 2 rows)
    Watch the jButton1 as i change it's gridheight. In the following example, the textfields on the left and right, are all gridheight 1. I set the fill attribute to vertical, that will cause the button to fill all the available space vertically. Then, when I change the gridheight from 1, to 2 and then 3, you will see the button grow!





    Please note here, and it is very important, that im NOT changing the size of the component itself (that is later) - I am changing the size of the grid CELL, and because the component has been told to FILL its cell, it gets bigger too (you cant see cells directly, so i had to do it that way)
    If the component had not been told to fill its cell, then it would have obeyed its anchor, and stuck to somewhere, which wouldnt have shown what i wanted.

    So what use is this? Well, sometimes you might want to have one component that is wider than others. Taking an example that you probably know; if you look at your web browser, the address bar runs the full width of the top bit, but above it are buttons. if you were going to give each of those buttons it's own cell, then you would want the address bar to span all those cells.

    I probably dont need to explain gridwidth much now, having just given an example; the address bar has a gridwidth of more than 1. If there was 10 buttons, then the address bar would have a gridwidth of 10, to span them all..

    There is a special property of gridwidth and height however. Instead of giving it a hard value, you can declare it to have the REMAINDER. This is a special attribute, that tells the layout manager to "find out how many cells there are left in this row/column and span them all!"
    How is it useful? Well, if your GUI changes during runtime.. i.e. in your web browser example, what happens if you add 10 more buttons, while the program is running?
    Your address bar that spanned them all at the start, will end up stopping halfway along. That's just not good! If you told gridbag that the address bar was to have the REMAINDER of the cells to span across, then no matter how many buttons you add, even 100, the gridbag will look and see "there is now 100 cells across, in this grid, i'll make that address bar span to be 100".. so always, the address bar will span the remainder of the cells.

    Note; you shouldnt use a HEIGHT remainder more than once per column, or a WIDTH remainder more than once per row.. The layout manager might get confused if you put 2 components on a row and tell the gridbag that they are both allowed the REMAINDER of the space.. it might split it 50/50, but it is NOT good practice!

    Note2; there is another protperty for height/width, and that is relative. I dont discuss it because i dont believe it to be particularly useful; if you make the gridheight relatve, it gives the component the same height as the component you last added.. if one changes, the other changes. This can lead to some serious confusion (in your mind), and i dont recommend you use it; i've never needed to.
    Last edited by cjard; January 26th, 2004 at 05:22 PM.

  4. #4
    Join Date
    Oct 2003
    Location
    .NET2.0 / VS2005 Developer
    Posts
    7,104
    Grid X/Grid Y

    Easy one! It's simple coordinates of where this component is to appear on the grid, like an X and Y game of battleships, or a Cell in Microsoft Excel.. In excel the first cell is A1. In gridbag, the first cell can be ANYTHING, because it determines on the number you use. If you wanna use gridx = 1, gridy = 1 that's fine. You could also use 0,0.. -37,-25, 141,2045.. but it is best to start off with either 1,1 or 0,0; whichever makes you happy

    The grid is numbered in the same way that your screen is drawn, or in the same way that an english person would write a letter; left to right, then top to bottom. when i talk about my gridx and gridY as coordinates (1,1).. it is in this order: (gridX,gridY)..

    so this is what you'd have (invisible grid):
    Code:
     ____________________________
    |  1,1   |   2,1   |   3,1   |
    |________|_________|_________|
    |  1,2   |   2,2   |   3,2   |
    |________|_________|_________|
    |  1,3   |   2,3   |   3,3   |
    |________|_________|_________|
    TIP:
    gridbag CAN cope with empty rows, it just squashes them down to NOTHING, so if you wanted to multiply your indexes by 10, it WONT affect your gui at all:
    Code:
     ____________________________
    | 10,10  |  20,10  |  30,10  |
    |________|_________|_________|
    | 10,20  |  20,20  |  30,20  |
    | _______|_________|_________|
    | 10,30  |  20,30  |  30,30  |
    |________|_________|_________|
    Why would you do this? Well, it can make things real easy if you sit and this "oh shoot, i forgot to put a textfield right in the middle there..."
    - you can just give the textfield an index of, say 20,21 and this is what it will look like (back to nice pictures! ascii art is tedious!):



    there, i put that textfield in at 20,21. Initially it was squashed up by it's brothers so there were a couple of other changes to make (to the weight, explained later)
    I put another one in at 11,21 and that guy jacked the whole grid out a bit to make room for himself
    If i hadnt bothered multiplying all the indexes by 10, then i woulda had to re-number quite a few cells to get it looking like that.. so once youre familiar with gridX and gridY using 1,2,3,4,5 .. try using 10,20,30 instead.. that way you can add up to 9 components that you forgot, without having to re-number stuff

    Here, i can reinforce a point i made earlier.. that new one i added at 20,21.. suppose i made his gridheight to be REMAINDER, then gridbag would have calculated "well, the grid is 30 cells high, he's rooted at Y position 20, so i'll make him take up the remainder of the space, that's an effective gridheight of 10".
    If i then set fill to be both horizontal and vertical you woulda seen this:



    Okay, nothing much special, but now, I wont touch that guy 20,21 AT ALL, but i will now add the 11,21 guy into the grid.
    For good measure, i'll also move the 10,10 guy to position 0,41.
    He should go and force the grid both wider and higher
    Why?
    Before, the grid went from 10 on the X axis to 30, on the X axis. It also went from 10 on the Y to 30 on the Y. Now it will start from 0 on the X, and run to 30. The Y axis will run from 10 to 41.
    This means the actual height of our grid is no longer 30-10 = 20.
    It is now 41-0=41.


    Watch what the REMAINDER setting causes:



    Yup.. the remainder is adjusted so that cell spans all the rows down to 41. Note i didnt have to touch that cell at 21,20 at all. The layout manager just altered his height for me. It will do this for you during design or during running.

    Note; just because you multiple your gridX and gridY by 10 DOES NOT mean you need to do the same to your gridwidth/gridheight.. you can leave those at 1, and gridbag will simply squash the remaining 9 rows/columns down into nothing, because they are empty! Making your gridheight/width multiplied by 10 would totally kill any benefits of making all the X and Y multiplied by 10, because you wouldnt be able to easily add something!


    So that's height and width (span) and x and y (position) covered. Next i'm going to talk about...
    Last edited by cjard; January 26th, 2004 at 05:25 PM.

  5. #5
    Join Date
    Oct 2003
    Location
    .NET2.0 / VS2005 Developer
    Posts
    7,104
    Insets

    There are some times that things just dont look good when fitted to a grid. Maybe you put a jlabel and a jtextfield next to each other, and you noticed that the text inside the jlabel and the text inside the jtextfield, just dont line up.
    Nuisance, especially since our GUI is built on a grid.

    No worries though, because that's what insets are for.

    Before you start playing with insets, be SURE that your problems of misalignment arent caused by soemthing else.. you know, if your gridheight is set up wrongly or something. Or, maybe you used a component on a row, like a jbutton, that has a higher natural height than something like a jtextfield. That kind of problem can be seen here:



    see that the jbutton is forcing the row a bit higher, so there's a gap in the nice flow of the jtextfields.
    Try and avoid this if you can, by avoiding making this kind of GUI. Be sensitive to the natural heights of components.. jButton/jcombobox is probably the biggest one, naturally.. (though you can squash him down if necessary)

    Right, so.. about Insets.

    You know that gridbag works on this invisible grid, and the component, (button, textfield) floats round inside the grid cell?
    Well.. insets allows you to add some "dead space" to a cell. The component isnt allowed to go in that dead space, but putting it in will force the cell to grow, as it now has to hold the component and the dead space.

    You can add dead space to the top, right, bottom and left independently, so if you wanna put some distance between a textfield and it's neighbours left and right, but you want it touching its top and bottom neighbours, then you can use insets.

    Insets is actually a java object, a special container for four integers, that tell gridbag how much pixels of dead space to add to the TOP, LEFT, BOTTOM, RIGHT respectively. If you cant remember the order.. think in a counter-clockwise circle, starting at the top)

    So an insets of 10,0,0,0 adds 10 pixels of deadspace to the top of this component's cell. Remember that the component cant go into the deadspace, but it will force the entire row higher. In the following pictures i draw a simple three-by-three grid of textfields. For the middle text field i will add insets of 10 (to the top), then also 20 to the left, then also 30 to the bottom, and finally also 40 to the right, so you can see how they work independently:



    Eek! what happened? Well, look at the middle one, theres a chunk of grey space above the top of the textfield. That, combined with the height of the textfield (about 20 pixels) has force the row up to about 30 pixels high. The neighbouring cells to the left and right are affected. i have NOT told them to fill, so they are instead, obeying their Anchor. Because they anchor in the centre, they appear out of line with the deadspaced cell (20,20).. but they are anchoring in the center; each cell has grown to 30 pixels high, and the components inside, being 20 pixels high and not allowed to fill, are instead floating vertically centre-justified.
    It will get worse looking:






    So what's happened? Thanks to 10+30 top and botton, plus 20 from the component, the cell is now 60 high
    It is also 20+40+ (whoknows?) however wide... the other cells have stuck to their anchors, and the middle cell now looks seriously out of place. I've highlighted the insets in different colours, as to where they are CONCEPTUALLY. There isnt actually anything there.. it just behaves like there was:



    Insets are always placed between the edge of the component and the edge of the cell it exists in. If a component's cell is spanning rows or columns, with the gridheight/gridwidth, then the insets are placed between the component and the edge of the spanned cell, not at the edge of every cell along the way.

    So thats how we push stuff round using insets, but caution to the wise! Insets alter the height of the row or column (depending on where they are) so they CAN upset things even more! :)

    Basic summary of insets: They alter the size of a component WITHOUT altering it's appearance.
    Last edited by cjard; January 26th, 2004 at 05:27 PM.

  6. #6
    Join Date
    Oct 2003
    Location
    .NET2.0 / VS2005 Developer
    Posts
    7,104
    IpadX/IPadY or "Internal Padding"

    This is very similar to insets with a very simple difference; they alter the size of a component AND alter its appearance.
    Insets put some dead space in there, causing the component to get bigger by using something you couldnt see. Internal Padding simply makes the component bigger. You can fake the effect by altering the Preferred Size of the component.

    If you have a textfield that is 100 pixels wide, and you add 10 Internal Padding X to it, then it will acquire 5 extra pixels on the left and 5 extra pixels on the right. Overall the textfield will grow so that it appears 10 pixels longer overall; so this is stuff you can see!

    Here is a grid of textfields. They are all of preferred size 60 wide.



    I'll add 10 ipadx to the centre one:



    The component is literally now just5 pixels fatter on either side. I'll make the one underneath it have a preferred size of 70 (60 original pixels +10 ipadx equivalent):



    Yes, they look exactly the same. There is ONE critical difference however:
    internal padding is always added to a component no matter what it's state. A component in any layout is in one of 2 states: normal or crushed. If you resize a GUI down so much that the component cannot exist at it's preferred size, it instantly collapses to it's minimum size.
    Whether in crushed or normal mode, the component has a basic size (when crushed, it is the stated minimum size.. when normal, it is at least the stated preferred size). To this basic size, is added the internal padding. This means that a component with internal padding of 10, preferred size of 100 and minumum size of 20, will appear to be 110 pixels when normal, and 30 pixels when crushed. The following diagram illustrates:



    Look at the highlighted column of textfields.
    The upper one has a preferred size of 60,20, minimum size of 14,20. No ipadx.
    The middle one has a preferred size of 60,20, minimum size of 4,20. 10 ipadx.
    The bottom one has a preferred size of 70,20, minimum size of 4,20. No ipadx.

    We see that when Normal, the ipdax on the middle one contributes 10 pixels to the preferred size of 60. It appears the same as the lower one, who has a preferred size of 70.
    When crushed, the situation reverses; the middle one now looks the same as the top one, because it again has an ipadx of 10, which contributes to the 4 pixels minimum size, making it look the same as the top most one, who has a minimum size of 14.

    So setting ipadx has effects on BOTH the preferred size and minimum size; ideally it is nice to crush your GUIs gracefully, so you might want to make more use of minimum and preferred sizes than internal padding


    Note; the api documentation is quite wrong about IPadX and IPadY. It states that the IPadX or IPadY number of pixels are added to the left and right of the component. Plugging some numbers in, the documentation infers that a 60 pixel wide textarea, will have 10 pixels added to both left and right (if ipadx is 10), becoming 80 pixels..
    Youve seen here that this isnt the case, and that the component becomes just 70 pixels wide, so ignore the API's claim that "The width of the component is at least its minimum width plus (ipadx * 2) pixels."

    It should read: "The width of the component is at least its chosen width plus ipadx pixels. The component's chosen width depends on whether it can fit into the available space. Components that cannot exist at at least their preferred width, shrink to their minimum width. Components that CAN exist at at least their minimum width may appear larger due to resizing by the layout manager"




    WeightX/Y

    Final section! Weight is perhaps the most important factor in resizing operations. It tells the layout manager how much to change the size of each component, when more space becomes available.

    Ill deal with it simplistically first:
    Imagine you have 2 brothers, and you have to stand in a line in a room, between the walls. You fight with your brothers over how much space you have on either side of you and eventually reach a happy state where each feels he has the space he can deservedly win.

    Now, if you all punch equally hard, youre gonna end up with the space shared into equal thirds. If the middle brother can punch twice as hard as the other 2, then he is going to end up with some bigger amount of space, because he can more effectively knock back anyone who tries to come into it.
    How much space will he end up with? well, if his punches are worth 2, and the other two brothers are worth 1 each, that's a total of 4, and the middle brother gets 2/4, or half the space, leaving the other two brothers with 1/4 each.

    Weight is just like this; the components compete for space, and the components that weigh more get more than an equal share. The formula is the same; gridbag layout looks at all the rows, and finds the highest weight value in each column. That then becomes the column weight. The columns weights are added up to give a grand total, then space is doled out according to the percentage of the grand total, that each column has.
    Same for vertical height (all the rows are scanned to find the highest WeightY on that row, then the highests are added, and vertical space is doled out according to that row's percentage of the total)

    Before i begin with the examples, theres one further thing to say about weight:
    All components start off at their preferred size, then the remaining free space is calculated and handed out according to the weighted percentages. It doesnt start from zero size, so if you have 3 identical textboxes on a row, two are weight 1.0, and the other is weight 5.0, then the 5.0 one WONT appear to be 5 times larger than either of the other 2.. They all started out the same preferred size, of, say 50 pixels. That means the window is 150 pixels wide. If the user resizes it to 850 pixels wide, then there is an extra 700 pixels of space. Here is where the weights come in. The weights are 5.0, 1.0 and 1.0. That's a total of 7, for 700 pixels of space (yeah, i rigged it). The heavy guy, gets 5.0/7.0 of the space.. that's 500 pixels. The other 2 get 100 pixels each!
    So the new sizes of our components are 50+500, 50+100, 50+100. In other words 550, 150, 150.. Now, 550 isnt five times bigger than 150.. so you need to see that it's the extra space that gets shared, not the total space!
    (If it was the total space, then the heavy guy would get 5/7ths of the 850 total.. about 607 pixels.. not so!)

    Confusing? It may be at first, but basically, its the only real way it can work to ensure that components with a weight of 0 dont just suddenly disappear.

    Heres some pictures.. Before the resize:

    Despite their different weights, they all appear the same size. This is because they are all at their preferred size of 60 pixels each. When we resize, a difference will appear.

    And after:


    I resized it to about double, but i've put some colouring in the boxes to highlight [sic] my point..
    All the blank text fields have a weightx of 0.0. This shows that it is only the highest weightx in any particular column that counts..

    The yellow highlight shows the preferred size of the component; remember this space is not a part of the calculation when the layout manager is carving up the extra space that the resize created.

    The blue highlight is the extra space that the resize generated. I split it up so you can see:
    the guy with weightx 2.0 got 2 blocks of blue
    the guy with weightx 1.0 got 1 block of blue

    there was a total number of new pixels X.. this was divided by 3, (weightx grand total of 0 + 2 + 1) then handed out in proprtion 2/3, 1/3.
    I COULD have written 0.0, 0.66 and 0.33 for the weightX and it would look the same.. it's the ratios that count, not the actual numbers.
    Some people may tell you that all weightx on a row need to add up to 1.0; not true.

    So, you see how the space is handed out, only after a resize


    Note; As mentioned before, when I said that only the largest weightx in any particular column counts (same applies for weighty in a row), you CANT make components different sizes within a column by giving them different weightx values.. it's all or nothing!


    ------
    The End.. sorta...
    Last edited by cjard; January 26th, 2004 at 05:31 PM.

  7. #7
    Join Date
    Oct 2003
    Location
    .NET2.0 / VS2005 Developer
    Posts
    7,104
    Right, ive taught you the basic idea behind it all, but is it actually helpful? Hmm, maybe not, so i'll show a few real world examples. Everyone using microsoft, has the Device Manager. I took a picture on it and doodled over it. It is how you MIGHT choose to make it, in gridbag java:



    Ive left out any boring values; if a value wasnt changed from its default, or had been mentioned before, typically, i left it out.

    The invisible grid is marked out in pink
    The cell edges are marked out in blue rectangles. a component itself may or may not fill all of the blue rectangle, and the blue rectangle represents the components "living space" after spanning any necessary rows/columns

    The JTree,with a weightY of 1, does all the vertical expanding

    The pale yellow grid column is actually the column that will do all the horizontal expanding; All the other columns (that do not participate in a span) contain only components that are weighted at 0. The final 2 columns will remain that width because the bottom jlabels are weightx = 0, the first 3 columns will also remain their drawn width thanks to the top buttons being weightx = 0. When a resize occurs, the yellow shaded column grows, and the components that have a weightX of 1.0 appear larger (the jtree and lower left jlabel.
    The button at the top, that has a weightX of 1.0 will not appear larger, because it has no fill, and is anchored to the west.. so the blue box denoting the size of the cell will change, but the component appearance will stay, as it may not fill its cell, nor leave the west edge that it is stuck to.

    If there are any questions, shoot!
    Last edited by cjard; January 26th, 2004 at 05:35 PM.
    "it's a fax from your dog, Mr Dansworth. It looks like your cat" - Gary Larson...DW1: Data Walkthroughs 1.1...DW2: Data Walkthroughs 2.0...DDS: The DataSet Designer Surface...ANO: ADO.NET2 Orientation...DAN: Deeper ADO.NET...DNU...PQ

  8. #8
    Join Date
    Nov 2002
    Location
    Brazil
    Posts
    181
    What if the first three JButtons had weightx = 1.0 too? Would their grid cells all take the same space as the fourth one, with the only difference being that the latter had gridwidth = REMAINDER, and therefore was the last on their row?

    Nice tutorial! Thanks for your effort!
    Last edited by Magus; January 26th, 2004 at 07:59 PM.

  9. #9
    cjard, that was awsome! Now I have no excuse for not playing around with gbl and making my GUIs do what I want it to. If you keep making tutorials like this you might have to find yourself a publisher and get a book printed.
    Note: I am a novice, take anything I say as coming from such.

  10. #10
    Join Date
    Oct 2003
    Location
    .NET2.0 / VS2005 Developer
    Posts
    7,104
    Originally posted by Magus
    What if the first three JButtons had weightx = 1.0 too? Would their grid cells all take the same space as the fourth one, with the only difference being that the latter had gridwidth = REMAINDER, and therefore was the last on their row?

    Nice tutorial! Thanks for your effort!
    If the first three buttons had a weightx of 1 also, then initially the gui would look something similar to my picture.. doubling the size of it would cause the cells holding the first three buttons to grow too.. All buttons would grow by the same amount

    Remember, that GRIDWIDTH is like a span.. the final cell on the row (that holds the fourth button) is maybe 300 pixels wide, and for sake of arguemnt, lets say that the first three cells are 40 pixels wide, at their minimal (mostly tightly packed possible, without causing a crush) size.

    If 400 pixels of new space becomes available (because the user resizes the window to be 400 pixels wider (total width 820) than its current of 40+40+40+300 =420)
    Then the weight will cause each button to grow by 100 pixels

    so the first three that are 40 pixels wide, will become 140 pixels wide, and the final one, will become 400 (was 300, +100) pixels wide:


    ## ## ## ###############
    becomes:
    ##@@@@@ ##@@@@@ ##@@@@@ ###############@@@@@


    ive used # to represent the original size, and the @ to represent the new added 100 pixels. either an # or an @ is "worth" 20 pixels"

    so you see how they grow? remember that gridwidth and weightx do separate things, gridwidth defines how many real gridcells this component spans over, and weightx defines what percentage of any new space the component actually gets. gridbag itself is internally responsible for working out which columns are actually allowed to resize, but you should be aware of it (like the pale yellow column) if you are aligning things with certain edges..
    "it's a fax from your dog, Mr Dansworth. It looks like your cat" - Gary Larson...DW1: Data Walkthroughs 1.1...DW2: Data Walkthroughs 2.0...DDS: The DataSet Designer Surface...ANO: ADO.NET2 Orientation...DAN: Deeper ADO.NET...DNU...PQ

  11. #11
    Join Date
    Oct 2003
    Location
    .NET2.0 / VS2005 Developer
    Posts
    7,104
    Originally posted by Barancle
    If you keep making tutorials like this you might have to find yourself a publisher and get a book printed.
    I'd need to spend a few more hours re-proof reading and altering the language style a little.. sometimes, when a person writes, they get so involved with what they write, they forget how to make it makes sense..

    when my brain has cooled down in a few days, and i have a bit of time, i will re-read and re-write sections of this tut, because I know there are some typos and some of it is a little hard to understand.. sentences need making shorter, etc

    now, i gotta go... field call-out
    "it's a fax from your dog, Mr Dansworth. It looks like your cat" - Gary Larson...DW1: Data Walkthroughs 1.1...DW2: Data Walkthroughs 2.0...DDS: The DataSet Designer Surface...ANO: ADO.NET2 Orientation...DAN: Deeper ADO.NET...DNU...PQ

  12. #12
    Join Date
    Apr 2001
    Location
    South Africa, Jo'burg
    Posts
    680
    Very nice cjard, thanks for the time you've put into this, I will definitely take the time to read again and will definitely take a lot from it!!!

    Thanks
    Byron

  13. #13
    Join Date
    Dec 2003
    Location
    Colchester, England
    Posts
    619
    This tutorial is just what i needed. I have a group project running at the minute, and we were given an example solution to a similar problem that the lecturer had written (it was a library catalogue) but the GUI for his solution was very ugly. I know that all that was really important to us was the internal code so we could get an idea of how to program our solutions, but I was hoping to make our GUI a little more usable. Thanks for taking the time to write this

  14. #14
    Join Date
    Oct 2003
    Location
    .NET2.0 / VS2005 Developer
    Posts
    7,104
    I find that using an IDE is the best way to actually make the GUI.. Sun ONE Studio 4 CE is my choice, though there are others.. I'd advise using one to create the form, simply because it can be quite a long process if youre using a text editor, of getting all the constraints right.. if they are wrong, your components often end up stacked on top of each other, with no easy indication of what went wrong..

    http://java.sun.com/j2se/1.4.1/downl...dk-s1studio_ce
    "it's a fax from your dog, Mr Dansworth. It looks like your cat" - Gary Larson...DW1: Data Walkthroughs 1.1...DW2: Data Walkthroughs 2.0...DDS: The DataSet Designer Surface...ANO: ADO.NET2 Orientation...DAN: Deeper ADO.NET...DNU...PQ

  15. #15
    Join Date
    Dec 2003
    Location
    Colchester, England
    Posts
    619
    It will all depend on what software is on the university computers. We've been advised to use Intelij, and Together is also available. (I assume these are similar programs to the one you're talking about?).

Page 1 of 5 1234 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width




On-Demand Webinars (sponsored)