Databind IsDirty All of the Time

bcrowell posted on Saturday, September 12, 2009

I've got a BusinessListBase Collection that i'm binding to a DevExpress grid. For some reason all of the objects come into the grid marked IsDirty. I therefore can't make save/apply buttons work properly. Can anyone think of a reason why all of the objects in a collection would be marked as dirty from instantiation? Thanks.

bcrowell replied on Saturday, September 12, 2009

Upon further examination it looks like the objects are being marked dirty when the collection is assigned to a bindingsource. So in the following code:

_custs = _custs.GetCustomers
#1)
BSCustomers.DataSource = _custs
#2)
grdCusts.DataSource = BSCustomers
--------------------------------

At #1 the _custs collection are not dirty. But when we get to #2 all of the objects are marked as dirty. So the grid is not the problem but i'm still at a loss.

rfcdejong replied on Saturday, September 12, 2009

U say that at #1 the items in the collection aren't dirty, u sure? Else it would had been a MarkClean() issue.

But what is the BSCustomers?

U could set breakpoints in each property setter and watch at the call stack who is to blame for it.

bcrowell replied on Saturday, September 12, 2009

Yes, I see the change as I step through the code. BSCustomers is a binding source that I later set as the datasource of a datagrid.

So i guess the question is if there's any reason that setting a csla collection to the datasource of a winforms binding source would cause the items to become dirty?

JonnyBee replied on Sunday, September 13, 2009

Hi,

When you connect the databinding you may also trigger changing of properties.

That is especially true if you use ComboBox'es in your form. The sequence of Bind/Unbind is critical an you must bind the datasource for the list items first - and if not you will find that the ComboBox resets the datavalue to the defaultvalue of the datatype.

Attach a OnPropertyChanged/OnChildChanged eventhandler to your BO and you will find which property that gets changed.

If you are using managed fields you can also look into the FeldList in FieldManager a find the field that is Dirty.

/jonnybee

lukky replied on Sunday, September 13, 2009

ComboBoxes are evil !!!

bcrowell replied on Monday, September 14, 2009

Yes, I think you've got it. It's when I bind the datasource to the DevExpress datagrid that some properties are changed and thus everything becomes dirty.

This is really lousy. I don't see a way around this while still using this grid control. I guess I'll have to use a readonly collection in the grid and then load up an editable object from the database for the detail form once a selection is made.

If anyone has a better idea that would be great. If the clean/dirty functionality is flaky then it may be time to just go to a WCF Rest data access model and forget CSLA. I hope not.

Fintanv replied on Tuesday, September 15, 2009

So the question I would have is "Why are the properties changing?"

 

Tom_W replied on Tuesday, September 15, 2009

bcrowell:

when I bind the datasource to the DevExpress datagrid that some properties are changed and thus everything becomes dirty.

One thing to note is that I don't think setting a property to the same value it had previously causes a business object to become dirty in CSLA.  (I just tested this in our code by re-typing the existing value for a field over the existing value for that field in both a text box and the grids, and the record didn't become dirty.)  That would strongly suggest that the data in your collection is actually changing and therefore the collection is correctly reporting that it is dirty.

Which properties go dirty, is it all of them or just some, and if so what is common to the dirty ones (i.e. are they all combos, dates, nullable types etc?).

That should be easy enough to test, just look at the values of the collection before and after stage 2 (in your earlier post) and see if they are definitely still the same.  If not, as Fintanv says, what's changed and why is the key question.

Could this be an issue with how the grid is handling null values in your collection?  We use the infragistics grids and nulls can be problematic.  If for example you havea dropdown list (i.e. one where the value of the underlying field must match an entry in the list) and the value in the underlying field is a null, but the list doesn't allow a null, then the list can sometimes change the value of the underlying field (because null isn't an entry the list permits).  This will obviously cause the collection to become dirty.

Other potential null issues are what the grid (or the editor controls within the grid) do when they encounter a null value, in the Infragistics grids you can set what value the editor controls set for a 'null' value (e.g. empty string, null, dbnull, etc) - is there any chance that the grid could be swapping the types of your nulls and causing a change to the data.  That can be hard to spot as at first glance it doesn't look like the data has changed.