Thank you for reporting this bug. We will make it our priority to review this report.
  1. #11
    Ext GWT Premium Member
    Join Date
    Dec 2011
    Location
    Earth
    Posts
    243
    Vote Rating
    1
    nbuesing is on a distinguished road

      0  

    Default


    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.

  2. #12
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,734
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    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

  3. #13
    Ext GWT Premium Member
    Join Date
    Dec 2011
    Location
    Earth
    Posts
    243
    Vote Rating
    1
    nbuesing is on a distinguished road

      0  

    Default


    Quote Originally Posted by Colin Alworth View Post
    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.

  4. #14
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,734
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    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().

  5. #15
    Ext GWT Premium Member
    Join Date
    Dec 2011
    Location
    Earth
    Posts
    243
    Vote Rating
    1
    nbuesing is on a distinguished road

      0  

    Default


    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.

Thread Participants: 2