From c6f714c4a476399ca568606a3ecc10efc0a8f2b0 Mon Sep 17 00:00:00 2001 From: "Mark Wiemer (MSFT)" <80539004+mwiemer-microsoft@users.noreply.github.com> Date: Wed, 17 Jun 2026 16:04:23 -0700 Subject: [PATCH 1/3] Change heading to sentence case Matches Microsoft style guide and other articles in this section. --- docs/csharp/distinguish-delegates-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/csharp/distinguish-delegates-events.md b/docs/csharp/distinguish-delegates-events.md index aa8d5ddee749c..b266f8f99d7c9 100644 --- a/docs/csharp/distinguish-delegates-events.md +++ b/docs/csharp/distinguish-delegates-events.md @@ -4,7 +4,7 @@ description: Learn the difference between delegates and events and when to use e ms.date: 03/11/2025 ms.subservice: fundamentals --- -# Distinguishing Delegates and Events +# Distinguishing delegates and events [Previous](modern-events.md) From 64c02b94cf78a8e370212298ca38bde9239c96ce Mon Sep 17 00:00:00 2001 From: "Mark Wiemer (MSFT)" <80539004+mwiemer-microsoft@users.noreply.github.com> Date: Wed, 17 Jun 2026 16:08:11 -0700 Subject: [PATCH 2/3] Make all headings sentence case Co-authored-by: Mark Wiemer (MSFT) <80539004+mwiemer-microsoft@users.noreply.github.com> --- docs/csharp/distinguish-delegates-events.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/csharp/distinguish-delegates-events.md b/docs/csharp/distinguish-delegates-events.md index b266f8f99d7c9..3ca60fdd780ad 100644 --- a/docs/csharp/distinguish-delegates-events.md +++ b/docs/csharp/distinguish-delegates-events.md @@ -14,7 +14,7 @@ Both offer a late binding scenario: they enable scenarios where a component comm With all those similarities, it's easy to have trouble determining when to use which. -## Listening to Events is Optional +## Listening to events is optional The most important consideration in determining which language feature to use is whether or not there must be an attached subscriber. If your code must call the code supplied by the subscriber, you should use a design based on delegates when you need to implement callback. If your code can complete all its work without calling any subscribers, you should use a design based on events. @@ -22,22 +22,22 @@ Consider the examples built during this section. The code you built using `List. Consider the `Progress` event. It reports progress on a task. The task continues to proceed whether or not there are any listeners. The `FileSearcher` is another example. It would still search and find all the files that were sought, even with no event subscribers attached. UX controls still work correctly, even when there are no subscribers listening to the events. They both use designs based on events. -## Return Values Require Delegates +## Return values require delegates Another consideration is the method prototype you would want for your delegate method. As you saw, the delegates used for events all have a void return type. There are idioms to create event handlers that do pass information back to event sources through modifying properties of the event argument object. While these idioms do work, they aren't as natural as returning a value from a method. Notice that these two heuristics can often both be present: If your delegate method returns a value, it affects the algorithm in some way. -## Events Have Private Invocation +## Events have private invocation Classes other than the one in which an event is contained can only add and remove event listeners; only the class containing the event can invoke the event. Events are typically public class members. By comparison, delegates are often passed as parameters and stored as private class members, if they're stored at all. -## Event Listeners Often Have Longer Lifetimes +## Event listeners often have longer lifetimes The longer lifetime of event listeners is a slightly weaker justification. However, you might find that event-based designs are more natural when the event source is raising events over a long period of time. You can see examples of event-based design for UX controls on many systems. Once you subscribe to an event, the event source can raise events throughout the lifetime of the program. (You can unsubscribe from events when you no longer need them.) Contrast that with many delegate-based designs, where a delegate is used as an argument to a method, and the delegate isn't used after that method returns. -## Evaluate Carefully +## Evaluate carefully The above considerations aren't hard and fast rules. Instead, they represent guidance that can help you decide which choice is best for your particular usage. Because they're similar, you can even prototype both, and consider which would be more natural to work with. They both handle late binding scenarios well. Use the one that communicates your design the best. From f3f1260a43aa337d5bb355a533935ca09bb4f677 Mon Sep 17 00:00:00 2001 From: Bill Wagner Date: Thu, 18 Jun 2026 09:06:51 -0400 Subject: [PATCH 3/3] Apply suggestions from code review Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- docs/csharp/distinguish-delegates-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/csharp/distinguish-delegates-events.md b/docs/csharp/distinguish-delegates-events.md index 3ca60fdd780ad..53cad03b4a799 100644 --- a/docs/csharp/distinguish-delegates-events.md +++ b/docs/csharp/distinguish-delegates-events.md @@ -4,7 +4,7 @@ description: Learn the difference between delegates and events and when to use e ms.date: 03/11/2025 ms.subservice: fundamentals --- -# Distinguishing delegates and events +# Delegates vs. events [Previous](modern-events.md)