Jeff wrote:
Otis wrote:
Just like the 2003 way: grid.DataSource = collection;
Do you get errors or just no data?
Yes, that works, but it doesn't take advantage of the winforms visual designer. For example, you can click on the SomethingEntity and the visual designer allows you to easily attach individual entity elements to the textboxes. Or... you can click on a TypedList and you visually bind a read-only list to a VS.Net 2005 datagrid and subsequently visually manipulate the columns of the grid.
Unfortunately, there is no way to select an EntityCollection in the visual designer, so you don't that the luxury of binding the collection visually. It's a minor issue, but one that would be great we could do it.
Yes you can. First create a datasource from the entity collection, then bind to that datasource. At least that's how I tried it.
VS.NET uses an additional way of design time databinding: objectdatasource, which requires some code in teh collection's which isn't there yet (at least that's my understanding). Also, it seems (but there is very little to no information available about this yet) that the design time databinding code also utilizes .xsd's as I could bind a grid visually to a datasource made from an entity collection, though I couldn't create a form with textboxes bound to that datasource by simply dragging it onto a form, while with a dataset this is possible.
Marcus wrote:
Frans... is it time to update http://weblogs.asp.net/fbouma/articles/115837.aspx
Heh
I would if I knew what was changed...
That's the core gripe I have with databinding from Microsoft: it's designed by not that smart people who think everyone who doesn't use datasets can go take a hike.
There is very little documentation about it, they designed 'objectdatasource', though there are two versions: one for asp.net and one for winforms and both have these silly 4 CRUD operations defined... like an object datasource supports those always...
Though, ITypedList and IBindingList still work in vs.net 2005. (as 99% of the current software is build on to of those, so it would be stupid to throw them out, they're not THAT stupid
).
That's also one thing which I've never understood: why o why is the design-time code different from the runtime code? I mean: why not bind the collection at design time as you would at runtime, without additional crap (like the property finder crap in vs.net 2003, which hangs itself up in its own recursion, MS promised to get back to me, that was 3 months ago) ?
What I've seen now in vs.net 2005 is that it seems (but I might be wrong, again there is very little documentation available about this, as they hardly document this, because with datasets it works, so why bother?) that an XSD producing piece of code will make sure it works at design time... (as it seems that the design time code works with these xsd's).
Another way of doing things is, which I'll introduce in v2.0 is using a dataview like object, which allows sorting and filtering and which is returned by the object bound.