On and off MSDN forums, there have been questions and comments raised about flickering due to SplitContainer.
The repeated official answer from MSDN is the same - setStyle for DoubleBuffer, UserPaint and AllPaintingInWmPaint to true.
All the while the official answer does not andress this one obvious phenomenon:
- The child SplitterPanels, panel1 and panel2, do not expose their setStyle methods.
- SetStyle methods are protected. Therefore in order to apply setStyle to child SplitterPanels, the programmer needs to create a subclass of SplitterPanel.
- But SplitContainer does not allow you to replace the child SplitterPanels referenced by the variables panel1 and panel2 with our own SplitterPanel instances.
Therefore, there is no way to enable doublebuffering on the individual SplitterPanels. There is no point in enabling doublebuffering for SplitContainer.
In fact, having doublebuffering feature available to SplitContainer is nearly a waste of namespace real-estate, because what really matters is doublebuffering the child SplitterPanels not the SplitContainer itself.
Another answer given to solve this problem is - have the contents of the SplitterPanels absorb the SplitterPanel's irresistable urge to flicker. Which would require the programmer to create contents that have complex manual painting strategies that may or may not work. Which the programmer may not able to implement due to class protection of the content being use.
Therefore, the only effective answer I have found on the internet is - create your own SplitContainer class.
I urge MSDN to carefully inspect this issue and admit that there is a bug (aka non-deliberate feature) here:
- Please do not tell us to use doublebuffering unless
- You can tell us a way to propagate the double buffering to the child SplitterPanels.
Perhaps, the issue would be solved in .NET 3.x?