Not sure I follow. There are three typical ways we do "async" in the framework:
1) Event based async 2) BeginXXX, EndXXX 3) Task The compiler await/async implicitly works with 3). You can also make it work 2) with TaskFactory.FromAsync. Included as part of our package below (as well as compiler support for async/await) are a bunch of extensions methods for various frameworks classes that provides 3) for classes that currently using 1) and 2). For example, if below is WebClient, then instead of calling OpenReadAsync and listening to the events, you can just call OpenReadTaskAsync which returns a Task<T>. From: [email protected] [mailto:[email protected]] On Behalf Of Davy Jones Sent: Sunday, March 3, 2013 12:10 AM To: ozDotNet Subject: Re: Async coding pattern Async/await. = begininvoke endinvoke Tasks = backgroundwork / threadpool Events are still events you can't replace them with the new 4.0 threading. Davy Sent from my starfleet datapad. On 3 mars 2013, at 05:18, David Kean <[email protected]<mailto:[email protected]>> wrote: Why still using event based async, when you can use async/await in Silverlight? http://nuget.org/packages/Microsoft.Bcl.Async/1.0.14-rc From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Greg Keogh Sent: Friday, March 1, 2013 8:54 PM To: ozDotNet Subject: Async coding pattern Folks, I have some skeleton code like this in a Silverlight app: client.GetFooCompleted += (s, e) => { Trace("GetFoo result is {0}", e.Result); }; client.GetFooAsync(rowId); This works fine, but then I noticed that the completion handler code keeps getting added on every call and the completion code runs 1, 2, 3, 4, etc times. Is there an elegant way of rejigging this code to get the correct one-call-one-completion behaviour. Greg
