Unanswered: Handling Scrollbars

Unanswered: Handling Scrollbars

I'm trying to build a panel that offers vertical scrollbars as needed. I've managed to do it before but this required so much weird coding and direct access of Style objects that I assume I must have been doing it wrong. When I build this the Layouts go off the page (see picture). I'm not sure why this is. If you see the picture the GroupCheckBoxPanel (the main class in this particular case) it has correctly built its FieldSets and Buttons from the provided GroupEntry but there are no Scrollbars. What triggers the system to add Scrollbars? I'm sure there's a simple approach I just keep overlooking.

I'm tried to provide a runnable version of the code I'm working with but I had to make some inline modifications to pull out the complicated class hierarchy parts. The main widget I'm working with is the GroupCheckBoxPanel.

You've got a lot of code there, and while it looks to be self-contained, its still a fair bit of reading, so I'll try answering the root question first, and see where that gets us:

What triggers the system to add Scrollbars?

The trigger to the browser is the css property 'overflow' (also available as either 'overflow-x' and 'overflow-y') - when set to 'scroll', scrollbars will always be visible, when set to 'auto', scrollbars will only be visible if required. Other options either draw content escaping its bounds (as in the "Css is Awesome" coffee mug), or cutting it off.

The key to remember here then is that contents don't need a scrollbar unless they are too big to fit - they must consume more space than is allowed. Systems that try to measure but fail to account for something sometimes end up with multiple, nested scrollbars - instead, pick a point in your layout where items will no longer be sized. The Grid body is a obvious example - rows would never get their height set based on the total size of the grid. A form usually makes sense in the same way - set overflow:auto on the outer form so that it can be made to fit, and just let the children force their own sizes.

Like I said, I haven't read all the code, just skimmed it quickly. But from that, this is a concern in your approach:

Code:

/**
* Utility class which creates a panel from a given ScaleBaseFormItem
* this panel contains the specificed fieldlabel and formItem.
* We use this class to consolidate all visual components (styles, padding, align, etc) which may
* not be done as easily in CSS into one place to be easily modified
* @author LENOVO USER
*
*/
public class ScaleBaseFormLayout extends VerticalLayoutContainer
//...
add(name, new VerticalLayoutData(-1, -1, margin));

A VerticalLC doesn't really make sense if all of its children are -1,-1 - thats the same as a FlowLC. The FlowLC.add method takes a margin data, same as VLC, so it should be able to take these same margin details you are trying to set.