The rule of thumb in case you modify content during the layout is that content should depend on layout pane size, not the other way around. It means that changing the content won't modify the min/pref/max size of the pane as that would trigger another layout pass (possibly falling into a loop).

This is why it's not recommended to change children during the layout, as default computation of min/pref/max size depends on the children. But if you modify compute* methods and return something that is not dependent on the children, you can safely modify them while doing the layout.

So, e.g. your filter control might return pref size that is approx. for 2-3 "tabs" (or whatnot). Since BorderPane resizes top to the full width, you would always get the maximum width you can get. Based on the assigned width, you can then compute the layout and add as much tabs as you can. Since that would not change the pref width, the layout is done.

Anyway, as Jonathan already noted, a JIRA issue with some sample would be great.


On 02/11/2014 05:50 PM, John Hendrikx wrote:
From an earlier posting on this list, I came to understand that in JavaFX 8 it is no longer allowed to modify the children list in layoutChildren, and that such modifications may need to be moved to the computerPref* methods.

However, I get a different odd issue, and I'm wondering exactly what is allowed and what isn't when it comes to layout (any documentation on this?)

What's happening is the following:

I got a (subclass of) BorderPane, at the top I have a tab-like control (let's call it a FilterControl). At the center I got a TreeView.

When the BorderPane gets laid out, I set up the content for both the TreeView and the FilterControl. I do this in layoutChildren or in computerPref* of the BorderPane -- it makes no difference. Setting up the content for the FilterControl involves changing its children list. The TreeView probably will do the same (adding/removing Cells as needed).

Now, I'm seeing layout issues. The BorderPane for example is often putting the TreeView right on top of the FilterControl (stuff is transparent, so I can see it). With other attempts, the FilterControl is not visible at all (zero height). Forcing an update (by changing focus) usually clears up the issue and the FilterControl will take its rightful spot and force the TreeView to be a little less high.

I'm thinking this is somekind of issue with layout and that I'm approaching this wrong causing the layout problems. However, I don't quite understand what I'm possibly doing wrong -- modifying the children of the Top node of the BorderPane during BorderPane's own computePref/layoutChildren call should be perfectly fine right?

Any help appreciated!


Reply via email to