This post originated from an RSS feed registered with .NET Buzz by Peter van Ooijen. Original Post: Handles versus Addhandler , a crash course in VB.NET event support (Error 459 revisited) Feed Title: Peter's Gekko Feed URL: /error.htm?aspxerrorpath=/blogs/peter.van.ooijen/rss.aspx Feed Description: My weblog cotains tips tricks and opinions on ASP.NET, tablet PC's and tech in general. Latest .NET Buzz Posts Latest .NET Buzz Posts by Peter van Ooijen Latest Posts From Peter's Gekko

In my previous post on the handling of COM events I described how I was driven into the arms of VB.NET. A VB.NET class published to COM sinks events as desired, a C# class pops up a mysterious error 459. With the help of feedback I've been delving a little deeper into this.

Events are handled by event handling methods. The way to set these in C# is by adding a delegate object to the event :

The usual way to set event handlers in VB is by using the handles keyword :

The nice way about the C# syntax is that it's no problem to hook in multiple methods as event handler's to the same event:

You can do the same thing, in VB.NET. In my post I admitted not knowing how to do that, Sean pointed me to the syntax to get that done using the AddHandler keyword. Instead of using handles the code could be written  as

Using this syntax  this I found out my VB.NET COM class started popping up the same 459 errors as the C# class. Apparently I was on to something.

Inspecting the actual code using Reflector shows that Handles and AddHandler have a subtle difference in the generated code.

The disassembly of a class using handles

constructor .ctor()

Public Sub New()
      Me.fw = New FileSystemWatcher
End Sub

Property setter of the object whose events are handled

<MethodImpl(MethodImplOptions.Synchronized)> _
Private Overridable Sub set_fw(ByVal WithEventsValue As FileSystemWatcher)
      If (Not Me._fw Is Nothing) Then
            RemoveHandler Me._fw.Created, New FileSystemEventHandler(AddressOf Me.watcher_Created)
      End If
      Me._fw = WithEventsValue
      If (Not Me._fw Is Nothing) Then
            AddHandler Me._fw.Created, New FileSystemEventHandler(AddressOf Me.watcher_Created)
      End If
End Sub

The disassmbly of the class when it sets the event handler in the constructor

Constructor .ctor

Public Sub New()
      Me.fw = New FileSystemWatcher
      AddHandler Me.fw.Created, New FileSystemEventHandler(AddressOf Me.watcher_Created)
End Sub

Fw property setter

<MethodImpl(MethodImplOptions.Synchronized)> _
Private Overridable Sub set_fw(ByVal WithEventsValue As FileSystemWatcher)
      If (Not Me._fw Is Nothing) Then
      End If
      Me._fw = WithEventsValue
      If (Not Me._fw Is Nothing) Then
      End If
End Sub

The handles keyword does translates to an AddHandler statement. But instead of in the constructor this statement is in the property setter of the object whose event is handled and adds the delegate to the internal object instead of its property wrapper. Apparently this subtle difference is enough to provide COM with a good event support. It matches the somewhat cryptic description Although you might think you could sink the events from the implemented object, that isn't automatically the case  on msdn.

The difference between C# and VB.NET is not the language itself but the code generation, I would not know of a way to alter that.