Click here to Skip to main content
Click here to Skip to main content

Tagged as

Go to top

Tips & Tricks - Working with Event Handler

, 3 Jun 2010
Rate this:
Please Sign up or sign in to vote.
Suppose two thread subscribed to the same OperationComplete handler and one unsubscribed the event. In such scenario the OperationComplete event will become null and for the next thread due to the event is null it will not execute. This happens mainly in multithreaded applications but you can't guar
Sometimes we write the following code while working with EventHandler and that may create some problems. I will discuss this later on. Let us see the code:
 
                private void RaiseOperationComplete(EventArgs e)
                {
                    if(OperationComplete != null)
                    {
                        OperationComplete(this, e);
                    }
                }
 
In the above case, suppose two thread subscribed to the same OperationComplete handler and one unsubscribed the event. In such scenario the OperationComplete event will become null and for the next thread due to the event is null it will not execute. This happens mainly in multithreaded applications but you can't guarantee for single threaded application too.
 
So what to do? How can we make sure that our application will not come into such situation and work properly?
 
Yup, let us modify the code a bit. First we will store the event handler to a local variable and then we will raise the event from the locally cached copy. Have a look into the following code:
 
                private void RaiseOperationComplete(EventArgs e)
                {
                    EventHandler<string> handler = OperationComplete;
                    if(handler != null)
                    {
                        handler(this, e);
                    }
                }
</string>
 
Here when we execute the OperationComplete event handler, the current value we will store in a local variable named "handler". Hence both "handler" and "OperationComplete" will point to the same object. Thus we will create a cached copy of the same value for the handler and then raise the event.
 
The reason you do this is because the assignment is a copy of the delegate instance at that point, and not a by-value copy. Doing this, the reference will be cached just in case another thread, or re-entrant code, nulls out the reference before you call it. The original value will not change though it will set the event to null.
 
So, remember to always follow the second approach and be in the safer place of coding.
 
Thanks to Pete O'Hanlon[^] for bringing this to my point in this post[^].

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

_ Kunal Chowdhury _
Technical Lead
India India
Kunal Chowdhury is a Microsoft "Client Development" MVP (Most Valuable Professional), a Codeproject Mentor, Telerik MVP, Nokia Developer Champion, Speaker in various Microsoft events, Author, passionate Blogger and a Software Engineer by profession.
 
He is currently working in an MNC located in India. He has a very good skill over XAML, C#, Silverlight, Windows Phone, WPF and Windows 8 (WinRT). He posts his findings, articles in his technical blog and CodeProject.
 
Technical Blog: http://www.kunal-chowdhury.com
Facebook: http://facebook.com/blog.kunal
Twitter : http://twitter.com/kunal2383
Follow on   Twitter   Google+   LinkedIn

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Mobile
Web01 | 2.8.140921.1 | Last Updated 3 Jun 2010
Article Copyright 2010 by _ Kunal Chowdhury _
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid