-
Re. 125 is the default column's width: Ok.
-
In the Application's Startup Event Handler in App.Xaml.Cs, I create (and assign to the Window's DataContext) the View Model Instance and then call Window's Show Method. If I don't change DataGridControl's ItemsSource, then the above workaround code works. However, if I assign a new value to DataGridControl's ItemsSource's Bound / Source Property after that (i.e. to apply changes to grid item filters the user specifies via other Elements), then the Columns return to their default width (of 125). In my test app, if I add the workaround code to ItemsSourceChangeCompleted Event Handler also, then it'll work even after the ItemsSource change.
-
However, in my production app, like I said, even though I'd placed the workaround code in both the DataGridControl's Loaded and ItemsSourceChangeCompleted Event's Handlers, GetFittedWidth still returns -1 for all Columns. I did just notice a new clue which explains the immediate symptom of why GetFittedWidth returns -1, but it doesn't explain the root cause. In both those Event Handlers, the DataGridControl's Items Collection has a 0 Count. I can't explain why that is though. From code review and the final U.I. display, there are > 0 Items. Even if Items were (for some currently unknown reason empty) at some point, one would expect that the Event Handlers would eventually be called with a non-empty Items.
-
Why is this workaround code even necessary??? Like I said, with .NET DataGrid, the Columns are auto-sized without any such extra code, and it does so in my same production app with its ItemsSource Bound to the same Property that my DataGridControl is Bound to. I would consider this a bug / feature omission. 3rd party tools should extend and add features not drop them vs. the standard tools.
↧
New Post: DataGridControl AutoCreateColumns Auto-Size Columns
↧