Column Virtualization does not handle uniquely named cell elements

[Adam]

Hi there,

We have a grid setup in which we create custom cell elements and with those elements, like a TextBlock, they have to be named.  This is to support ValidationSummary behavior in the view mode of the grid contents.  However, when Column Virtualization is enabled, scrolling a grid horizontally causes a visual tree error, "The name already exists in the tree".  It appears that as you're scrolling with virtualization, the CreateCellElement of the column type goes crazy creating new elements but there is no reason why two cells should be added to the tree with the same name.  We name our TextBlock elements using the UniqueName of the column, which should be unique across the row.  However, upon turning Column Virtualization off, the issue does not present.  Is there something I'm not doing correctly in this scenario?

Thanks!
Adam.g

[Adam]

Additionally, if our cell element notifies of validation errors, having Row Virtualization enabled seems to "double notify" after the cell elements are created.  I can probably provide a demo of this if need be.

Thanks!
Adam.g

[Nedyalko Nikolov]

Hi,

It will be great if you send us a small project which we can debug on our side.
You should open a separate support ticket in order to do that.
Thank you in advance.

Greetings,
Nedyalko Nikolov
the Telerik team

[Adam]

Support ticket submitted, #666260.

Thanks!
Adam.g

[Ivan Ivanov]

Hello,

We have debugged the project that you have sent to us and it appears that the unique naming of cell elements lays at the base of both of the issues. RadGridView utilizes container recycling alongside its UI virtualization logic, so often containers serve different purposes during an application's lifecycle. First of the issues is caused by the fact that two different textblock instances with the same names try to exist in the same namescope which results in this exception. I have implemented a possible workaround in your code and I am attaching the modified version for your reference. As for the other problem, the Silverlight validation summary logs the errors in accordance to their sources' names. As RadGridView uses container recycling while sorting with row virtualization, the same error comes from a different source every time. Unfortunately, we cannot hardly do anything to change this behavior. May I ask you why you are using this naming approach? Is it related to any accessibility enhancements or automated tests execution?

All the best,
Ivan Ivanov
the Telerik team

[Adam]

Hey Ivan,

It seems a little silly to me that the visual tree would ever need two of these cell elements residing in the visual tree regardless of column virtualization such that we would receive the error, but if you tell me that that's something inherent in the implementation for virtualization, it certainly matches with the behavior I'm seeing.  I'll take a look at your proposed changes.

I became familiar with the fact that the ValidationSummary tracks errors based on the element name.  And, if the row virtualization did not throw a binding validation error for the old cell that had validation errors before sorting, everything would work as expected.  For our solution, I've actually duplicated the original ValidationSummary Silverlight control and am customizing the behavior to support grid view cells.  As I'm sure you saw in the project, we must be able to focus on an actual cell that is reporting a validation error.  As long as the row virtualization is double throwing this error and erroneously reporting that two cells have validation errors, I'm unsure if we can avoid this double validation error.

It sounds like, from our functionality perspective, we can avoid naming the cell elements.  But I do have to have a way to allow the elements themselves to be focusable and not get false validation errors thrown during sorting and similar operations.

Does that make sense?  If you like, I can include a more full implementation of what we've actually done with the custom ValidationSummary such that you can see firsthand what is being handled and each binding validation error that is caught.

Thanks!
Adam.g

[Ivan Ivanov]

Hi,

Would you please clarify what you mean by mentioning this: "I do have to have a way to allow the elements themselves to be focusable"? As for your custom validation summary, we would like to see it, so you can send us your implementation. Thank you.

All the best,
Ivan Ivanov
the Telerik team

[Adam]

Hey there,

Per your recommendations, I have slightly altered our approach to have the ValidationSummary look at the Tag of our controls if no name is specified.  This allows us to easily retain a unique handle on the control for tracking errors.  This appears to let us get around the column virtualization issue.  However, this still doesn't appear to correct any behavior around the row virtualization.

Per my comment, you will see in the ValidationSummary code that we have to track errors based on a key, and now, with the tag, we still have that key.  With the changes I've made so far, I think the only issue left is the double notification during row virtualization during sorting and the like.  The ValidationSummary now properly focuses the particular cell that the error is thrown from.

Thanks!
Adam.g

[Ivan Ivanov]

Hello,

 Well, I have tested the updated version that you have sent to me in the support ticked and I am no longer able to reproduce multiple errors on sorting. May I ask you whether you are still testing it with the same version, or I am missing something?

All the best,
Ivan Ivanov
the Telerik team