In my previous blog post, I had a solution to prevent subtle bug when removing and readding an event handler. The solution works, but its not flexible at all. You can see the method is very dependent/attached to the button1 object and the click event, which means that the logic cannot be re-use for other objects or other events. For example, if I want to have the same logic for textchanged, this would mean I have to write another function for the event.

So how can we make it more modular? Well, we need to be able to register and unregister event handler dynamically. This can be easily achieved by using reflection and delegates. Reflection alows us to browse all the events that a type have in a form of EventInfo object. We can then use the EventInfo object to add or remove event handler to the event. To do it, EventInfo requires a delegate of the EventHandler type that represents/points to an instance method to invoke on a class instance. The delegate can be created using Delegate.CreateDelegate method, which takes in the following as its parameters: The type of the delegate, An object that contains the event handler method, the event handler method name. Here is the new code of the Register Click Event.

RWendi

Be very carefull if you have code like the above example. It may seems ok, because you unregister the event handler at the start of the function, you reregister it again at the end of the function. No event get lost, no drama! Now let say, in that function we add another function called foo. In foo we add the same event handler logic, that is unregistering and re-registering the handler.

The above code has a subtle bug, which is the event handler get registered twice. One time at the end of Foo and the other at the end of Form1_Load function. The impact of this obviously when the event get raised, the handler will be called twice. Okay it may not be very subtle in the above code, but if you have a more complicated function, it's rather hard to track down this bug. It happened to me recently on one of our product code base. What I did to ensure this kind of problem never happens again is to add another function that's responsible in adding the handler to the event. This function will be used always for adding the handler to the event. The code is as below.

UPDATE: A better and more flexible approach can be found here

RWendi

On some unknown cases, opening files/documents using .NET Process class may have a performance impact. I hit this issue a while back, and it took a good few seconds for the .NET process to open up a Word document. I had a similar code as below when the issue occured.

After some research, I found out that this can be remedied by: instead of setting the ProcessInfo.Filename to be the filepath, you set the property to be the path of the designated application to open the file, and specify the file that you would like to open as its parameters (As shown below).

The problem with this method is that, you need to do this for every file type that you would like to support. So if your application supports multiple file format, you need to support each and every one of them in your code. Another problem is that, you need to find a smart way in detecting the default application that was set by the user to open a file. For example: if you want to open a word document, you can't always assume that the user has Microsoft Word installed in his machine. What happened if the user has OpenOffice instead? Or another case is, If the user has both MS Office and OpenOffice installed, but the user has opted to use open office as default application. Surely the user would prefer to use OpenOffice instead of MS Office. Thus we cannot just hardcoding value in.

Another solution to the problem is to use ShellExecute method of shell32.dll. One way you can do this is by defining an external method for the ShellExecute, and then calling it from your code. Another way of doing this is to set the Process object to do a shell execute. You can do this by setting the UseShellExecute property, of your Process' StartInfo object, to true.

So if you ever hit a performance issue when opening documents using .NET process class, give the above soulutions a try.

RWendi