I tried the first one with a new DefaultExpandStrategy(dockable.getController()) as strategy, I also tried the second one with dockable.getController() as controller, but both resulted in a weird layout: it seems that when my dockable contains a scrollpane, the dockable is expanding as much as the scrollpane’s content height!?
What should I do to restore the old behavior?
In other words, what’s exactly equivalent to using the no longer existing CLocation.expandProperty(DockableProperty property)?
Note that I am not 100% sure whether this API change is the reason behind my weird layout problem (with a scrollpane).
But when I compiled after updating to 1.1.1, besides having to implement makeTransparent(Window window); in the Workaround interface, this was the only API change I noticed, and that’s why I suspected of it.
Both your calls end up executing the same code, because “expandProperty” just creates a DefaultExpandStrategy if none is present. The DockController is required to load extensions (like the Toolbar-extension), otherwise it does not have much effect. The code is almost untouched in this area.
I could imagine the scroll-pane has a “preferred size” which is rather big. Maybe some code takes that into consideration (I would not know which piece causes all the trouble). Before I start guessing around: how does this DockableProperty look like (I think a call to “toString” should already provide much information)?
Thank you Beni for your support, I really appreciate it!
Actually, it is until I attempted to get the „toString“ of my DockableProperty that I realized that the two getCLocation(…) methods which I override, and where I call expandProperty(…), are not even being called! This means the layout problem I’m having with scrollpane has nothing to do with it.
But the layout problem is reproducible, and it’s something that didn’t used to occur before.
You can run the attached sample ExampleWithDocking.java, first on v1.1.1p7, then on v1.1.1, and you’ll see the problem. And I already attached screenshots if you want to have a look.
I still don’t know starting which exact version before v1.1.1 is the problem reproducible, but I remember running it on v1.1.1p7e and there was no problem neither. So it’s somewhere between v1.1.1p8 and v1.1.1.
Alright, the issue is caused by the “getPreferredSize” method of “SplitDockStation”, which I updated around the time you describe. The updated method asks all the children Dockable for their preferred size, and returns something close to the sum, more details follow.
Unfortunately your “panelC”, the one with the JScrollPane, returns a preferred size of about “871x1773” pixels. And because the “getPreferredSize” of “SplitDockStation” tries not to move around the dividers (tries not to change the relative size of its children), the height is tripled.
This is not a bug, this is the intended behavior. It’s just not backwards compatible enough for your application. As a solution I would have some suggestions:
[ul]
[li] Remove the outer JScrollPane, in your example the parent of “rootPanel”. Is it really necessary?
[/li][li] … or manually define an upper size of the “rootPanel” (by overriding its “getPreferredSize” method and check for some maximum values for width and height).
[/li][li] … or make sure the “panelC” in your application does return a smaller preferred size.
[/li][/ul]
