[Solved] Column widths and sizes change when GridView removed and later re-added to visual tree 18167

[Brian Sayatovic]

I have a UI where a ContentControl's content is swapped out as the user selects an area from a list of area elsewhere.  For the user, it's not unlike a tab control switching tabs.  The code behind it all is just lazily constructing and caching views to set as the ContentControl's Content property value when the user selects the corresponding area in the list.

Several of these views have RadGridViews in them.  I can switch areas all day long with no problem.  Except...

When the user goes from area A to area B, and then in area B popups up a dialog, which later pops up another dialog... when they go back to A (meaning the cached view with a previously working RadGridView), the grid's column widths are all messed up.  See before.png and after.png for a small slice of the UI showing how the column sizes changed.

Part of the resized problem is that some columns are so wide, the whole grid now scrolls horizontally.  But if you just nudge the scrollbar, the columns all re-size back to their normal sizes.

We had a very similar problem in RadTabControls as well, but that was fixed by adding IsContentPreserved="True" to the tabs.  However, since this case is not a RadTabControl, that's not an option here.

Is this a bug in GridView?  Am I abusing it by removing and re-adding cached views from the visual tree?  Is there some event/method I can call to kick the RadGridView in the pants (which nudging the scrollbar seems to do)?

[Brian Sayatovic]

I believe I've determined that the trigger is when the data the out-of-visual-tree RadGridView is bound to changes.  Just switching areas doesn't change data, but the code in area B sometimes modifies data in area A (which is happens to occur inside my area B popup dialogs).

As some of my columns are "Auto", I suspect the changing data causes the GridView to recalculate widths.  However, when it's not in the visual tree, the RadGridView probably gets weird size calculation problems.

Still, I would expect the grid to be able to re-calculate its widths once it finds itself added back into the visual tree.

[Dimitrina]

Hello,

When the GridView has been unloaded and then loaded again it does not keep any settings. In that case I would suggest you to save its configuration and then load it. For that purpose you can check the PersistenceFramework as demonstrated on this online example.
 

Regards,
Didie
the Telerik team

[Brian Sayatovic]

I don't think we're talking about the same thing.

The user has not adjusted the columns at all.  When the view first renders, the columns have determined their own size based on the content and the available space because some of them are Auto and some of them are *.

Then the grid is taken out of the visual tree.  While it's our, some changes happen to the data in it's ItemsSource.

When the grid is placed back into the visual tree, the column widths are bad.  Restoring the previous column widths wouldn't be correct because some of the data has changed in the interim, the automatic column sizing needs to be re-determined.  But the grid isn't doing this.

However, when I then scroll horizontally in the grid's scroll viewer, even by one pixel, the columns then adjust themselves and stay adjusted.

Why isn't the adjustment happening when it's placed into the visual tree and its bounds become concrete?

[Dimitrina]

Hello,

We have tested the behavior when loading/unloading the GridView from the VisualTree, but we did not encounter any problems with the columns' Width. May I ask you to check the attached sample solution and let me know how can I reproduce the issue?

Regards,
Didie
the Telerik team

[Brian Sayatovic]

I downloaded the sample project and did not reproduce the problem.  So now I'm trying to add qualities and features of my project which exhibits the problem incrementally to your sample project to see if I can find the cause.