Hi Nir,
Thanks, yes, those are what I was thinking about. It seems to apply to
more properties though, anything that is changed in a layout methods
seems like a bad idea to bind to something else that may affect layout.
ScrollPane#viewportBoundsProperty seems to be such a property that you
better not bind to something else layout related.
--John
On 09/02/2024 15:48, Nir Lisker wrote:
You're thinking about the docs of the note in the bounds properties I
think:
https://openjfx.io/javadoc/21/javafx.graphics/javafx/scene/Node.html#boundsInLocalProperty()
https://openjfx.io/javadoc/21/javafx.graphics/javafx/scene/Node.html#boundsInParentProperty()
On Fri, Feb 9, 2024, 03:28 John Hendrikx <john.hendr...@gmail.com> wrote:
Hi,
I'm pretty sure I read somewhere in JavaFX docs, code or website that
binding certain properties which are changed during layout is a
really
bad idea, but I can't find where I've seen this. Anyone know what
I mean?
It was something like: binding the values of a property like
width/height which are changed during layout to another property
(which
may in turn affect layout) should not be done, and one should be
using
properties like min/pref/max width/height.
The reason I ask is because I'm running into a weird problem where
I'm
binding the value of ScrollPane.viewportBoundsProperty.width to a
Label's text property. What I noticed is that the Label simply is
not
updating correctly, and will display the correct value **BUT** use
the
previous value for its width calculation which causes the text to not
fit -- the fact that it is displayed wrong is especially obvious when
the Label's value switches between values like "312.0" and
"313.333333333" where the 2nd value often gets an ellipsis (like
"31...") because its width was computed based on "312.0". What I see
happening is this:
- A splitpane is resized (with a scrollpane in it)
- The ScrollPane's viewportBoundsProperty changes (in layoutChildren
code of ScrollPaneSkin), so layout is already running...
- A binding on viewportBoundsProperty.width updates the label text
from
"312.0" to "313.33333333"
However, before that binding is executed, I see a call to
`computePrefWidth` on the Label, which uses the old text (ie.
"312.0")
-- there is NO other call to computePrefWidth, so the layout process
continues with an incorrect width value...
When later the layout code of the Label is called, it concludes
that the
current width (based on the text "312.0") is insufficient to display
"313.33333333", and so adds an ellipsis...
So, I'm thinking this may be "expected" behavior -- I'm binding on a
property that is updated during layout, and then making another
change
(to Label.text) which in turn should trigger a new layout. However,
that doesn't happen, and it just runs in the current layout, where it
then uses part new, part old values (new text, but old width).
Any insights are appreciated.
--John
