Registering Event Handlers in C# vs. VB .NET

[Scott M.]

Am I correct in thinking that because C# doesn't have the "Handles" keyword
that VB .NET does, we have to register event delegates manually in C#,
whereas in VB .NET using "Handles" takes care of registering the event
delegate for us behind the scenes?

In other words, *if* C# did have a "Handles"-type keyword, would we still
need to register an event delegate?

 

[Nicholas Paldino [.NET/C# MVP]]

Scott,

Yes, you are right, VB will take care of assigning the delegate to the
event when you use the handles keyword.

My assumption is that no, you would not have to register the event if
something like that existed in C#, but it's impossible to say, given that
there has been no discussion about it or mentioning of anything of that
nature.

 

[Scott M.]

Ok Nicholas. I just wanted to make sure my understanding of why we don't
need to do it in VB .NET (and have a Handles keyword) equated to why we do
have to do it in C# (and don't have something like Handles).

Thanks!

Scott,

Yes, you are right, VB will take care of assigning the delegate to the
event when you use the handles keyword.

My assumption is that no, you would not have to register the event if
something like that existed in C#, but it's impossible to say, given that
there has been no discussion about it or mentioning of anything of that
nature.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Am I correct in thinking that because C# doesn't have the "Handles"
keyword that VB .NET does, we have to register event delegates manually
in C#, whereas in VB .NET using "Handles" takes care of registering the
event delegate for us behind the scenes?

In other words, *if* C# did have a "Handles"-type keyword, would we still
need to register an event delegate?

 

[Peter Duniho]

Am I correct in thinking that because C# doesn't have the "Handles"
keyword
that VB .NET does, we have to register event delegates manually in C#,
whereas in VB .NET using "Handles" takes care of registering the event
delegate for us behind the scenes?

In other words, *if* C# did have a "Handles"-type keyword, would we still
need to register an event delegate?

As Nicholas says, it's hard to say what "might have been".

That said, I prefer the C# approach. VB hides a bit of the mechanism from
you, which IMHO makes it harder for people new to the whole delegates and
events thing to really understand what's going on.

It can be an especially difficult leap for a VB.NET programmer to grasp
that a method written to handle an event can be applied to multiple
events, multiple objects, etc. as well as that a given event can have
multiple subscribers, because the basic syntax for dealing with event
handlers in VB.NET doesn't expose that.

Other people's opinions may vary. VB does a variety of things that smooth
things out for the programmer, by inferring behaviors or doing things
behind the scenes. I suppose some people might actually like this, but
every time I see someone confused by what's going on in VB.NET, I wonder
whether they would have had the same confusion had VB.NET not been
invoking some hidden behavior on the programmer's behalf (another recent
example that comes to mind is VB.NET instantiating a Form-derived class
instance as some sort of "default" instance to use, conflicting with a
previously-created one).

Pete

 

[David Anton]

In keeping with VB's philosophy of having many ways to do the same thing, you
can either use "Handles" or "AddHandler" (AddHandler and RemoveHandler are
the exact equivalent to the C# approach).
--
http://www.tangiblesoftwaresolutions.com
C++ to C#
C++ to VB
C++ to Java
C++ to Ruby
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: convert VB or C# to C++/CLI

 

[Scott M.]

It can be an especially difficult leap for a VB.NET programmer to grasp

that a method written to handle an event can be applied to multiple
events, multiple objects, etc. as well as that a given event can have
multiple subscribers, because the basic syntax for dealing with event
handlers in VB.NET doesn't expose that.

Huh? In VB .NET, we often deal with multiple (or common) event handlers for
multiple objects. We just use the Handles keyword to do it, but the concept
is no more foreign in VB .NET than it is in C#. Also, while "Handles" does
"hide" the underlying event delegate registration, working with delegates
directly is not a problem at all and not hidden in any way. (using
AddressOf).

Other people's opinions may vary. VB does a variety of things that smooth
things out for the programmer, by inferring behaviors or doing things
behind the scenes. I suppose some people might actually like this, but
every time I see someone confused by what's going on in VB.NET, I wonder
whether they would have had the same confusion had VB.NET not been
invoking some hidden behavior on the programmer's behalf (another recent
example that comes to mind is VB.NET instantiating a Form-derived class
instance as some sort of "default" instance to use, conflicting with a
previously-created one).

I agree that "auto-instancing" of forms (gone in VB .NET 2002 & 2003 and
back again in 2005) is contrary to good OO practice (and I personally
discourage it's use), but I don't see how this is an example of hiding
anything, since you can still instance forms explicitly if you wish.

To me "hiding" means that what happens is completely behind the scense and
you can't get involved with it. Delegates and auto-instancing of forms can
be dealt with "automatically" (ie. Handles), but the concept isn't hidden
and the developer can remove the Handles and use AddressOf to register their
own delegates if they wish.

Wouldn't you say the the C# "using" statement (now, in VB .NET 2005) "hides"
some functionality in the same way that Handles does? Does that mean you
wouldn't use "using"?

It's just a language conveinience, but it doesn't hinder the language to
have it available.

....My two cents - thanks for yours.


-Scott

 

[Peter Duniho]

Huh? In VB .NET, we often deal with multiple (or common) event handlers
for
multiple objects. We just use the Handles keyword to do it, but the
concept
is no more foreign in VB .NET than it is in C#. Also, while "Handles"
does
"hide" the underlying event delegate registration, working with delegates
directly is not a problem at all and not hidden in any way. (using
AddressOf).

You've missed my point. I'm not saying VB.NET doesn't offer the same
functionality possible elsewhere. I'm saying that the "Handles" keyword
is used in a way that obscures the full capabilities of events. A
particular example of what I mean is the requirement that when using
"Handles" that you have some known object variable (as opposed, for
example, to a collection of objects exposing an event), and of course the
ability to subscribe and unsubscribe at will at run-time.

It's not that you can't do these things in VB.NET, but you have to use an
entirely different syntax to do so from the syntax offered up as the basic
provided mechanism.

I agree that "auto-instancing" of forms (gone in VB .NET 2002 & 2003 and
back again in 2005) is contrary to good OO practice (and I personally
discourage it's use), but I don't see how this is an example of hiding
anything, since you can still instance forms explicitly if you wish.

Again, you're missing my point. It's not about whether you _can_ do
something. It's whether the supplied _basic_ mechanism hides from you the
full functionality that is possible.

I readily accept that some people prefer to have these details hidden from
them, but it's not something I personally prefer and I've seen people have
problems learning concepts like this when those details are hidden.

[...]
Wouldn't you say the the C# "using" statement (now, in VB .NET 2005)
"hides"
some functionality in the same way that Handles does? Does that mean you
wouldn't use "using"?

No, I wouldn't say that "using" "hides" functionality in the same way that
"Handles" does. There's a direct one-to-one mapping between "using" and
the code it replaces. "Handles" offers a subset of the full spectrum of
the way an event handling method can be used.

It's just a language conveinience, but it doesn't hinder the language to
have it available.

I never said it hindered the language. I said it potentially hinders the
programmer.

...My two cents - thanks for yours.

You're welcome. Hoepfully I've made myself better understood this time.

Pete

 

[Scott M.]

You've missed my point. I'm not saying VB.NET doesn't offer the same

functionality possible elsewhere. I'm saying that the "Handles" keyword
is used in a way that obscures the full capabilities of events. A
particular example of what I mean is the requirement that when using
"Handles" that you have some known object variable (as opposed, for
example, to a collection of objects exposing an event), and of course the
ability to subscribe and unsubscribe at will at run-time.

It's not that you can't do these things in VB.NET, but you have to use an
entirely different syntax to do so from the syntax offered up as the basic
provided mechanism.

I didn't miss your point, but I think that your point doesn't apply as
broadly as you make it sound. If I am developing my own classes and raising
my own events, then the client of these classes won't have any "provided
mechansim" for handling those events. It will be up to the client to
declare the instance "WithEvents" or "AddHandler". I think what you are
referring to is applicable to classes used in UI's, but then (as I said),
they can still be modified to use the other syntax.

I just don't think this is a VB thing. C# also has language elements, such
as "using" that abstract a feature into a new language construct, but the
user can still get at this language functionality in other ways.

Anyway, thanks for your input.

-Scott

 

[Peter Duniho]

I didn't miss your point,

No, really...you did.

I'm sorry I wasn't able to explain it sufficiently, but your replies make
it clear you don't understand what I'm saying. It's probably my fault,
but unfortunately I can't think of a better way to describe what I'm
talking about.

Pete

 

[Scott M.]

No, really...I didn't. I just disagree.

You're talking about the fact that VS .NET creates event handlers for UI
elements and automatically wires up the events using "Handles", rather than
creating the delegates and registering them using "AddHandler" and
"AddressOf". And, you feel that because this happens automatically in UI
applicaitons, VB .NET developers somehow won't understand what delegates are
or have a harder time learning them than in C#.

My point is that just because VS .NET chooses to write one syntax vs. the
other doesn't mean that VB .NET developers are handicapped when it comes to
learning and understanding delegates. Those developers writing custom
classes and then using them in client applicaitons still have to create a
mechansim for event handling and VS .NET doesn't offer any "standard"
mechanism in those cases. Also, delegates are used for more than just event
handling. So, anyone using VB .NET for any kind of serious development is
going to be confronted with delegates and their useage beyond the "Handles"
keyword.

My analogy to you was the "using" keyword (originally added to C# and now to
VB .NET 2005). Would using "using" in C# cause developers to have a harder
time understanding what Dispose() is all about? No. In that case, "using"
is just a compliment to the language, it enhances it. It's not required to
use it - - you can still use the more manual Dispose() method call for
clarity if you like, but "using" is just a short-cut, just like "Handles" is
a short-cut for something you can still do manually (and in many cases, want
to do manually).

I think we just disagree on this one.

-Scott

 

[Peter Duniho]

No, really...I didn't. I just disagree.

No, you really don't get my point.

You're talking about the fact that VS .NET creates event handlers for UI
elements and automatically wires up the events using "Handles", rather
than
creating the delegates and registering them using "AddHandler" and
"AddressOf".

Yes, I am talking about that fact.

And, you feel that because this happens automatically in UI
applicaitons, VB .NET developers somehow won't understand what delegates
are
or have a harder time learning them than in C#.

That's not what I said. I said a specific subset of VB.NET developers may
have problems grasping the full nature of events and delegates.

As far as I'm concerned, that point is not even disputable. I've seen it
happen. You can claim it's not a problem until you're blue in the face, I
will still know from first-hand experience that's not true.

I've no doubt that plenty of VB.NET programmers have no trouble. But that
doesn't mean none do, nor does it mean that the choice to have two broadly
different language mechanisms for using events has no effect on some
developer's ability to get up to speed with certain .NET concepts.

My point is that just because VS .NET chooses to write one syntax vs. the
other doesn't mean that VB .NET developers are handicapped when it comes
to
learning and understanding delegates.

I never said VB.NET developers are as a group handicapped. You continue
to miss my point, even as you insist that you haven't.

[...]
I think we just disagree on this one.

I don't mind a disagreement. But you need to understand my point before
you disagree with it.

Pete

 

[Cor Ligthert[MVP]]

Peter,

That said, I prefer the C# approach.

It is not a C# approach the short way in VB is something extra in VB and
very documentative and therefore very easy to maintain in 95% of the
situations. That is probably the reason that it is mostly used in VB.

I would be pleased if it was in C# as well as that extra.

Cor

 

[Chris Shepherd]

My analogy to you was the "using" keyword (originally added to C# and now to
VB .NET 2005). Would using "using" in C# cause developers to have a harder
time understanding what Dispose() is all about? No. In that case, "using"
is just a compliment to the language, it enhances it. It's not required to
use it - - you can still use the more manual Dispose() method call for
clarity if you like, but "using" is just a short-cut, just like "Handles" is
a short-cut for something you can still do manually (and in many cases, want
to do manually).

I think the whole using thing is a terrible counter-example, because it is
rather clear that it only affects one block, and troubleshooting a
misunderstanding of this is in most cases trivial.

The VB.NET syntax issue Peter pointed out was more a case of asking the
question: How is a newbie programmer going to understand that when they have a
method that "Handles" an event that other things could already also be handling
the event?

While I could see the same newbie programmer failing to grasp that his object in
the using statement is no longer available after the following block, that is a
fairly straightforward thing to troubleshoot, and the errors in the code will be
rather apparent.

From personal experience, I've seen developers (in the process of learning)
just assume that because it says the method "Handles" the event, that only their
method handles the event. Whether you want to insult their intelligence or
learning methods is really irrelevant, what it boils down to is I've seen it
cause confusion. Most of the time explaining it using the alternate syntax
(AddHandler/RemoveHandler) seems to clear it up, because they then get it's a
list of Handlers, not just one method doing it all.

This is of course not a discussion of one language being superior to the other
or anything like that. Pete just said he didn't like the keyword because in his
experience (obviously similar to my own) it can/does lead to confusion. What
this amounts to is arguing about someone else's personal experience.


Chris.

 

[Jon Skeet [C# MVP]]

This is of course not a discussion of one language being superior to the other
or anything like that. Pete just said he didn't like the keyword because in his
experience (obviously similar to my own) it can/does lead to confusion. What
this amounts to is arguing about someone else's personal experience.

It has another rather sneaky side-effect too - it turns fields into
properties in order to subscribe/unsubscribe.

FWIW, I believe that the "field-like events" syntax of C# has also done
developers a disservice in many ways - it's caused a lot of confusion
about what events really are.

 

[Chris Shepherd]

It has another rather sneaky side-effect too - it turns fields into
properties in order to subscribe/unsubscribe.

FWIW, I believe that the "field-like events" syntax of C# has also done
developers a disservice in many ways - it's caused a lot of confusion
about what events really are.

Yeah, ultimately I think developing a language is about trying to maintain the
delicate balance between Clarity, Simplicity, and Utility.

People just have different ideas of what those things mean.


Chris.

 

[Peter Bromberg [C# MVP]]

I think a lot of this boils down to what Nigel Shaw once referred to as the
"culture" from which each language came. C# was created from the ground up
specifically to target the .NET Framework whereas VB.NET "came from" the
original classic Visual Basic - which "came from" the original BASIC, and so
on, ad nauseum.
-- Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
MetaFinder: http://www.blogmetafinder.com

 

[Scott M.]

I don't mind a disagreement. But you need to understand my point before

you disagree with it.

If you were talking about a specific subset of VB people, why did you say:

"It can be an especially difficult leap for a VB.NET programmer to grasp
...."

It is only now that you are saying a specific set of VB programmers.
Regardless, you can make that point about virtually any aspect of
programming in any language. A specfiic set of C# programmers are going to
have trouble understanding indexers. So what? Your new and improved
"point" is really meaningless now.

 

[Scott M.]

I think a lot of this boils down to what Nigel Shaw once referred to as the
"culture" from which each language came. C# was created from the ground up
specifically to target the .NET Framework whereas VB.NET "came from" the
original classic Visual Basic - which "came from" the original BASIC, and
so
on, ad nauseum.
-- Peter

Again, I disagree here. VB .NET was also created from the ground up
specifically to target the .NET Framework, but compatibility measures were
added in as not to alienate the millions of VB 6 developers. C# was written
from the ground up with C and Java in minde to accomodate those millions of
developers.

 

[Peter Duniho]

If you were talking about a specific subset of VB people, why did you
say:

"It can be an especially difficult leap for a VB.NET programmer to grasp
..."

Because that conveys my point better than writing "for VB.NET
programmers", which is what I would have written had I meant to apply the
discussion to ALL VB.NET programmers.

In other words, I wrote that because it best conveyed the point I was, and
have always been, trying to make.

If you're having trouble understanding what I wrote, you might want to
review the grammatical rules regarding the article "a". In particular,
that word indicates a single instance, and isn't used to describe a
plurality.

It is only now that you are saying a specific set of VB programmers.

No. I have always been saying that. Just because you choose to read it
differently, that doesn't change my intent or my words. It just means
that you're unwilling to admit that you misunderstood all along.

Regardless, you can make that point about virtually any aspect of
programming in any language. A specfiic set of C# programmers are going
to
have trouble understanding indexers. So what? Your new and improved
"point" is really meaningless now.

Whatever.

Please feel free to come back to the discussion when you've learned how to
carry on a civil conversation.

Pete

 

[Jon Skeet [C# MVP]]

Again, I disagree here. VB .NET was also created from the ground up
specifically to target the .NET Framework, but compatibility measures were
added in as not to alienate the millions of VB 6 developers. C# was written
from the ground up with C and Java in minde to accomodate those millions of
developers.

While I see your point, the "compatibility measures" involved are
*vastly* different between C# and VB.NET. There are plenty of syntactic
similarities, but equally large differences - and there are very few
bits of code which will work in both C/C++/Java and C#.

Just as an indicator of this, there's no add-on library to make C#
behave like C, C++ or Java - unlike VB.NET. (J# is a different beast,
of course.)