C# syntax I wish for

[Shuqian Ying]

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).

Find more in 1-NET: connects your resources anywhere[^]. Email searcher Email Aggregation Manager[^].

[Yasen Dokov]

I like that syntax! Where is the problem in writing a general purpose method that does this? (First time I'm posting here! Hey everyone! :))

[BillWoodruff]

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

[Super Lloyd]

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! :)

A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!

[Super Lloyd]

Glad someone understand! :)

A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!

[BillWoodruff]

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

[Yortw]

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(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 WaitForEvent(this object eventSource, string eventName) where T : EventArgs
{
var tcs = new System.Threading.Tasks.TaskCompletionSource();
var eventInfo = eventSource.GetType().GetEvent(eventName);

		EventHandler eventHandler = null;
		eventHandler = new EventHandler(
			(source, e) =>
			{
				eventInfo.RemoveEventHandler(eventSource, eventHandler);
				tcs.TrySetResult(e);
			}
		);
		eventInfo.AddEventHandler(eventSource, eventHandler);

		return tcs.Task;
	}
}

[Super Lloyd]

Man, I can't upvote this enough! Awesome, as good as it get, love it! :-D

A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!

[Yortw]

Always nice to be appreciated :)

[User 10495434]

your prince code will come and rescue you someday ;P

[Super Lloyd]

It already had!! :omg: :-\ The Lounge[^]

A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!