> in the grid I need to add a column with a calculated value (from data in the entity).

Hi Craig, I think I'm about a month ahead of you here!

> It's not 100% clear to me yet whether the grid is binding to the actual entity list, or drilling in a bit and binding to a dataset behind the scenes.

As far as I can tell, it secretly binds to the dataset. I tried adding a calculated property to the Entity class, like this:

 public decimal? ExtendedPrice
 { get { return this.Quantity * this.Price; } }

It didn't work until I changed the query that populated the Entity list to also include an "ExtendedPrice" column .. then it showed up, but if the price or quantity were changed, the computed column did not.

The approach I've found that works best is to add a custom method to the bizobj that returns a data table, then bind to the data table

For example (this one calls a stored procedure but direct would work):

public virtual DataTable GetOrderHistoryView(int? OrderID)
        {
          //  DataSet ds = new DataSet();
            this.FillDataSet(this.GetCurrentDataSet(),
                "OrderHistoryView", "OrderHistoryView", CommandType.StoredProcedure,
                CreateParameter("@OrderID", OrderID )
                , CreateParameter("@FmtOnly", (OrderID==null))
            );
            return this.GetCurrentDataSet().Tables[0];
        } // GetOrderHistoryView

Make sure this is called from HookParentRetrieved or whatever is appropriate. Also, make sure you are filling a data table in the CURRENT dataset since I've found MM.NET code starts going potty if you have more than one dataset per bizobj.

Then in the property sheet for the grid..

BindingSource = "OrderHistory"; // bizobj class name
BindingSourceMember = "OrderHistoryView"; // datatable name

and for each column set DataPropertyName to the column name.

This approach also has the big advantage that you can automatically do lookups on the query side .. for my particular example it does joins to show PersonName instead of PersonID and so forth - you're not limited to the structure of the entity class.

The disadvantage of it is that it is read-only unless you are willing to write a lot of code to support writing changes back. But usually that's been ok.

There are a few other ways to do this, but this seems to work pretty good even though it is 'old-style' (datasets) not 'new-style' (entity lists). Entity lists just don't work well for complex combinations in a grid - something SQL is made for.

I'm open to any suggestions from anyone else .. I'm not entirely happy with some of the coding under here. Especially when you start wanting read-write. I also haven't solved showing totals under the grid, apart from kludges like using a separate SQL query or post-scanning the dataset (but might switch to the DevExpress controls first before attempting to solving that one).

Cheers,
Walter