Odd deferred layout behaviour with a Flickable of a Column of Columns...
Just had an interesting encounter with this:
I have an app with a Flickable containing a Column (
id: content) containing a Repeater and the repeater's model component is another Column (
id: record) with some Text and Image and Rectangle items in it.
It's look-and-feel is exactly as expected... however when I added some external js to dig into the
contentitems children looking for certain items (identified by a particular
objectName) and using their position relative to the Flickable's
contentHeightto trigger display of some "top level" UI stuff not in the Flickable... I got some unexpected behaviour, and a bit of logging confirms it's as if the inner
recordColumn items aren't laid out until they're actually scrolled into view in the Flickable. Before that, the
records' child items is unexpectedly zero.
(A consequence of this was that the first time scrolling through the Flickable, the triggered stuff was being triggered prematurely. But then once everything was forced to be laid out and the
yvalues were correct, everything behaved as intended while scrolling back and forwards again).
There's some hint that Column might be doing something clever from the mention of
forceLayout()in the docs. I couldn't figure out where to drop a
forceLayout()into my code to get it to behave any better though.
I eventually worked round it by replacing the inner
recordColumn with a straight Item, and anchor-based placement of its sub-items... then the y positions of the sub-items seem to be as expected from the start. But I'd like to understand what's going on better.
Is the behaviour I saw with Column better documented anywhere? Are there other component types which defer layout calculations until they're "in view"? Is this "in view" behaviour specific to Flickable, or other things? Is there any way of tapping into it (a signal or something?) or does it just naturally fall out of QML's just-update-what's-needed approach somehow?