IBindingList.ListChanged and IDataErrorInfo

Posts   
 
    
tomc
User
Posts: 31
Joined: 28-Jun-2006
# Posted on: 31-Aug-2006 22:20:04   

Frans,

I have been having some problems with GUI controls not updating when I use the IDataErrorInfo related methods of the EntityBase2 class, i.e. SetEntityError and SetEntityFieldError. It appears that the IBindingList.ListChanged event is not fired by the EntityViewBase implementation of this interface. I have verified that the MS DataView implementation does fire this event when the respective error setting functions (RowError and SetColumnError) are called. Would it be possible to change your implementation of SetEntityError and SetEntityFieldError to behave in this manner?

Thanks, Tom

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39872
Joined: 17-Aug-2003
# Posted on: 01-Sep-2006 07:36:11   

And you need this because now the error you set isn't shown in the gui?

Frans Bouma | Lead developer LLBLGen Pro
tomc
User
Posts: 31
Joined: 28-Jun-2006
# Posted on: 01-Sep-2006 08:10:59   

Frans,

Yes. Specifically, I am using DevExpress XtraGrid in a master/detail scenario. If I assign a DataSet to the DataSource of the grid, and call the appropriate error setting methods, the errors are displayed without a problem. However, if I assign a LLBLGen EntityCollection with appropriate prefetch relation entities, and call the SetEntityError and SetEntityFieldError methods on entities therein, the GUI does not reflect the changes for the detail entities. I modified the LLBLGen EntityBase2.cs source so that the SetEntityError and SetEntitiyFieldError called OnPropertyChanged and this fixed the problem.

Based on the somewhat ambiguous documentation of the IBindingList.ListChanged event, it is not clear if this event should be fired when an error is set in a class supporting the IDataErrorInfo interface. However, given the fact that MS classes do it and (some) third party GUI libraries behave assuming this is true, I think it is reasonable to follow suit. I would be most appreciative if you agreed ;-)

Tomas

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39872
Joined: 17-Aug-2003
# Posted on: 01-Sep-2006 10:43:57   

Well I won't raise OnPropertyChanged because an error is set, as that's not correct IMHO and it will break applications who act on OnPropertyChanged to do additional logic: I don't know what's done in these eventhandlers.

Listchanged is also a weird way to propagate these errors upwards, I don't think it's related to that event, simply because what if you bind a single entity to a bunch of textboxes... no list.

The reason the datatable raises this event is I think because it causes a bound control to repaint/refresh.

The sad thing with these events is that if I now start raising them without a reason that something has changed, something can break due to that which then falls apart but it's really hard to track down what caused it.

But I'll see what I can do.

Frans Bouma | Lead developer LLBLGen Pro
tomc
User
Posts: 31
Joined: 28-Jun-2006
# Posted on: 01-Sep-2006 20:08:58   

If there are changes taking place around the IDataErrorInfo implementation and related methods, would it be possible to make the SetEntityError and SetEntityFieldError methods to virtual? This could be useful when there is a need to perform some custom behaviour.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39872
Joined: 17-Aug-2003
# Posted on: 04-Sep-2006 10:36:14   

Making them virtual is indeed the best option. I've made them virtual in the next build (060904)

Frans Bouma | Lead developer LLBLGen Pro