The sp's in my code were placed in there for initial testing and I never removed them.  My goal was to replace them with calls to the corresponding business objects (which were not created at the time--they exist now). 

I am following you.  Really.  The thing that I am tripping up on is that once I give the DB the job of creating my custom properties (which are not custom properties to the business object anymore...they are actually columns in the remote data table) there remains little benefit to be derived from a custom property in the business object itself.

Well, getting late.  Time to go home.  Got an early and long day tomorrow.

Take care,
Bill

No need to do this - the proc can return whatever you want. I my example the StationType was just part of the WHERE clause but the value being checked was in an associated table not the PUN table itself.

In our PUN table for example we have quite a number of custom fields:

    Protected Overrides Function GetCustomBindablePropertyDescriptors() As MicroFour.StrataFrame.Business.FieldPropertyDescriptor()

        Dim boPUNType As System.Type = Me.GetType()

        Return New MicroFour.StrataFrame.Business.FieldPropertyDescriptor() { _
             New MicroFour.StrataFrame.Business.ReflectionPropertyDescriptor( _
            "OperatorName", boPUNType), _
             New MicroFour.StrataFrame.Business.ReflectionPropertyDescriptor( _
            "INIDescription", boPUNType), _
             New MicroFour.StrataFrame.Business.ReflectionPropertyDescriptor( _
            "INIMaxHides", boPUNType), _
             New MicroFour.StrataFrame.Business.ReflectionPropertyDescriptor( _
            "INIMaxWeight", boPUNType), _
             New MicroFour.StrataFrame.Business.ReflectionPropertyDescriptor( _
            "INIMaxArea", boPUNType), _
            New MicroFour.StrataFrame.Business.ReflectionPropertyDescriptor( _
            "PKBCode", boPUNType), _
            New MicroFour.StrataFrame.Business.ReflectionPropertyDescriptor( _
            "ReceiveBatchCode", boPUNType), _
            New MicroFour.StrataFrame.Business.ReflectionPropertyDescriptor( _
            "FlesherBatchCode", boPUNType), _
            New MicroFour.StrataFrame.Business.ReflectionPropertyDescriptor( _
            "ShortTermBatchCode", boPUNType), _
            New MicroFour.StrataFrame.Business.ReflectionPropertyDescriptor( _
            "TanningBatchCode", boPUNType)}
    End Function

#End Region

Our stored procedures return these values as needed. If we need to add more custom fields we can without breaking any existing code.

Regarding the other question - correct it wouldn't actually delete the rows until you did a BO.Save so you would want to carefull.

The best approach is not to return the data at all.

Cheers, Peter

Thanks so much for an very very useful example.  Coming from a VFP and Visual FoxExpress background I'm very used to thinking in terms of dynamic view parameters and only bringing as many records over the wire as absolutely necessary.  I'm very new to Strataframe and .NET in general and your code has helped a lot to translate some familiar concepts and give me a lot of ideas as to how I want to use the Strataframe framework.

Stuff like this always very much appreciated. 

Actually, no.  There has been a lot of good dialog come from this post and this alone should be evident that there are many different ways to approach a problem.  First of all, if you create a custom property and want to sort on that property, there has to be an underlying column in the CurrentDataTable....you can, as you have seen from Greg and others, pull a faux field as part of your query....or in the CurrentDataRefilled event of your BO, you could progammatically add the columns into the CurrentDataTable so that you could filter on this as well:

You could then, in your custom property, store off the value in the Set (or even the Get of the proper if it is readonly):

Taking this approach you could then sort and filter on the aggregate field.

Thanks, Peter!  I will review your code a bit more to see if I may be missing something. 

Can a user search on these custom fields (e.g. OperatorName="Bill") using the BrowseDialog?  Or, could I use code to sort on one of these fields (e.g. myBO.Sort = "INIMaxWeight DESC")?

Regards,
Bill

Yes, but this will also make the BO dirty and if you do not want the table to be updated back at the server, you will have to AcceptChanges on the CurrentDataTable...otherwise this will be deleted from the server if a Save() is called:

Trent,

I have been known to be quite dense at times.  Sometimes saying something slightly differently fires certain synapses and things start clicking.  For me, it was the word "faux".  Thanks for pulling out the French.  English just wasn't getting through to me.

I will see what I can do with the creation of columns in an sp for the use with my custom properties.  Also, I need to spend some more time with Peter's code.  Looks like a good morning ahead.

Thanks, everyone, for your patience with me.
Bill

No.  The BrowseDialog creates Dynamic queries that are placed against the Database on the server, not the BO.  The BO is not where the query takes place....if you think about it, if the BO were where the query occurred, you would never pull any records back from the server.  So in this instance you will never be able to query on a custom property (unless it has an underlying field on the server that can be queried).