Custom Properties on Typed Datasets
In .Net 2.0 it's possible to define custom properties for a typed Dataset and retain them when the code is regenerated, thanks to the wonders of partial classes. I was writing a UI prototype recently for a Windows application, and used typed Datasets and TableAdapters to speed up development.
It's always been possible to define an expression for a calculated column in a DataTable, using a syntax that I think is supposed to remind us of SQL. But you're limited in what you can put in there, restricted to a few defined functions. To pick one example, there is, as far as I can tell, no way to specify that the current date be used as one of the expression's operands.
This led me to writing a custom property for my typed DataRow, one that used some business rules about effective dates and anniversary dates to calculate a duration. In Object Explorer, this property looked like all the others. Could I use it in Windows databinding?
The answer appears to be "No", although I haven't found anything written about it one way or the other. But it won't appear in the Property window's field picker, and specifying it leads to an runtime error. I don't know the reason for sure, but I suspect it's because the object you're connecting your controls to when you bind to a DataTable is really a DataView. A custom property on the typed DataRow wouldn't be accessible through a DataRowView.
And this is a pity. When you're writing a little three-day minimum-investment project like my prototype, you want an easy, clean solution, one where you do the hard stuff once if at all and don't lock yourself into any particular architecture. A typed DataRow that could expose bindable custom properties would be a good stand-in for the custom business objects that it's too early in the project to create.
It's always been possible to define an expression for a calculated column in a DataTable, using a syntax that I think is supposed to remind us of SQL. But you're limited in what you can put in there, restricted to a few defined functions. To pick one example, there is, as far as I can tell, no way to specify that the current date be used as one of the expression's operands.
This led me to writing a custom property for my typed DataRow, one that used some business rules about effective dates and anniversary dates to calculate a duration. In Object Explorer, this property looked like all the others. Could I use it in Windows databinding?
The answer appears to be "No", although I haven't found anything written about it one way or the other. But it won't appear in the Property window's field picker, and specifying it leads to an runtime error. I don't know the reason for sure, but I suspect it's because the object you're connecting your controls to when you bind to a DataTable is really a DataView. A custom property on the typed DataRow wouldn't be accessible through a DataRowView.
And this is a pity. When you're writing a little three-day minimum-investment project like my prototype, you want an easy, clean solution, one where you do the hard stuff once if at all and don't lock yourself into any particular architecture. A typed DataRow that could expose bindable custom properties would be a good stand-in for the custom business objects that it's too early in the project to create.
posted by Ann at 5:17 PM
4 Comments:
I wonder if there's just an attribute that you need to specify on your custom property that makes it visible to the designer.
The only attribute the generated properties had was System.Diagnostics.DebuggerNonUserCodeAttribute, so that didn't give me any clues. I may try deleting one of the properties from the generated code and seeing if it still shows up in the designer. That would prove that it was looking to something other than the type definition for its fields.
Check out [System.ComponentModel.Bindable]... I just came across it while looking for something else.
If that doesn't do it, you may want to check out each of the attributes in ComponentModel.
I commented out a property in the generated dataset code. Once compiled, the property no longer appeared in the Object Browser. So it wasn't part of the generated class anymore.
But it still showed up in the designer. And when I bound to it and ran the app, it still worked, even though no property of that name existed in the class it was allegedly binding to. So it's not really binding to the generated class at all.
Post a Comment
<< Home