Currently I'm creating a codename one component for which the height depends on the width. Codename one (Shai Almog) replied that this is not easy to do, the layout algorithms aren't intended to handle this requirement. See the original question here. A suggestion was given to use the approach in the Codename one TextArea component, but apparently this approach was not without issues itself.
No I would like to solve this by a different approach. I was wondering if people could give feedback on whether this would work or not. The basic idea is the assumption that the width and height of a Form component, as being the highest component in hierarchy, won't depend on a layout manager but directly on the display. And thus has fixed dimensions. The Form has a child Container contentPane that I'm assuming then also has fixed size. Then we can create a custom LayoutManager to use this information. Say we extend from a BoxLayout and overload its methods layoutContainer(Container c) and getPreferredSize(Container c) to use this info, using c.getParent().getParent() instanceof Form to know width and height (depending and for custom resizable components create methods such as getPrefferedWForHeight(int height) or an initializing method setFixedWidth(int width) that affects the usual getPrefferredH() and getPrefferredW() calls.
Nicest would be to extend components using methods such as hasFixedWidth() (or to combine width and height in one call hasFixedDimension(int axis)) and widthDependsOnHeight() that would make the BoxLayout independent on hard coded class names, but it look like it can't be done as replacing Codename one components using
UIBuilder.registerCustomComponent("Container", nl.localhost.Container.class);
UIBuilder.registerCustomComponent("Form", nl.localhost.Form.class);
appears not to have effect.
I haven't thought much about scrolling or rotating devices (and thus repainting Forms) but I don't think it will give a problem. Would the approach above work?
Best wishes Marc K
