|
|
Girls Just Want To Have Fun
Mongo: Mongo only pawn... in game of life.
|
|
|
|
|
|
|
Why not post this on the C# language forum for discussion ?
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
Never got that feeling of "Hey, I have just achieved something that only a programmer can understand", sitting alone at your desk ?
That's why.
|
|
|
|
|
It's not really a question at all...
Just some meta.. programatical musing...
|
|
|
|
|
If it looks like code, smells like code, and walks like code, I think it's code, and having this kind of discussion here means that in the long run CodeProject will not benefit as much as if the discussion were in the language forum ... because this kind of content gets "drowned" in the flood of Lounge posts.
It's an interesting topic, and becoming a compelling conversation.
cheers, Bill
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
It would seem to me that this would be more appropriate as a Task continuation, rather than as a blocking call inside a task. By the way, language proposals are now made on the Roslyn[^] site.
This space for rent
|
|
|
|
|
I don't understand your message Pete, what blocking call are you talking about?
My method effectively turn waiting for that particular next event into a task, which one can await or .Wait(), up to you!
(though I do suggest await)
|
|
|
|
|
The blocking call I'm talking about is you waiting for the event. You're waiting for that to happen before you continue. If you are dependent on this, it just feels more natural that this would be a task continuation.
This space for rent
|
|
|
|
|
well... this is exactly the same thing, just different syntax (i.e. nice C# syntactic sugar), no?!
when I write:
await WaitForThatEvent()<br />
DoSomethingAfterward()
The compiler generate (roughly.. there is cancellation to consider)
WaitForThatEvent().ContinueWith(t => DoSomethingAfterward());
Isn't that nice?! 
modified 27-Sep-16 3:31am.
|
|
|
|
|
How is different to subscribing to an Event and do your stuffs in Event Handlers.
method()
{
WhatEver.MyEvent += (myArgs) => {
}
}
Please help me understand if you are looking for something different which cannot be handled by Events and Delegates (Lambda expressions also simplifies your syntax).
I might have different thought process and not able to understand what exactly you are looking for. 
Life is a computer program and everyone is the programmer of his own life.
|
|
|
|
|
How is that different? It is better looking!
turning that basic version
EventHandler ev = null;
ev = (o, e) => {
source.Event -= eh;
DoSomething();
};
source.Event += eh;
into that elegant version
await source.Event.WaitForEvent()
DoSomething();
Can't you appreciate the beautiful simplicity and easier code flow of the second version?! 
Added bonus: DoSomething() will try to be in the same thread as the start of the method!!
modified 27-Sep-16 3:22am.
|
|
|
|
|
Yeah, your elegant version look cool while reading. accepted.
But, I personally don't have problem with this too:
source.Event += (o, e) => {
source.Event -= eh;
DoSomething();
};
Your elegant version might get complex when you would have to pass the parameters that DoSomething uses.
oArgType o;
hArgType h;
await source.Event.WaitForEvent(out o, out h);
DoSomething(o, h);
Also, I feel that the generic implementation of "your elegant version" can be achieved by an extension method. I would try to do that in my free time and would post as a reply here.
But nice thought, I appreciate it. 
Life is a computer program and everyone is the programmer of his own life.
|
|
|
|
|
On the contrary after some practice with async methods you will see how they simplify all your code, not the opposite. Added bonus code after await is in the initial thread, when possible.
One downside of async method is that they don't take out/ref parameter.
But if you want the event args, here is another version that return the event
public static Task<GpsLocationArgs> WaitForLocationChangedAsync(this IGps gps)
{
var res = new TaskCompletionSource<GpsLocationArgs>();
EventHandler<GpsLocation> eh = null;
eh = (o, e) =>
{
gps.LocationChanged -= eh;
res.TrySetResult(e);
};
gps.LocationChanged += eh;
return res.Task;
}
var loc = await myGps.WaitForLocationChangedAsync();
Console.WriteLine($"({loc.Latitude}, {loc.Longitude})");
sadly, as I complained, it is NOT possible to write a general purpose WaitForEvent() method.. 
But give it a go, maybe using some LINQ expression magic and some reflection you can come up with a reasonably easy and elegant version....
|
|
|
|
|
I believe you're correct in that you can't do this on the event itself, but you could make something nearly as good (depending on your definition of 'nearly as good').
await source.WaitForEvent<EventArgs>(nameof(source.Event));
Would be possible. Using nameof in VS2015 means you have any issues with refactoring, though it is a bit uglier than your preferred syntax.
Something like the following would implement the method (and returns the EventArgs if you need them). An alternate overload would be needed for non-generic event handler based evevents, but that's not hard.
public static class EventExtensions
{
public static Task<T> WaitForEvent<T>(this object eventSource, string eventName) where T : EventArgs
{
var tcs = new System.Threading.Tasks.TaskCompletionSource<T>();
var eventInfo = eventSource.GetType().GetEvent(eventName);
EventHandler<T> eventHandler = null;
eventHandler = new EventHandler<T>(
(source, e) =>
{
eventInfo.RemoveEventHandler(eventSource, eventHandler);
tcs.TrySetResult(e);
}
);
eventInfo.AddEventHandler(eventSource, eventHandler);
return tcs.Task;
}
}
|
|
|
|
|
Man, I can't upvote this enough!
Awesome, as good as it get, love it! 
|
|
|
|
|
Always nice to be appreciated
|
|
|
|
|
By the way, the more I think about this, you can do what you want rather elegantly, using RX. If you view an event as an Observable, then it would be fairly simple to just observe that event and react to it. When I have a couple of free minutes, I'll write you a general purpose example that shows how to do this (and to wait for pretty much any event).
This space for rent
|
|
|
|
|
Your code is eagerly awaited
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
Reactive use a lot of callback as far as I remember...
What I am trying is to make the code seemingly linear and callback free, using await..
(handy for try/catch, easier to understand the flow as well)
that said.. I would be curious to see what you come back with!
|
|
|
|
|
I understand what you mean. We also have been using such a pattern (your less elegent one) for sometimes.
The event property of an object is essentially a list of handlers for the event, which is designed before the introduction of async/await syntax for asynchronous programming. So it would be "un-natural" to have a method for it at the time.
But yeah, I would also vote for something like that for events to complete the circle (for the introduction of async/await syntax).
|
|
|
|
|
Glad someone understand!
|
|
|
|
|
your prince code will come and rescue you someday <maybe>
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
Obvious 
