ScrollPane.prefViewportWidth == computed size?

Richard Bair richard.bair at oracle.com
Mon Jun 3 11:57:45 PDT 2013


> Problem: this works only if the content prefWidth is set explicitly. If it is -1, prefViewportWidth is also -1 (because it is bound) and that computes a value too small to fit the (computed) prefWidth of the content, leading to a horizontal scrollbar. Is this a bug

I think calling it a bug would be fair, and this approach should work.

> or am I supposed to do this differently?

Hmmm. I guess fitToWidth doesn't work for you because you want the content to dictate the size of the scroll pane, and not the other way around? Maybe a combination of this and a subclass to work around the issue you are seeing?

public class MyScrollPane extends ScrollPane {
    public MyScrollPane() {
        setFitToWidth(true);
    }

    @Override protected double prefWidth(double height) {
        Insets insets = getInsets();
        return insets.getLeft() + content.prefWidth(height) + insets.getRight());
    }
}

Ok I didn't try compiling that ("content" for sure will break) but this should set the pref width of the scroll pane based on the pref width of the content, and then add in the padding (for whatever kind of border you may have supplied). This might still be wrong because it doesn't take into account the scroll bar width when the vertical scrollbar is shown. Bummer.

Or maybe the ScrollPane, when fitToWidth is true, automatically adjusts its pref width to match that of its content? That would seem to be the "right" thing to do in this case, but I don't know that it does (or that it makes sense in all cases?).

So it seems to me that there are at least 2 different ways we could go about supporting this specific use case, one seems like a straightforward thing (let -1 have meaning for prefViewportWidth) and one is the result of a perhaps questionable interpretation (fitToWidth=true changes the way we compute the prefWidth of the ScrollPane). Both seem reasonable ways to have tried to use the control and both yield unexpected results it sounds like.

Richard


More information about the openjfx-dev mailing list