w-ahmad
Avoid negative MaxWidth values
TableViewCell MeasureOverride can be called by the platform before the control is rendered. This happens for example when the ItemsSource is defined declaratively and column calculations are started before the page is loaded. Your sample app doesn't experience this, since it waits for a Loaded event from its hosting grid.
When MeasureOverride is called on a tableview that is not yet rendered, then Column.ActualWidth is still zero, and the element is given a negative MaxWidth value. This causes the app to crash.
Actually I prefer my proposed implementation: only assign MaxWidth when it's relevant, otherwise don't touch it and let the basic layout routine do its work. Programmatically setting MaxWidth to zero basically makes the column or the cell invisible, and that might not be what you want. At the end of the day, users probably prefer suboptimal column auto-widths over disappearing colums (with MaxWidth zero).
Alternatively, you can indeed use Math.Max but then I would suggest to use another threshold value (something greater than zero) as a kind of 'Minimum MaxWidth' that would keep the column at least visible and selectable.
When the calculated width is negative, the original problem reoccurs. To replicate this issue, set both MinWidth and MaxWidth of any column to 20 or less in the sample app. Here is the result...
The cell content should be entirely hidden since its left and right margins are set to 12, requiring more than 24 pixels to be visible. Thus, there isn't enough space for the text to display like the Column Header. Setting
MaxWidth to 0 doesn't solve the problem. An alternative solution might be adding an else block with element.Visibility = Visibility.Collapsed.
Although it's not an ideal fix, but a "Hack". If there's another solution to this issue, I welcome its implementation.
Approved the PR because it resolves the negative width assignment exception.
@XamlBrewer I apologize for not merging this PR earlier. I initially assumed that PR authors could merge their own PRs, which led to the delay. Unfortunately, the changes are now outdated, and there are conflicts. I truly appreciate your contributions and look forward to more from you in the future. Thank you for your understanding!