Request for DataPortalResult Event Arg

Request for DataPortalResult Event Arg

Old forum URL: forums.lhotka.net/forums/t/7646.aspx

Jack posted on Wednesday, September 16, 2009

I am continually doing a check to see if my aysnc call worked /w no error and a non-null object was retrieved.  Could we add a single bool to the event argument for:

Completed = e.Error == null && e.Object != null

I've found quite a few times I've made copy/paste issues

Thanks

jack

JonnyBee replied on Thursday, September 17, 2009

Hi,

Csla DataPortalResultEventArgs works very similar to how the Backgroundworkers RunWorkerCompletedEventArgs is defined in .Net.

You could however make your extension method to add a Completed method:

    public static class MyExtensions
    {
        public static bool Completed(this IDataPortalResult arg)
        {
            return arg.Error == null;
        }
    } 

usage:
        private void objecttype_FetchCompleted(object sender, DataPortalResult<objecttype> e)
        {
            if (!e.Completed()) return;

            // do whatever you want with returned object
        }

/jonnybee

RockfordLhotka replied on Thursday, September 17, 2009

That code is incorrect though.

The way you know success/fail is whether Error is null. It doesn't matter what Object is if Error != null.

In fact, the Microsoft implementation throws an exception if you try to access e.Object when e.Error != null, and I probably should have done the same thing...

ajj3085 replied on Thursday, September 17, 2009

I think this would be a good change, for consistency.

Jack replied on Thursday, September 17, 2009

You know I started that way... and somewhere along the line I switched to doing both checks. 

 

I think now that it was because of an earlier issue with the CSLA DataProvider in SL (maybe when it was firing DataChanged twice back in the day) or something but I'm sure I was having an issue where I needed to check both.  I then switched away from the DataProvider and starting just managing my own async calls via the DataPortal and then of course it just mindlessly propagated.

 

I'll put my code back to just check error then but it would be nice to have the re-assurance of the MS implementation and if I find a null Object I'll be certain to run it down.

 

Would that make sense as well in the DataChanged?

 

While my earlier request is not such a big deal now it might still be nice to put in a straight bool for success vs. !=null vs. == null.  If you don't want to then that is fine, I'll take Johnny Bee's advice and plug it in that way.

 

Thanks for the clarification.

 

From: RockfordLhotka [mailto:cslanet@lhotka.net]
Sent: September-17-09 8:50 AM
To: jaddington@alexandergracie.com
Subject: Re: [CSLA .NET] Request for DataPortalResult Event Arg

 

That code is incorrect though.

The way you know success/fail is whether Error is null. It doesn't matter what Object is if Error != null.

In fact, the Microsoft implementation throws an exception if you try to access e.Object when e.Error != null, and I probably should have done the same thing...



Copyright (c) Marimer LLC