Bill,
I think that you are trying to make this too complicated. I think that I would first backup and then start rethinking through your process.
First, we use custom columns as aggregates OR create a custom property that dynamically returns aggregates a lot. Now since you are trying to apply a filter, then you will most likely want a column in the data table.
OK. Since we have that established, from what I can understand, you always want to have a calculated column within your data table. So obviously if you perform a query, then you can do this as part of the query (easier and faster in some cases). However, if you will have a scenario that will not retrieve data from a database query first, then you would need to ensure that the column gets manually added prior to being refrenced or accessed. So in this case, I would do one of two things to ensure that the column exists within the BO.
- Override the OnAfterAddNew method of the BO and ensure that the desired columns get added within the BO and/or exist when a new record is added. This way a query is not required, but when you add a new record the BO will ensure that the column exists.
- Override the OnCurrentDataTableRefilled method of the BO and call the same logic that is added as part of the OnAfterAddNew method.
By doing the above two things you will always be ensured that you have the column within your data table, thus allowing a filter to be applied.
At this point, you will just create the custom property on the BO to access it through the strong-typed reference, but you can then treat this column just as though you could any other column that comes from the database, however, it just resides within the BO.