I think there's a bug in MultiSplitLayout once it starts doing layoutContainer with floatingDividers FALSE, i.e. typically after the MultiSplitPane user has dragged a DIVIDER.

To illustrate the bug, consider a ROW layout with two LEAF nodes separated by a DIVIDER. The nodes have weights of 0.3 and 0.7 respectively.
Let us assume the total available WIDTH for the LEAF nodes is 100px, that’s why we get: 30px and 70px.
Now, if I maximize the frame such that the total available WIDTH for the LEAF nodes becomes 1000px, we get: 300px and 700px.
So far, there was no problem because given that no DIVIDER was dragged yet, layoutContainer will call doLayoutByWeight, and layout2 will properly allocate the extra space.

Now let us assume I minimize my frame back to the 100px above, and I drag the DIVIDER such that to get a 50-50 layout.
Now, if I maximize the frame such that the total available WIDTH for the LEAF nodes becomes 1000px, I won’t get: 500px and 500px.
Basically, because:
1. floatingDividers is set to FALSE and hence we will no longer doLayoutByWeight
2. when layout2 calls layoutGrow, it will attempt to allocate the extra space as follows: newWidth = currentWidth + (extraWidth * splitChild.getWeight())

The problem is in the call getWeight() since it will return a non-updated weight (either 0.3 or 0.7 in this case), instead of the updated 0.5.
When I update the layout to 50-50 and I maximize, I expect the currently showing weights to be preserved, not the ones the layout had initially started with!

I propose the following solution to this:
Every time a divider is dragged, weights must be recalculated, and floatingDividers must be set back to TRUE to resume layoutByWeight.

I copied the code of MultiSplitLayout and added a method called updateWeigths() (along with another helper method). I call this method from within the finishDrag method of JXMultiSplitPane.

Please check the attached source code.
I’m waiting for your feedback, specially from the authors of those classes Hans Muller and Luan O’Carroll.

I just ran your test, and yes, it does reproduce the problem of invalid weights!

You can also try the following scenario which also clearly reproduces the problem:
- set the initial weights as follows: LEFT 0 / RIGHT 1.0
- run and drag the divider, e.g. to achieve 50/50
- now maximize

As opposed to the expected 50/50 layout, you'll see that the width of the LEFT node won't change, because as I already explained, extra space is allocated as follows:

newWidth = currentWidth + (extraWidth * splitChild.getWeight())

And since the LEFT node has an initial weight of 0, it will get nothing of the extra space, and its newWidth = currentWidth.

Thank you for your reply. I didn't run your test yet, but yeah, that's exactlybthe problem I was talking about.

The bug can be summarized as follows: after a divider is dragged, the weighrs of the layout are not updated, which means that once a divider is dragged, the weight values are no longer valid, and methods such as layoutGrow would be using invalid values to compute the layout.