Nested SplitContainers bug the SplitterWidth

Question

So I have 3 split containers, with 2 panels each.

SplitContainer1 is the main container that is docked in the Form ( Parent ).

SplitContainer1.Panel1 contains SplitContainer2 which is docked.

SplitContainer1.Panel2 contains SpliContainer3 which is docked.

So far so good.

SplitContainer1 has a SplitterWidth of 3. SplitContainer2 and SplitContainer3 has a SplitterWidth of 6.

In the Designer, you can see the SplitterWidth difference between them, but when I build the solution, the SplitterWidth of SplitContainer2 and SplitContainer3 gets reset back to 4 no matter what I do. I have changed the code in "InitializeComponent" of the form with no effect.

The only way I got this working is in the Load Event of the form, re-specify the SplitterWidths which I find completely dumb. Why won't the SplitterWidths stay at the value I specified in the Designer?

If anyone can shed some light on this, what would be awesome!!

Thanks for your time,

Peter

Melody

I was able to reproduce the problem on my end. Obviously it shouldn't work that way. Sounds like a bug in the way the ambient property from SplitContainer1 is being copied to the other two? Since it's a bug, there is no workaround except the "dumb" approach you've already figured out. Sorry dude. – Linebreeding

Yes, this is a bug. An unfortunate interaction between the ISupportInitialize implementation that SplitContainer uses, which delays assigning the actual properties. And layout calculation for the panel, which forces the splitter width to be assigned. With its old value, not the pending new value. The workaround is quite simple, just assign the properties in the form constructor, after the InitializeComponent() call. – Thule

@HansPassant – Hans, based on your experience, do you think that these bugs have any chance to get fixed? I submitted similar one and it got declined. Are .NET guys generally afraid of breaking the backward compatibility with these fixes? Should I continue reporting them or should I give it up? – Schreibman

It won't happen, these bugs should have been addressed in 2005. Didn't happen, too busy with WPF. Can't fix them anymore, too many programs took a dependency on the buggy behavior. – Thule

That reminds me of bug related to renaming SplitContainters. This is a huge one (as it breaks the solution) and neither was ever addressed... – Rubicon

The only way I've been able to overcome this bug (which still exists today), is to add the SplitContainers (and all their controls) programmatically. – Jeopardize

Answer 1

Just so that this isn't left unanswered for eternity -

This is an old bug that has been in Visual Basic for many versions now, and is never addressed (nor is it likely to ever be addressed).

As Hans Passant mentions, the issue is due to the ISupportInitialize implementation for the SplitContainer.

Since it's a bug, there is not definitive way of resolving the issue that makes any logical sense.

One way, which I've tested in a mock up program, is as @xfx says - Add and manipulate the controls programmatically, rather than using the toolbox.

An alternative is to reload the SplitterWidths programatically, whether that's on Form_Load, which is most likely, or anywhere else in the code that it may be required.

Irita