PDA

View Full Version : resizing of window with VerticalLayoutData doesn't occur until mouseover of window



nbuesing
8 Feb 2012, 10:41 AM
This has taking a while to reproduce, since it seems a variety of things must be in alignment. Under this scenario if you resize the browser window the table will NOT resize until the cursor goes over the window (delay resize until a mouse event occurs).Scenario where resizing is deferred until mouseover.VerticalLayoutData of 1, -1 is provided (so widget is controlled by container, height is that of widget)
Viewport vp = new Viewport();VerticalLayoutContainer container = new VerticalLayoutContainer();vp.setWidget(container);container.add(this.asWidget(), new VerticalLayoutData(1, -1, new Margins(10)));RootPanel.get().add(vp);Scenario where resizing works at time of resize (no mouseover needed).VerticalLayoutData of 1, 1 is provided (so width and height is controlled by container)
Viewport vp = new Viewport();VerticalLayoutContainer container = new VerticalLayoutContainer();vp.setWidget(container);container.add(this.asWidget(), new VerticalLayoutData(1, 1, new Margins(10)));RootPanel.get().add(vp);Patch file is included to demonstrate behavior with your examples.Uses GroupingGridExample and also updates Explorer.gwt.xml modified to make GroupingGridExample the entry point.31498
Index: src/main/java/com/sencha/gxt/explorer/Explorer.gwt.xml===================================================================--- src/main/java/com/sencha/gxt/explorer/Explorer.gwt.xml (revision 2134)+++ src/main/java/com/sencha/gxt/explorer/Explorer.gwt.xml (working copy)@@ -12,7 +12,7 @@ - + @@ -31,5 +31,6 @@ - + + Index: src/main/java/com/sencha/gxt/explorer/client/grid/GroupingGridExample.java===================================================================--- src/main/java/com/sencha/gxt/explorer/client/grid/GroupingGridExample.java (revision 2134)+++ src/main/java/com/sencha/gxt/explorer/client/grid/GroupingGridExample.java (working copy)@@ -14,6 +14,7 @@ import com.google.gwt.user.client.ui.RootPanel; import com.google.gwt.user.client.ui.Widget; import com.sencha.gxt.core.client.ValueProvider;+import com.sencha.gxt.core.client.util.Margins; import com.sencha.gxt.data.shared.ListStore; import com.sencha.gxt.data.shared.ModelKeyProvider; import com.sencha.gxt.data.shared.PropertyAccess;@@ -21,12 +22,15 @@ import com.sencha.gxt.examples.resources.client.model.Stock; import com.sencha.gxt.explorer.client.model.Example.Detail; import com.sencha.gxt.widget.core.client.ContentPanel;+import com.sencha.gxt.widget.core.client.container.VerticalLayoutContainer;+import com.sencha.gxt.widget.core.client.container.VerticalLayoutContainer.VerticalLayoutData;+import com.sencha.gxt.widget.core.client.container.Viewport; import com.sencha.gxt.widget.core.client.grid.ColumnConfig; import com.sencha.gxt.widget.core.client.grid.ColumnModel; import com.sencha.gxt.widget.core.client.grid.Grid; import com.sencha.gxt.widget.core.client.grid.GroupingView; -@Detail(name = "Grouping Grid", icon = "grouping", category = "Grid", classes = {Stock.class})+@Detail(name = "Grouping Grid", icon = "grouping", category = "Grid", classes = {Stock.class}, fit=true) public class GroupingGridExample implements EntryPoint, IsWidget { interface StockProperties extends PropertyAccess {@@ -75,7 +79,7 @@ final GroupingView view = new GroupingView(); view.setShowGroupedColumn(false);- view.setForceFit(true);+ //view.setForceFit(true); Grid grid = new Grid(store, cm); grid.setView(view);@@ -97,7 +101,15 @@ @Override public void onModuleLoad() {- RootPanel.get().add(this);+ Viewport vp = new Viewport();+ VerticalLayoutContainer container = new VerticalLayoutContainer();+ vp.setWidget(container);+ + container.add(this.asWidget(), new VerticalLayoutData(1, -1, new Margins(10)));+ //Resizing works if height is set to -1 so it expands to the entire window.+ //container.add(this.asWidget(), new VerticalLayoutData(1, 1, new Margins(10)));+ + RootPanel.get().add(vp); } }

nbuesing
8 Feb 2012, 12:42 PM
In looking at VerticalLayoutContainer.doLayout, I can see why there is a difference now due to the height value. If the height == -1, it does this "scheduleEntry" and returns.

Fix #1, remove 'return statement from the shown code. I doubt this is the correct solution, but my child widget does get resized as expected.

Fix #2, change scheduleEntry to scheduleDeffered. Again, not sure that is the "correct" fix.



if (height > 1) {
ph -= height;
} else if (height == -1) {
if ((c instanceof HasWidgets || c instanceof IndexedPanel) && !secondPassRequired) {
secondPassRequired = true;
Scheduler.get().scheduleEntry(forceLayoutCommand);
return;
}



Please let me know if either solution is acceptable, I would like to fix our code until the next beta is released (and hopefully with a fix for this).

Thanks.

sven
8 Feb 2012, 2:55 PM
Can you please provide the code in a formated way? There are no newlines in there or anything.

This is probably an already known issue which is already on the list, just to be sure.

nbuesing
8 Feb 2012, 3:51 PM
I created the post the same was as my previous post, but this time I did "preview post" before submitting. It seems that preview post messes up newlines when you post from that. When I am back in the office, I will resubmit the patch.

Someone should look into the forum software to see why a post after preview causes the newlines to go away (at least that is what happened for me here).

sven
9 Feb 2012, 2:32 AM
That would be great. Thank you.

nbuesing
9 Feb 2012, 5:10 AM
Resubmitted patch, thanks.



Index: com.sencha.gxt.examples/src/main/java/com/sencha/gxt/explorer/Explorer.gwt.xml
===================================================================
--- com.sencha.gxt.examples/src/main/java/com/sencha/gxt/explorer/Explorer.gwt.xml (revision 2134)
+++ com.sencha.gxt.examples/src/main/java/com/sencha/gxt/explorer/Explorer.gwt.xml (working copy)
@@ -12,7 +12,7 @@

<!-- <set-property name="gxt.logging.enabled" value="true" /> -->

- <inherits name="com.sencha.gwt.uibinder.UiBinder" />
+ <!-- <inherits name="com.sencha.gwt.uibinder.UiBinder" /> -->

<!-- Specify the paths for translatable code -->
<source path='client' />
@@ -31,5 +31,6 @@

<set-configuration-property name="GXT.state.autoBeanFactory" value="com.sencha.gxt.explorer.client.misc.WindowStateExample.ExampleAutoBeanFactory" />

- <entry-point class='com.sencha.gxt.explorer.client.Explorer' />
+ <!-- <entry-point class='com.sencha.gxt.explorer.client.Explorer' /> -->
+ <entry-point class='com.sencha.gxt.explorer.client.grid.GroupingGridExample'/>
</module>
Index: com.sencha.gxt.examples/src/main/java/com/sencha/gxt/explorer/client/grid/GroupingGridExample.java
===================================================================
--- com.sencha.gxt.examples/src/main/java/com/sencha/gxt/explorer/client/grid/GroupingGridExample.java (revision 2134)
+++ com.sencha.gxt.examples/src/main/java/com/sencha/gxt/explorer/client/grid/GroupingGridExample.java (working copy)
@@ -14,6 +14,7 @@
import com.google.gwt.user.client.ui.RootPanel;
import com.google.gwt.user.client.ui.Widget;
import com.sencha.gxt.core.client.ValueProvider;
+import com.sencha.gxt.core.client.util.Margins;
import com.sencha.gxt.data.shared.ListStore;
import com.sencha.gxt.data.shared.ModelKeyProvider;
import com.sencha.gxt.data.shared.PropertyAccess;
@@ -21,12 +22,15 @@
import com.sencha.gxt.examples.resources.client.model.Stock;
import com.sencha.gxt.explorer.client.model.Example.Detail;
import com.sencha.gxt.widget.core.client.ContentPanel;
+import com.sencha.gxt.widget.core.client.container.VerticalLayoutContainer;
+import com.sencha.gxt.widget.core.client.container.VerticalLayoutContainer.VerticalLayoutData;
+import com.sencha.gxt.widget.core.client.container.Viewport;
import com.sencha.gxt.widget.core.client.grid.ColumnConfig;
import com.sencha.gxt.widget.core.client.grid.ColumnModel;
import com.sencha.gxt.widget.core.client.grid.Grid;
import com.sencha.gxt.widget.core.client.grid.GroupingView;

-@Detail(name = "Grouping Grid", icon = "grouping", category = "Grid", classes = {Stock.class})
+@Detail(name = "Grouping Grid", icon = "grouping", category = "Grid", classes = {Stock.class}, fit=true)
public class GroupingGridExample implements EntryPoint, IsWidget {

interface StockProperties extends PropertyAccess<Stock> {
@@ -75,7 +79,7 @@

final GroupingView<Stock> view = new GroupingView<Stock>();
view.setShowGroupedColumn(false);
- view.setForceFit(true);
+ //view.setForceFit(true);

Grid<Stock> grid = new Grid<Stock>(store, cm);
grid.setView(view);
@@ -97,7 +101,15 @@

@Override
public void onModuleLoad() {
- RootPanel.get().add(this);
+ Viewport vp = new Viewport();
+ VerticalLayoutContainer container = new VerticalLayoutContainer();
+ vp.setWidget(container);
+
+ container.add(this.asWidget(), new VerticalLayoutData(1, -1, new Margins(10)));
+ //Resizing works if height is set to 1 so it expands to the entire window.
+ //container.add(this.asWidget(), new VerticalLayoutData(1, 1, new Margins(10)));
+
+ RootPanel.get().add(vp);
}

}

nbuesing
10 Feb 2012, 8:47 AM
Now I have another scenario (that I am yet to get working in your explorer code), but the grid (which is nested quite well) will not resize at all.

Now if I change the code to remove the return and schedule deferred it does get rendered correct, but debugging shows this class never ends (which makes sense since the scheduled defer will go indefinately). In any case, something is going on to prevent the desired re-rendering.

if ((c instanceof HasWidgets || c instanceof IndexedPanel) && !secondPassRequired) {
secondPassRequired = true;
Scheduler.get().scheduleDeferred(forceLayoutCommand);
///return;
}

I will try to work on an example and add it to this defect. However, if you make any progress the initial issue on this, I would appreciate the change so I verify to see if it would by chance fix this issue.

Thanks.

sven
10 Feb 2012, 8:53 AM
(that I am yet to get working in your explorer code)

There is no need to use the explorer for examples. Easiest is to just create a standalone one. THan you also do not need to provide patch files but can provide the hole class required. This is way more efficient.

nbuesing
5 Oct 2012, 11:37 AM
Here is a stand alone example of this, since it seems this issue was lost over the issues of trying to apply this to the demo pages vs. creating a stand-alone test case.

resize the browser and the table/content panel do not resize until there is a mouse over...

39186

Colin Alworth
1 Nov 2012, 3:56 PM
I may be missing something here, but it the ContentPanel/Grid don't resize no matter what I do, which seems to make sense, as they are given explicit sizes.



grid.setHeight(300);
grid.setWidth(800);
panel.setWidth(800);
panel.setHeight(200);


Removing these lines causes an issue, predictably, as the ContentPanel was added to the inner VLC with size -1,-1, meaning "don't size this child, it will decide its own size". Additionally, the FieldSet is added to the outer VLC with the same sizing, so the outer VLC isn't sizing the FieldSet, which therefore has no size to give the inner VLC. Even if it did, the inner VLC has also been instructed not to size its child (panel).

Edit: Just got this issue to occur in IE8, though still cant get it in FF or Chrome. I'm actually not sure why it is resizing at all, as it has been given -1 as a width/height and an explicit height/width, so it shouldn't be passing the layout along at all. That said, I'm still not sure the structure makes sense, especially if the bug is that the Grid/ContentPanel is *not* resizing. Can you clarify what you expect this to do?

nbuesing
19 Nov 2012, 7:00 AM
Colin,

Sorry for not responding earlier, I continue to have some resizing issues, and trying to get them resolved prior to posting this.

When I originally posted this, I was still doing trial and error figuring out how the sizing and resizing all works.

I don't know exactly what I was expecting, but I wasn't expecting things to resize on mouse over, and because of this is really added to my confusion of how VLC and VerticalLayoutData works. I know in other email exchanges we have had, a lot of my confusion was around things behaving like this. I was expecting things to either NOT resize at all, or resize when the window was resized, but NOT resize on mouse-over.

Here is what I'm trying to get it. I want a scenario where the width of components resize to the window (so a VLC width value of 1), but the height does not resize a VLC height value of -1). I want to give components their heigh and then have a scroll bar in the VLC to allow the full height to be seen, and a the same time, I want the width to fill the screen.

Ideally I would like to set a minimum width, so if the browser was set too small, then a HScroll would be present. however, that is a nice to have feature, not something I really needed.

In all my attempts to get the width=1, height=-1 behavior, I notice this "resize on mouse-over" and I really think no matter if I am setting something up right or wrong, this is incorrect behavior.

the issue I'm having now is that I get a grid to shrink every time I resize the browser (and I don't want it to shrink). If I can get that fixed or I get a test case, I will be follow up with more details.

Colin Alworth
19 Nov 2012, 8:51 AM
Surprisingly, or not, there is not a single line of code in GXT that causes layouts to happen when mouse events occur. Instead, I believe this behavior comes out of the browser, trying to make predictions in its layout work, and messing something up. As to why it is corrected when the mouse moves, I have two theories: The mouse makes the browser thing again about a reflow, thus fixing the mistake, or the browser sees the mouse event, passes it to the JavaScript (i.e. GXT), and somewhere inside the JS app a new style is added, so the browser is forced to reflow the page, thus fixing the issue.

Our work, as the developers of the widgets is to make sure they work in all reasonable use cases - we don't test all of the unreasonable ones, of which there are many. We also strive to make them perform well - in almost all cases, GXT 3 is faster than GXT 2. We could take a different approach, where it is nearly impossible to build a page with a layout that doesn't make sense, but at significant expense at runtime - the app would need to assign all sizes, wait for the browser to finish, measure all sizes, and starting from each leaf widget in the layout tree, decide if the size is reasonable, and if not, start to force some parent or other to have a size to make it reasonable.

Min-size container: This shouldn't be too hard to build as a distinct container. Extend SimpleContainer, and in doLayout(), get the current size. For each dimension, if greater than minHeight/Width, track that dimension, otherwise, track that min value and enable scrolling in that dimension (set overflow to auto or scroll). Call applyLayout() to the only child, with that size (and 0,0 as a position). You should be able to reuse this then, with different values, across the app, just beware how it will interact with the things that have scrollbars *below* this container - you may well end up with nested scrollbars.

Width=1, height=-1 behavior - what do you intend this to look like when it is finished? To consume all width, but to have the grid decide its own height? The grid doesn't support this (by default) for one simple reason: what happens when there are more rows than can be drawn? A scrollbar will be needed somewhere, and unless we ask it to pick a size, then measure itself and its parent, then pick _another_ size, you'll end up with a scrollbar at the parent of the grid. This is somewhat contrary to the point of the grid, especially with any sizable number of rows (hundreds, thousands), but it can be implemented, in much the same was as this example: http://www.sencha.com/examples-2/#autoheightgrid

nbuesing
19 Nov 2012, 10:06 AM
Width=1, height=-1 behavior - what do you intend this to look like when it is finished? To consume all width, but to have the grid decide its own height? The grid doesn't support this (by default) for one simple reason: what happens when there are more rows than can be drawn? A scrollbar will be needed somewhere, and unless we ask it to pick a size, then measure itself and its parent, then pick _another_ size, you'll end up with a scrollbar at the parent of the grid. This is somewhat contrary to the point of the grid, especially with any sizable number of rows (hundreds, thousands), but it can be implemented, in much the same was as this example: http://www.sencha.com/examples-2/#autoheightgrid

I am setting the grid to a given height, so that isn't the issue here (thanks for earlier email and posts you provided me on this).

I have a vertical layout container that contains many children. Each child is with an explicit height (either set as in the case of the grid) or built up from the components of the child widgets. Each child of the VLC is a FieldSet.

There could be 20+ field sets, so I want the VLC to scroll. However, I want the FieldSets (and their contents) to take the full width of the browser window.

Hence, VerticalLayoutData(1, -1) is being used when adding the FieldSets to the VerticalLayout container.

Now, back in Feb when I originally had this issue, I was looking at VLC.doLayout() and seeing how it behaved with -1 values for width and height.

It sounds like it is a browser issue, since you say GXT doesn't do anything with resizing events, instead of passing them down. Just confirms my continue frustrations with IE.

Thanks.

Colin Alworth
19 Nov 2012, 12:08 PM
I have a vertical layout container that contains many children. Each child is with an explicit height (either set as in the case of the grid) or built up from the components of the child widgets. Each child of the VLC is a FieldSet.

There could be 20+ field sets, so I want the VLC to scroll. However, I want the FieldSets (and their contents) to take the full width of the browser window.

Hence, VerticalLayoutData(1, -1) is being used when adding the FieldSets to the VerticalLayout container.

Okay, this I can help with.

Don't use a VLC - a VLC is for complete sizing of at least one child, and is really overkill (esp if using IE, where performance matters). Instead, consider the CssFloatLayoutContainer.

This is designed to expect that only widths will be assigned to each and every item (default of -1, meaning the same as VLC/HLC, pixel and percentage also allowed). Two differences from VLC:
- no height is assigned, each child is expected to be able to size itself (or be assigned a height directly).
- if there is still space leftover in the current row, and the next item would fit, it will be placed there as well - this is why it is a CssFloat container.

This is very versatile - it can be used to produce a multi-column form (three children each with new CssFloatData(.33), each is a FlowLayoutContainer or another CssFloatLC, with lots of widgets attached), or a single column of full-width items (N children, each with width = 1.0) - the latter sounds to be exactly what you are looking for. No measuring is required, just let the items flow as they need to.

EDIT: We understand your IE frustrations, believe me. If you get this "magic moving items" bug in the future where the layout configuration makes sense, as do the styles, adding position:relative to an element (either the moving thing or the parent of the moving thing) often can tell IE to behave. This is also done for other reasons than punishing IE, and is available as XElement.makePositionable().

nbuesing
19 Nov 2012, 12:39 PM
Colin, Thanks for all of your help (yet again). I will have to give the CSS Float Layout a try. To be honest, I thought the VLC would be more better (performance and ability for what I wanted to do), since I didn't think I needed to do an "float" repositioning; I guess I was wrong on that.

I will have to try this all out.

Thanks again.