Form with GridLayout: fields shift when data values change

I have seen this before, but it seems more pronounced since upgrading from the 6.6 to 6.7 version. I am running 6.7.1 now.

I created the following YouTube video to show what is happening:

I have a VerticalSplitPanel that contains a Table on top and a Form on bottom. The Form’s layout is a GridLayout, designed to be 100% wide, with most fields inside the grid also set to be 100% wide. The form is setImmediate(true) for the validators to run. It’s a two column grid, each set with an expand ration of 0.5f.

When I change the value in a select box, or enter data in a text field, the form will always shift. I see no “top level errors” via analyze layouts. The original, initial layout seems more or less correct to me, but not sure why it’s shifting when data values are entered.

How might I fix this so the layout holds during data entry? Thanks for any tips!


[/b]No ideas? I noted it also does this also when changing selected rows from the Table that drives the Form. It seems like the Form+GridLayout is recalculating widths based on data values rather than on how the layout specifies widths. Since all my data values are not as wide as the fields they are in, I wouldn’t expect any shifting to take place.

I suspect it’s those columnExpandRatios that work on “excess” space rather than like a

with width 100% and two
each with a width 50%, where the percentages apply to the layout with no real concern for the contents (and only look odd when the TD contents are in fact bigger than can be held).

Hi David, didn’t notice your post earlier, but great video. :wink: We have already considered moving our bug tracking system to Youtube…

The behaviour looks rather erratic, and since there apparently are no layout problems, that could be a bug. I
didn’t see any related existing report
, although GridLayout has had rather a lot resizing problems before. It would be best if you would create a ticket yourself so you can follow its progress more easily.

Of course, if it’s a bug, some minimal example code that isolates the problem would be most welcome.

Okay, I created ticket
. I’ll have to see what it means to create a minimal example, but I have attached our code that does it. It’s not minimal, but it could be novice!

I am seeing this same issue with a GridLayout in a child window.

I am was to get past this by not having any fields with explicit pixel sizes in the GridLayout. The fields that spanned multiple columns are set to 100% width. After doing this, the GridLayout no longer shifts.

Our grid is a simple two column grid, with all fields set to 100% width, never a specific pixel size. We used 0.5f values to the expand ratios for the two columns, but they really work non-intuitively (assign “extra” space rather than just the amount of space for the column). We have a couple of labels with size left as unspecified, but we never set a specific field size other than 100%.

I made a small test/example of using GridLayout in a Form
, but couldn’t see any problem. The problem could be caused by some containing layout or settings for some specific fields in the layout.

I’m a bit worried about that horizontal radio button group. It might mess up with the width calculations of expand rations.

I tried setting the OptionGroup to remove the “inline” feature and it still happened.

I noted our Form is setImmediate(true), but you didn’t do that, but seem to have put it on all fields. I noted that I don’t get the shift on any data value changes in fields that are not immediate, presumably because nothing is sent to the server. So it’s a bit better, but of course I still see it on changes to those fields that are immediate.

I also tried setting our form width to 1000 pixels instead of 100%, but it still shifts.

And I noted you set the field’s width to 100% in the attachField method, not when it’s created. Can that impact anything?

Thanks for trying to figure it out. I’ll post a new video shortly, since I noted it can be even odder! :frowning:

Here’s another youtube video showing how crazy the bug can be:

But, as usual, I didn’t try this on other browsers, and I noted that I don’t see a shift in any other browser, just my Firefox 7.0.1. Could that be it then?

I checked our styles, and we do have one FF7 specific style:
.v-ff7 .v-button-wrap { overflow: visible; }

But that was for icons not appearing in the buttons and getting an ellipsis instead.