[Solved] Radgrid binds clones of objects to grid, why?

[Timothy Robbins]

If I bind a generic List of my business objects (which implement ICloneable)
why is it that when the list is bound, it binds a myObject.Clone() to the list instead of the actual object?

Is there a way to disable this functionality?
Your docs say DataSource behaves the same. asp.net Datagrids do not do this.

[Vlad]

Hi Timothy,

RadGrid is using internally ADO.NET (needed for automatic filtering, sorting, grouping, hierarchy, etc.) which checks for ICloneable interface and calls the Clone() method. Standard MS DataGrid does not support such operations and that is why does not need call this method.

Sincerely yours,
Vlad
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

[Timothy Robbins]

Since I *don't* use ADO.net for my persistence mechanism, is there any way that I can use your grid without using the ADO stuff to prevent Clone() being called? I don't mind reading through the Sort and Filter properties to handle them myself in the DataNeeded event, I am used to having to do that. 

A TON of people use NHibernate and other ORM tools, the new Linq to Entities stuff in 3.5 would be similar I imagine. This makes the grid useless if we want to stay with ORM.

[Vlad]

Hi Timothy,

RadGrid can be bound to any of these data-sources without any problem, including Linq, NHibernate, LLBLGen, EntitySpaces, etc ? I'm not sure how Clone() is related to these? Can you elaborate more? There are differences also on how the grid is bound - using DataSource directly or via DataSourceControl.

Kind regards,
Vlad
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

[Timothy Robbins]

Sure, it may work fine if you dont implement ICloneable on your business objects.

Part of our business model involves, for convenience, Cloning an inventory item. In order to do this easily, considering there are deeply nested properties and such, I inherit ICloneable, and write my method which creates a deep copy of the object, also setting the ID's to 0 (one of several ways NHib and other ORMs out the determine an object is new). One of the things done during the cloning is to set Item.Name +=  " (copy)".

Really quite minor, not a huge deal. Until I get to binding to your grid.

If you are familiar with NHibernate and lazy loading, you'll love this.  Since my Clone is a deep copy, all the lazily loaded objects that should not have loaded for that bind to a grid, are now loaded , which leads to some fairly large and useless db calls, not to mention that that all my items now have a (copy) at the end of the name, as well as an ID that is 0, instead of my original ID.

If your grid did a truly shallow Object.MemberwiseClone() then this would be a non-issue.

Assuming and relying on an *Interface* based call to have the same behavior is bad ju-ju, wouldn't you say? MemberwiseClone, however is NOT an interface based call, and would behave the same across the board. I would have to specifically override it to give it different behavior. In that case, shame on me if it doesn't work right.

[Vlad]

Hi Timothy,

You are right. We fixed this immediately and the fix will be part of the upcoming service pack which is scheduled for Monday next week.

I have attached small example to illustrate you the correct work of latest build.

All the best,
Vlad
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

[Timothy Robbins]

You guys are awesome!


Most other companies would give the runaround on discovery of a bug like this. Not you guys, you fix the bug, for a release pending next week even. Simply amazing. I salute you.