ok nevermind, i am posting too fast or thinking too slow today :P

Lists are reference objects so won't be necessary to do that much work i was just doing a wrong type conversion.

So problem solved :)

edit: FACADE Pattern, now i get it :P

I don't know why but coded it to copy the object in memory no to use the same1, i hope the coffe machine is repaired tomorrow ;)

Thanks for the reply Cobaia.

I have come to the same conclusion and coded a wrapper class mostly like you said. 
It feels like a waste of resources, i think would be much easier and effective to add EntityCollection and EntityObject to the methods that populate the grid, but it works.

Also i still have the problem with editable grids. Some validations are performed on property setters in the model. Is not impossible to achieve the same with the binding lists using some events and reflection but i really would love to see EntityFramework supported in future releases.

BTW we just bought the suit, it has some great controls, and the grid is very good even with those problems.

The way I understand it, the ultragrid will show all public properties as columns and all public list properties as bands.  If a public property is anything other than something simple like a string or a number (i.e. a property that is another complex class) then it displays a column of essentially garbage.

Perhaps you have already considered it, but what about a wrapper class that takes an instanse of Person for binding to the grid?  The Person wrapper class could then have a BindingList that contains the one Address member of the innner Person class. (facade pattern?)

Having data that binds to the grid in the format you want it displayed may make your life easier and your app more maintainable down the line.

Thanks for the reply.

If it was possible to add a childband programatically i can code an extension to populate the grid, but the model is related to database model, automated test builders and more,  so i can't change it just for that.