Gil Yoder wrote:Using binding I ran a test with
GridSplitterEx to watch the size of
the right column as the splitter moved right. The column would shrink to a size
of about 210 pixels (close to
MinWidth + 12) plus or minus a pixel
or two (it wasn't always the same), when the splitter would stop moving.
Oh yeah, I now have some vague recollection about the grid "randomly" growing if I went past a certain point (the + 12). I don't remember the exact details, but that sounds like the right neighborhood.
Gil Yoder wrote: your code does workaround the problem for the simplified
presented, giving the approximate minimum size for the column, but it did not
work unmodified, if I added another column between the splitter and the last
column in my XAML.
Correct. I only needed a left & right column, so GridSplitterEx only handles that case . Doing it generically for multiple columns on the right seemed like a lot of unnecessary work at the time .
It *is* a bug in .NET & GridSplitter though.
Unfortunately, it is not easy to fix. If you look at the source code for GridSplitter, everything you need access to (to do this right) is private. No virtual methods, etc. to override.
I think if you want to do a generic multi-column fix, you need to do the work in a GridEx : Grid type class and override MeasureOverride & ArrangeOverride and fix the bug there.
Basically copy the source for those two functions and debug to see where the bug is... but really, what is the expected behavior?
Lets say you have something like:
1 (min 200) | 2 (min 200) | 3 (min 200)
No matter how you fix it, it is always going to be possible to run 2 & 3 off the screen. For example... maximize the window, move splitter 1 all the way to the right. Then minimize. 2 and 3 will be gone.
There are a whole bunch of cases you need to handle .
Even my fix will not handle that case for just one splitter. Resizing the window horizontally will not resize the panes.