CslaDataProvider for Silverlight does not raise DataChanged event on initial object instance fetch

Roy Ogborn posted on Monday, August 10, 2009

Here's the scenario:

CslaDataProvider is specified in XAML with IsInitialLoadEnabled="False" and a DataChanged event is specified.

In code behind, in response to a user click, I clear then set some FactoryParameters on the data provider then call _myDataProvider.Refresh(); which in turn invokes the Client side business object's async Get method. This all works without error.

However, when that object returns from the server with data, the DataChanged event never fires in my code behind. This causes the client code behind to not be aware that a new object instance was indeed returned.

On each subsequent call to the same code, clearing FactoryParameters and setting new ones, the DataChanged event does, in fact fire from that point forward. So it fires on the 2nd object instance returned (when user clicks again, selecting a new item) and each time thereafter.

I've worked out a hack such that upon the first time the dataprovider is asked to refresh in code behind, I also call _dataProvider.Rebind(); ... which causes the DataChanged event to fire twice, once with a null object returned, then again with the acutal business object instance returned ... and is quite ugly.

Another data point ... If, on the other hand, on the first time the _dataProvider.Refresh() call for the app, and that the underlying business object's fetch method fails, then the DataChanged event actually does fire the first time through, returning the error. So I know the event handler is wired up already.

I think that the DataChanged event should fire each and every time that the underlying business object's ascync fetch method returns, error or not.

Am I doing something wrong?

I should note I'm using v. 3.7.1 of CslaLight.

Thanks.
Roy

cds replied on Monday, August 10, 2009

Hi Roy

I think I ran into a similar problem many months ago when I started using CslaLight. I was frustrated with the lack of events that appeared when using the CslaDataProvider in XAML, and ended up subclassing it and generating my own events when the ObjectInstance property changed.

In hindsight, I think that I was trying to bend the CslaDataProvider in XAML in ways it was never intended to be used.

My policy now is that any code-behind interaction with business objects is done by using the business object classes themselves and their async methods. This way, you get to code a handler that definitely executes once the operation is complete. There's no worrying about trying to attach to events on the provider declared in the XAML. And, crucially, once you've got a result back from your server call, you can just set the ObjectInstance property on the CslaDataProvider and have the UI update via binding.

So, in short, I think perhaps you're taking the wrong approach.

Hope that helps...

Craig

RockfordLhotka replied on Tuesday, August 11, 2009

Can you provide a small isolated repro for this? It sounds like a bug, but obviously there's some difference between what you are doing and what we have in the unit tests.