(SVN) items added before scrollbar creation change position

christianboutin.com

14-09-2009 15:15:26

I'm creating a list of buttons in a window through a for loop in this way :

for (int i=0;i<10;i++){
//for (int i=9;i>=0;i--){
if (i%2 == 0){
bd->widget_skinTypeName = "usca_missionbuttondark";
}else{
bd->widget_skinTypeName = "usca_missionbuttonlight";
}
bd->widget_dimensions.position = QuickGUI::Point(13,bd->widget_dimensions.size.height*i);
bd->textDesc.segments.clear();
bd->textDesc.segments.push_back(TextSegment("BigMenu",QuickGUI::ColourValue::White, *missionTitle.begin()));
win->createButton(bd);
missionTitle.pop_front();
}


items are created in the window, but as they go below the lower end and the scrollbar is created, items created _before_ the scrollbar get moved to the side as shown here :



The coincidentally named "mistake" button appears at a different X position than the previous button "at all costs". Mistake is at the right place though, and all buttons above it were pushed to the left. mistake is the first button that is created after the scrollbar is required (ie, "at all costs" goes a bit below the window, so after it the scrollbar is created, then "mistake" is created)

Switch the commented "for" for the other, which places buttons from the bottom up, and this is what I get :



As you can see only the first created button, "Blowing up Rocks" is improperly placed. Others are in their proper place.

There's a quick workaround for this on the user's end. Create a blank dummy item at the lower-right-most point as the first element, then add all the buttons. Still thought you'd like to know.

Thanks!

C.

* edit : clicked submit prematurely

christianboutin.com

14-09-2009 15:54:16

I just tried with images and I don't have the bug. Is that bug for buttons-only? Maybe...

kungfoomasta

14-09-2009 19:01:30

Thanks for bringing this up. Scrolling is always a pain. I'll have to step through and see whats happening here. Not really sure why the buttons are getting shifted. I know that the client area becomes smaller once the scrollbars appear, but that shouldn't affect the positioning of widgets.

Are your images the exact same size as the buttons?

Also, if you want to make sure the buttons are the exact width of the window dimensions, you can always make use of

Widget::getClientDimensions()

This doesn't fix the issue here, but it should prevent that bottom horizontal scrollbar from appearing.

christianboutin.com

14-09-2009 22:03:12

Yes the images have the exact same layout/content as the buttons (just changed the type in the skinType file). For that particular menu I thought I could make a series of buttons and fill them with images/text and so forth. But I found out it's impossible (buttons can't have children I think) so I first replaced them with images, at which point the bug didn't occur, then panels (which is the right way to do what I want, I believe : panel, with all the elements on it, then stick a transparent button that covers it all), also no bug with panel. So it seems specific to buttons. Worked around the bug now so it's no longer an issue for my game. Just a thing to keep in mind :-) Thanks!

kungfoomasta

15-09-2009 05:03:35

I can't get to this tonight, but I want to try to repro this tomorrow night.

kungfoomasta

19-09-2009 22:21:57

Very odd, I couldn't reproduce this easily, but I do have it repro'ing now.

From my investigations it looks like the ContainerWidget class is shifting the buttons when the scrollbars appear.

The way the anchoring system works, when the client dimensions of a widget change, the children of this widget are repositioned and/or resized according to their anchors. (A Left Anchor is an enforcement of a position from the left side of a widget to it's parent's left side, for example)

When the scrollBars appear, the client area becomes smaller by 15 pixels. (scrollbars have width of 15 pixels) Since the client area is changed, the anchors are applied, and the end result is that all widgets that were previously existing get shifted left by 15 pixels. In my example , the window fit 5 buttons before the ScrollBars appeared. When the 6th button appeared, all previous buttons got shifted to be at position x - 15. All future buttons still have position x.

In short, I do not believe the appearance or disappearance of ScrollBars should have any impact on the actual positions of Widgets within the ContainerWidget. The client dimensions will not be changed when ScrollBars appear or disappear.

kungfoomasta

23-09-2009 19:29:18

I just noticed last night my change causes the vertical and horizontal scrollbars to overlap, I will take a look at this and fix it, should be a quick fix.

kungfoomasta

23-09-2009 20:48:56

Fixed in SVN. I'll probably update the release zip also, tonight or tomorrow