08-04-2011 02:39 PM
Unless you extend a Manager and implement your own sublayout, don't ever use setExtent - pass the correct values into super.sublayout instead. Doing otherwise is just asking for trouble.
08-04-2011 03:13 PM
@dnepr: that's pretty much what I told akhan back in the day.
However, I suspect some additional problem there: both akhan and david_schwartz_bb seem to have problems specifically with ObjectListField. And there was a report on a totally difference issue, but still to do with ListField and scrolling. Might well be an OS bug - that other issue most definitely was.
That rings a bell.
Inside the VFM sublayout, when laying out a listfield, do the following:
f being the ListField
layoutChild(f, desired list width, ((ListField) f).getSize() * ((ListField) f).getRowHeight());
08-04-2011 05:43 PM
Personally I don't like stuff like layoutChild in built-in managers. They do that properly in their sublayouts and later use their internal data generated by the same sublayout method to scroll and paint properly.
I do wonder how akhan's and david_schwartz_bb's custom managers lay out their children, especially the scrolling VFM. They might have some subtle bug there exposed only by more complex screen components such as ListFields.
For example, david's setExtent(300, 300) looks extremely suspicious. super.sublayout(300, 300) is the proper way to achieve it for built-in managers. I've just posted this in the other thread - I hope that's a good enough explanation:
Overall, writing a custom layout Manager has many pitfalls - they might have fallen into one or more of those .
08-05-2011 09:08 AM
I figured it out.
The form containing the ObjectListField must have this in the constructor:
Somehow it prevents the ObjectListField from stretching out the background image instead of scrolling the list within the background.
Do you know why this is required?