I am studying events in C# but there are not much articles or information that show me where or what kinda position I'd need to use events in.
Could some one give me real world example that makes them more understandable.
Thanks in advance.
As Chris Gray said, one use is to signal when something has happened that your code didn't directly call. The most common cause here is probably user actions on the GUI. Another example might be an asynchronous operation completing on another thread.
The other reason to use events is when you don't know who might be interested in what has just happened. The class raising the event doesn't need to know (at design time) anything about how many instances of what other classes might be interested.
class Raiser {
public DoSomething() {
//Do something long winded.
OnDidSomething(new DidSomethingEventArgs());
}
public EventHandler<DidSomethingEventArgs> DidSomething;
private OnDidSomething(DidSomethingEventArgs e) {
if (DidSomething != null)
DidSomething(this, e);
}
}
Obviously, you also need to define the DidSomethingEventArgs class which passes on the relevant data about the event. This also illustrates a common naming convention for events. If the event is called X, then the event is only ever raised in a method called OnX and any data it passes on is an instance of class XEventArgs. Note that an event can be null if no listeners are subscribed to it, hence the check just before we raise the event.
Note that this class knows nothing about what other classes might be interested in the fact that it did something. It simply announces the fact that it has done it.
Multiple classes can then listen out for the event:
class ListenerA {
private Raiser r;
ListenerA(Raiser r) {
this.r = r;
r.DidSomething += R_DidSomething;
}
R_DidSomething(object sender, DidSomethingEventArgs e) {
//Do something with the result.
}
}
And:
class ListenerB {
private Raiser r;
ListenerB(Raiser r) {
this.r = r;
r.DidSomething += R_DidSomething;
}
R_DidSomething(object sender, DidSomethingEventArgs e) {
//Do something with the result.
}
}
Now, when the DoSomething method is called on the Raiser instance, all instances of ListenerA and ListenerB will be informed via the DidSomething event. Note that the listener classes could easily be in different assemblies to the raiser. They need a reference back to the raiser's assembly but it doesn't need a reference to its listeners' assemblies.
Note that the above simple Raiser example may cause you some problems in a multi-threaded program. A more robust example would use something like:
class Raiser {
public DoSomething() {
//Do something long winded.
OnDidSomething(new DidSomethingEventArgs());
}
#region DidSomething Event
private object _DidSomethingLock = new object();
private EventHandler<DidSomethingEventArgs> _DidSomething;
public EventHandler<DidSomethingEventArgs> DidSomething {
add { lock(_DidSomethinglock) _DidSomething += value; }
remove { lock(_DidSomethinglock) _DidSomething -= value; }
}
OnDidSomething(DidSomethingEventArgs e) {
EventHandler<DidSomethingEventArgs> handler;
lock (_DidSomethingLock)
handler = _DidSomething;
if (handler == null)
return;
try {
DidSomething(this, e);
} catch (Exception ex) {
//Do something with the exception
}
}
#endregion
}
This ensures that another thread adding or removing a listener while you are in the middle of raising the event doesn't cause problems.
The simple listeners used here will also cause memory leaks if instances of the listener classes are being created and destroyed. This is because the Raiser instance gets passed (and stores) a reference to each listener as they subscribe to the event. This is enough to prevent the garbage collector from properly tidying up the listeners when all explicit references to them are removed. The best way round this is probably to make the listeners implement the IDisposable interface and to unsubscribe from the events in the Dispose method. Then you just need to remember to call the Dispose method.
The most practical example I generally see is User Interactivity. Let's use a Button as a specific example. When the button is clicked, you obviously want something to happen. Let's say we call "SaveSettings()". However, we don't want to hard-code "SaveSettings()" into the button. The buttom would be commanding SaveSettings() to occur. Obviously, this prevents the button from being reusable - we can't use a button which calls SaveSettings() anywhere but the settings dialog. To avoid writing the same button code for every button, each one calling a different function, we use an event.
Instead of the button calling a function directly, the button announces that it has been clicked. From there, the button's responsibility is over. Other code can listen for that announcement, or event, and do something specific.
So in our SaveSettings example, the settings dialog code finds the "OK" button and listens for its "I got clicked" announcement, and when it is fired, calls SaveSettings().
Events can become very powerful because any number of different listeners can wait for the same event. Many things can be invoked by the event.
Sure thing. think of an event as the notification that occurs when something completes in the system that your code didn’t directly call. In C# it's really easy to get code to run when an event "fires"
For example when a user presses a button an event will be raised or when a background network operation completes. In C# you use the += semantics to attach to the event that will be “signaled” when the event fires.
I made you a simple C# winforms program – in it I added a button using the Visual Studio “Designer” (I just dragged a button from the Toolbox to the Window).
You’ll see the line “button1.Click” – in this case I want to do something when the “Click” event is raised.
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
namespace events
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
button1.Click += new EventHandler(button1_Click);
}
void button1_Click(object sender, EventArgs e)
{
MessageBox.Show("Hi!");
}
}
}
You’ll also see other kinds of events in practice for example:
Network operation has completed (WebClient.DownloadFileCompleted)
User Interfaces (resizing windows for example)
Timers (set off the timer in 10 minutes)
Let's say you are developing a UI. You create a widget and you add it to the main form. When something happens in your widget, you can use events to trigger some action on the form - disabling other buttons, etc.
Just like how a button's click event works.
Related
I am trying to understand events and delegates and after 2 days of studying, it looks like I am still lost in basic understanding.
I wrote following code - class UserControl contains event definition. It works well, although the program is stucked in Start() method.
How for example buttonClick event is implemented? Does button object running in some kind of different thread - on order to be able to call a method whenever the button is clicked?
Thanks
class UserControl
{
public delegate void methodsControlDelegate();
public event methodsControlDelegate methods;
public void Start()
{
while (true)
{
if (methods != null)
{
Thread.Sleep(1000);
this.methods();
}
}
}
}
class Program
{
static void Main()
{
UserControl uc = new UserControl();
uc.methods += eventMethod;
uc.Start();
}
public static void eventMethod()
{
Console.WriteLine("EVENT METHOD");
}
}
EDIT:
I have modified the code for Windows Forms.
class Writer
{
public string Text { get; set; }
public void writeMessage(object sender, EventArgs e)
{
MessageBox.Show(Text);
}
}
static class Program
{
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
UserControl userControl = new UserControl();
Writer writer = new Writer();
userControl.WriteMessages += writer.writeMessage;
writer.Text = "HELLO, HOW ARE YOU";
}
}
class UserControl
{
public delegate void EventHandler(object sender, EventArgs e);
public event EventHandler WriteMessages;
}
I am trying to understand events and delegates and after 2 days of studying, it looks like I am still lost in basic understanding.
Take a step back.
class Customer
{
private string name;
public string Name { get { return this.name; } }
public Customer(string name)
{
this.name = name;
}
}
A property is logically a property of the class of things. Customers have a name, so Customers have a property Name.
A field is an implementation detail. It is a variable that can store a value.
A type is an implementation detail of a field or property; it gives you a restriction on what kind of data can be used as a value for this property.
The value -- say "Barbara Smith" -- is the value associated with that property for a particular customer: new Customer("Barbara Smith").
If that is not all clear then you need to take a step back and understand that. You won't get events and delegates if you haven't got properties, fields and values down.
An event is like a property. It is a logical feature of a class of things. Buttons can tell you that they are clicked, so Click is an event of Button. The button will call you when it is clicked.
A delegate type is a restriction on how the button may call you when it is clicked.
A delegate instance is a delegate to a particular function that will be called when the button is clicked.
Is that now clear?
How for example buttonClick event is implemented?
Understanding that requires you to understand how Windows works.
Every Windows program has a message queue which receives messages from the operating system. When the user clicks a button, Windows puts a message in the queue for that process that says the button was clicked. When the process handles that message, taking it out of the queue, it invokes the delegate associated with the click handler for the button.
Does button object running in some kind of different thread - on order to be able to call a method whenever the button is clicked?
Nope. If you hang the UI thread of your program so that it cannot remove the message from the queue then the button click handler is never invoked.
In fact it is illegal to call code in the button from any thread other than the UI thread.
Every time you've seen a Windows app hang, it's almost certainly because some badly-written code did not allow the message loop to take a message out of the queue in a timely manner.
You then go on to post some code with no explanation and no question. I don't know why you posted that code. Try asking a more clear question.
That said, looking at the code you seem to be trying to do event handling from a console application. Don't do that. Console applications are not event-driven. Write a WinForms or WPF application if you want to make an event-driven application.
delegate is an encapsulation on top of a method. It allows you to pass a method around, as a reference and execute it whenever you decide. The delegate defines a signature of a method and any method which is of the same signature can be used as that delegate.
events are one more level of encapsulation, this time on top of delegates. It allows adding and removing (subscribing and unsubscribing) methods to it. And when the event fires, it will invoke each one of the added to it methods (delegates). This encapsulation is necessary, so that one 'client' of the event cannot override another client to the same event.
I'm starting out in C#, coded a lot in Java but having some trouble here. I'm trying to learn how to use MouseKeyHook for an application I'm developing. I cannot get the actual listener to fire off an event. Here's my listener code:
using System;
using System.Windows.Forms;
using Gma.System.MouseKeyHook;
namespace ChromaHeatmap
{
class keyListener
{
private IKeyboardMouseEvents m_GlobalHook;
public void Subscribe()
{
// Note: for the application hook, use the Hook.AppEvents() instead
m_GlobalHook = Hook.GlobalEvents();
m_GlobalHook.KeyPress += GlobalHookKeyPress;
}
private void GlobalHookKeyPress(object sender, KeyPressEventArgs e)
{
Console.WriteLine("blah");
}
public void Unsubscribe()
{
m_GlobalHook.KeyPress -= GlobalHookKeyPress;
//It is recommened to dispose it
m_GlobalHook.Dispose();
}
}
}
And here's the part of my application code where I attempt to do something with the listener. If anyone can let me know what the best way is to loop here and wait for events, I'd appreciate it.
//Listen for key presses
keyListener heyListen = new keyListener();
heyListen.Subscribe();
while(true)
{
}
while(true) {}
This is a hold-and-catch-fire statement, the thread will burn 100% core and cannot execute the hook callback. You'll notice that the machine goes dead for 5 seconds when you press a key, the operating system is waiting for an opportunity to invoke the callback. But it won't wait forever and unceremoniously will destroy the hook so you regain control over the machine. Also the kind of mishap that will occur when you try to debug your event handler.
Windows needs an opportunity to safely call the hook callback. That requires your program to be "idle", not executing any code. The technical term for this is "pumping the message loop", your program must wait for a notification from the operating system that something interesting happened.
A very simple way is to use the Winforms project template as-is, you'll also get a window. Note how the Main() method in the project makes the call that you need instead of the while() loop. You must call Application.Run().
Check this post for code that avoids displaying a window.
I am currently debugging a big (very big!) C# application that contains memory leaks. It mainly uses Winforms for the GUI, though a couple of controls are made in WPF and hosted with an ElementHost. Until now, I have found that many of the memory leaks were caused by events not being unhooked (by calling -=) and I've been able to solve the problem.
However, I just came across a similar problem. There is a class called WorkItem (short lived) which in the constructor registers to events of another class called ClientEntityCache (long lived). The events were never unhooked and I could see in .NET profiler that instances of WorkItem were being kept alive when they shouldn't because of those events. So I decided to make WorkItem implement IDisposable and in the Dispose() function I unhook the events this way:
public void Dispose()
{
ClientEntityCache.EntityCacheCleared -= ClientEntityCache_CacheCleared;
// Same thing for 10 other events
}
EDIT
Here is the code I use for subscription:
public WorkItem()
{
ClientEntityCache.EntityCacheCleared += ClientEntityCache_CacheCleared;
// Same thing for 10 other events
}
I also changed the code for unregistering to not call new EntityCacheClearedEventHandler.
END OF EDIT
I made the calls to Dispose at the proper places in the code that uses WorkItem and when I debug I can see that the function is really being called and I do -= for every event. But I still get a memory leak and my WorkItems still stay alive after being Disposed and in .NET profiler I can see that the instances are kept alive because the event handlers (like EntityCacheClearedEventHandler) still have them in their invocation list. I tried to unhook them more than once (multiple -=) just to make sure they were not hooked more than once but this doesn't help.
Anyone has an idea why this is happening or what I could do to solve the problem?
I suppose I could change the event handlers to use weak delegates but this would require to mess a lot with a big pile of legacy code.
Thanks!
EDIT:
If this helps, here is the root path described by .NET profiler:
lots of things point on ClientEntityCache, which points to EntityCacheClearedEventHandler, which points to Object[], which points to another instance of EntityCacheClearedEventHandler (I don't understand why), which points to WorkItem.
It might be that multiple different delegate functions are wired to the event. Hopefully the following little example will make it clearer as to what I mean.
// Simple class to host the Event
class Test
{
public event EventHandler MyEvent;
}
// Two different methods which will be wired to the Event
static void MyEventHandler1(object sender, EventArgs e)
{
throw new NotImplementedException();
}
static void MyEventHandler2(object sender, EventArgs e)
{
throw new NotImplementedException();
}
[STAThread]
static void Main(string[] args)
{
Test t = new Test();
t.MyEvent += new EventHandler(MyEventHandler1);
t.MyEvent += new EventHandler(MyEventHandler2);
// Break here before removing the event handler and inspect t.MyEvent
t.MyEvent -= new EventHandler(MyEventHandler1);
t.MyEvent -= new EventHandler(MyEventHandler1); // Note this is again MyEventHandler1
}
If you break before the removal of the event handler you can view the invocation list in the debugger. See below, there are 2 handlers, one for MyEventHandler1 and another for the method MyEventHandler2.
Now after removing the MyEventHandler1 twice, MyEventHandler2 is still registered, because there is only one delegate left it looks a little different, it is no longer showing in the list, but until the delegate for MyEventHandler2 is removed it will still be referenced by the event.
When unhooking an event, it needs to be the same delegate. Like this:
public class Foo
{
private MyDelegate Foo = ClientEntityCache_CacheCleared;
public void WorkItem()
{
ClientEntityCache.EntityCacheCleared += Foo;
}
public void Dispose()
{
ClientEntityCache.EntityCacheCleared -= Foo;
}
}
The reason is, what you are using is syntactic sugar for this:
public class Foo
{
public void WorkItem()
{
ClientEntityCache.EntityCacheCleared +=
new MyDelegate(ClientEntityCache_CacheCleared);
}
public void Dispose()
{
ClientEntityCache.EntityCacheCleared -=
new MyDelegate(ClientEntityCache_CacheCleared);
}
}
So the -= doesn't unhook the original one you subscribed with because they are different delegates.
Are you unhooking the right reference? When you unhook using -= no error is produced and if you're unhooking events which aren't hooked nothing will happen. However if you add using += you'll get an error if the event is already hooked. Now, this is only a way for you to diagnose the problem but try adding the events instead and if you DONT get an error the problem is that your unhooking the event with the wrong reference.
Dispose won't get called by the GC if the instance is being kept alive by the event handlers, as it is still being referenced by the source of the events.
If you called your Dispose method yourself, the references would then go out of scope.
Maybe try:
public void Dispose()
{
ClientEntityCache.EntityCacheCleared -= ClientEntityCache_CacheCleared;
// Same thing for 10 other events
}
You are creating a new event handler and removing it from the delegate - which effectively does nothing.
Remove the event subscription by removing reference to the original subscribing event method.
You could always just set your eventhandler = delegate {}; In my opinion, that would be better than null.
I have a web service with two methods:
RetrieveFirstLevelOptions() and RetrieveSecondLevelOptions(int levelOneOption).
The GUI contains two comboBoxes: FirstLevelOptionsCombo and SecondLevelOptionsCombo.
I am having trouble with creating a control flow for the initialization stage when I have to make a request to RetrieveFirstLevelOptions() and then, once the results are in, call RetrieveSecondLevelOptions(default levelOneOption = 0).
The problem is that since everything happens asynchronously I don't know what the best approach is to allow this behaviour take place once and only once, at the beginning.
An option I would love to have is to attach a second event handler to the RetieveFirstLevelOptionsCompleted event and have it remove itself after running only once. But it looks like such a behaviour is impossible to get.
Another option would be to have a boolean flag to indicate whether in Initialization phase and if it is, then the handler for RetrieveFirstLevelOptionsCompleted would execute some additional logic. However this idea makes it look like all event handlers would have to check for state information and do different things depending on the current state. This seems to be bad design because the control flow seems to be descentralized.
I want to have a centralized control flow mechanism that will make the decisions in one spot. But how can this be done when everything is executed asynchronously?
"An option I would love to have is to attach a second event handler to the RetieveFirstLevelOptionsCompleted event and have it remove itself after running only once. But it looks like such a behaviour is impossible to get."
Is there some reason this isn't working:
class Example
{
SomeWebService myService;
Example()
{
// do stuff
myService.RetrieveFirstLevelOptionsCompleted += MyHandlerMethod;
}
void MyHandlerMethod(object sender, RetrieveFirstLevelOptionsCompletedEventArgs e)
{
// do stuff
myService.RetrieveFirstLevelOptionsCompleted -= MyHandlerMethod;
// potentially attach next event handler for all subsequent calls
myService.RetrieveFirstLevelOptionsCompleted += MyHandlerMethod2;
}
}
The pattern that I usually use in a situation like this is to create a wrapper around the Async web service proxy method that accepts a callback method. The callback method then gets passed to the RetrieveFirstLevelOptionsAsync() method like so:
public void RetrieveFirstLevelOptions(Action callback)
{
client.RetrieveFirstLevelOptionsAsync(callback);
}
void client_RetrieveFirstLevelOptionsCompleted(object sender, AsyncCompletedEventArgs e)
{
var callback = e.UserState as Action;
if (callback != null)
{
callback();
}
}
So when you call RetrieveFirstLevelOptions(), you just pass the callback that you want to run only once, and you don't ever have to worry about it getting called multiple times. Presumably you'd put your call to RetrieveSecondLevelOptions() within that callback.
What is the best design decision for a 'top-level' class to attach to an event to a class that may be '5+ layers down in the callstack?
For example, perhaps the MainForm has spawned an object, and that object has spawned a callstack of several other object calls. The most obvious way would be to chain the event up the object hierarchy, but this seems messy and requires a lot of work.
One other solution ive seen is to use the observer pattern by creating a publically accessible static object which exposes the event, and acts as a proxy between the bottom-level object, and the top-level 'form'.
Any recommendations?
Here's a pseudo-code example. In this example, the MainForm instantiates 'SomeObject', and attaches to an event. 'SomeObject' attaches to an object it instantiates, in an effort to carry the event up to the MainForm listener.
class Mainform
{
public void OnLoad()
{
SomeObject someObject = new SomeObject();
someObject.OnSomeEvent += MyHandler;
someObject.DoStuff();
}
public void MyHandler()
{
}
}
class SomeObject
{
public void DoStuff()
{
SomeOtherObject otherObject = new SomeOtherObject();
otherObject.OnSomeEvent += MyHandler;
otherObject.DoStuff();
}
public void MyHandler()
{
if( OnSomeEvent != null )
OnSomeEvent();
}
public event Action OnSomeEvent;
}
If your application isn't based on Composite UI Application Blocks, the easiest solution is to put a "listener" class between Main form and your other components which both classes can easily access. Conceptually, the classes are laid out as follows:
---------- ----------------
| MainForm | | Some Component |
--------- ----------------
| |
Hooks onto Notifies
| |
\ /
-----------------
| Proxy Notifier |
-----------------
Here's some example code:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
FakeMainForm form = new FakeMainForm();
form.CreateComponentAndListenForMessage();
Console.ReadKey(true);
}
}
class FakeMainForm
{
public FakeMainForm()
{
Listener.AddListener(MessageRecieved);
}
void MessageRecieved(string msg)
{
Console.WriteLine("FakeMainForm.MessageRecieved: {0}", msg);
}
public void CreateComponentAndListenForMessage()
{
ComponentClass component = new ComponentClass();
component.PretendToProcessData();
}
}
class Listener
{
private static event Action<string> Notify;
public static void AddListener(Action<string> handler)
{
Notify += handler;
}
public static void InvokeListener(string msg)
{
if (Notify != null) { Notify(msg); }
}
}
class ComponentClass
{
public void PretendToProcessData()
{
Listener.InvokeListener("ComponentClass.PretendToProcessData() was called");
}
}
}
This program outputs the following:
FakeMainForm.MessageRecieved: ComponentClass.PretendToProcessData() was called
This code allows you to invoke methods directly on any listener, no matter how far apart they are in the call stack.
Its easy to rewrite your Listener class so that its a little more generic and works on different types, but you should get the idea.
My initial intention would be to try and avoid that, so that an object's scope has obvious boundaries. In the particular case of Forms, I would attempt to have the child's parent form manage all required communications withs its ancestors. Can you be more specific about your case?
My first thought is that from your MainForm's perspective, it should have no idea what is going on 5 levels down. It should only know about its interactions with the object that it spawned.
With that, if you main form wants to perform some action asynchronously, it should be able to do that by calling a method on the spawned object asynchronously.
Now from your spawned object's point of view, if you allowed your caller to perform some method asynchronously, there's no need to push the event model further down... just call the methods directly down the stack. You're already on another thread.
Hopefully that helps a little. Just remember the levels of your app should only be aware of what goes on in the level immediately below them.
WPF uses routed events. These are static and can bubble up or tunnel down the element tree. I don't know if you are using WPF, but the idea of static events might help you out.
I wouldn't say this is a design fault, there are valid reasons for the main form to want to listen to what an object is doing. One scenario I've encountered is displaying status messages to the user to indicate what background processes are doing, or what multiple controls are doing in a multi-threaded app that lets you have multiple screens/"pages" open at once.
In the Composite UI Application Block, the basic equivalent of a dependency injection container wires up events when its instantiating objects in the same work item (a work item is just an object container for a group of related user controls). It does this by scanning for special attributes such as [EventPublication("StatusChanged")] on events and [EventSubscription("StatusChanged")] on public methods. One of my applications uses this functionality so that a user control instantiated way down in the innards of the application can broadcast status information (such as "Loading customer data...45%") without knowing that that data is going to end up in the main form's status bar.
So a UserControl can do something like this:
public void DoSomethingInTheBackground()
{
using (StatusNotification sn = new StatusNotification(this.WorkItem))
{
sn.Message("Loading customer data...", 33);
// Block while loading the customer data....
sn.Message("Loading order history...", 66);
// Block while loading the order history...
sn.Message("Done!", 100);
}
}
...where the StatusNotification class has an event with the a signature like
[EventPublication("StatusChanged")]
public event EventHandler<StatusEventArgs> StatusChanged;
... and the above Message() and Dispose() methods on that class invoke that event appropriately. But that class didn't explicitly have that event hooked up to anything. The object instantiator will have automatically hooked up the events to anybody with a subscription attribute of the same name.
So the MainForm has an event handler that looks something like this:
[EventSubscription("StatusChanged", ThreadOption=ThreadOption.UserInterface)]
public void OnStatusChanged(object sender, StatusEventArgs e)
{
this.statusLabel.Text = e.Text;
if (e.ProgressPercentage != -1)
{
this.progressBar.Visible = true;
this.progressBar.Value = e.ProgressPercentage;
}
}
... or some such. It's more complicated than that since it will rotate through multiple status notifications for a given number of seconds since multiple user controls can be broadcasting status messages around the same time.
So to recreate this behavior without actually switching over to CAB (which, to be honest, is much more complicated than I think it really needs to be), you could either have a MessageNotificationService object that you pass around your application or that you turn into a static/singleton object (I usually avoid this approach since it's harder to test), OR you could have you sub usercontrols be instantiated by a factory class that does the event wiring up for you. Objects could register with the factory by attributes of your own creation or by explicitly calling methods that say "hey, anytime you create an object with an event of this signature, I want to know about it."
Just be careful to have whatever class you implement unhook the events when an object gets disposed because it's stupid easy in this scenario to end up with something that won't get garbage collected.
Hope this helps!