1

In VB, we have the Handles clause, that allows add a Handler to an event of a control without putting it into the xaml file (directly into the VB file).

xaml:

<Button x:Name="myButton" />

VB:

Private Sub Button_Click() Handles myButton.Click

End Sub

One good thing that can be done using this is the possibility to use the Visual Studio dropdowns to add events automatically without the need to go to the xaml file and change it. Read this question (and the answer) to better understand what I'm talking about:

Visual studio 2010 showing available events from code behind

The answer of that question doesn't specify why C# does not have this feature inside Visual Studio, but it's clear for me: C# does not have this feature because it uses the Handles clause to add the event on CodeBehind.

I know that we can make use of the += and add the event manually on the constructor, below InitializeComponent (that is almost the same thing), but VB also have the AddHandler that can add events on the constructor (and in other places), and it's not automatic and less reliable (for me) than the Handles clause.

My question is:

Why it's never implemented? It's non-reliable? Non-secure? There's any workaround?

Community
  • 1
  • 1
Guilherme
  • 5,143
  • 5
  • 39
  • 60
  • 8
    Different languages have different features. Who would have thought? – Oded Sep 18 '13 at 18:06
  • 1
    Point being, asking _why_ a language does or doesn't have a feature is a question for the language designers, not the programming public. I suggest reading this: http://blogs.msdn.com/b/ericlippert/archive/2003/10/28/53298.aspx – Oded Sep 18 '13 at 18:07
  • The problem is that VB and C# is compiled to the same thing: MSIL. This is why I'm in doubt about it. VB and C# have very close specification and features because of that. – Guilherme Sep 18 '13 at 18:09
  • Personally, if I were comparing language features, I'd want to know why C# [doesn't have XML literals](http://stackoverflow.com/a/8768783/211627) or why the [LINQ support](http://stackoverflow.com/a/6515130/211627) is not as rich. But all of this is ultimately explained by the fact that Microsoft does not have inifinite resources and infinite time. Each language team selected the features they felt were most important and would be most welcome/used by their users. – JDB Sep 18 '13 at 18:11
  • 1
    Anyways, if you're using WPF you should not be using code behind or event-driven stuff most of the time, so why do you even care about that? – Federico Berasategui Sep 18 '13 at 18:13
  • I'm curious about it ;) It's appeared strange for me. – Guilherme Sep 18 '13 at 18:15
  • 1
    @Guilherme AFAIK, the MSIL you get from a VB `Handles` clause is exactly the same as what you get from C# if you specify an event property in the XAML; it's entirely handled by the compiler before the IL is generated. `Handles` is just a convenience keyword that mimics VB's historical event style where events were wired up by name, and not by any direct assignment; C# never had such behavior so why introduce it? – Michael Edenfield Sep 18 '13 at 18:16
  • Though [this answer](http://stackoverflow.com/a/6346059/211627) is on a different topic, the core of it applies: *However at this time based on our research we believe that the feature does not have broad enough appeal or compelling usage cases to make it into a real supported language feature.* – JDB Sep 18 '13 at 18:17
  • @Cybȫʁgϟ37 Yeah, I agree with you. We can do anything without that, but when it comes to the VisualStudio feature that I've mentioned, the reaction of a user is: "It seems that this feature is only available when the current file is in VB.Net. In my opinion this suks :/". – Guilherme Sep 18 '13 at 18:21
  • As an aside, if you're using WPF, you should look into Command binding. Wiring up the handler directly to the button might be appropriate some times, but it tightly couples your UI to the logic behind it. With the Command binding in WPF, you get rid of this tight coupling and make your code more flexible (and testable). – Chris Dunaway Sep 19 '13 at 15:04

1 Answers1

5

It was never implemented because no one at Microsoft thought it was useful enough to justify the effort. The exact reasons why can only be answered by someone on the C# team. And while it's true that C# and VB have made an effort to synchronize their features, that doesn't mean they're going to retroactively introduce all VB-specific features in C# or vice versa. (Note that the Handles clause has always existed in VB.NET)

However, one can speculate based on VB's history as a language why it might have been introduced. Namely, that's how VB events pre-NET always worked, so VB developers would probably be used to it.

In traditional VB, events were wired up to objects by name. If you have a Form and you define a subroutine named Form_Load, it will run as your form's Load event. This tradition carried over into ASP, and still lingers as the AutoEventWireup configuration option. VB developers were used to the language knowing what method to run for which events without having to "explain it" to the compiler.

In .NET languages, events are just a particular kind of property with a special type (a delegate type) that have to be assigned like any other property. In order to allow VB developers to transition easily into VB.NET, though, you would ideally give them an easy way to do so without having to learn about events and delegates and handlers (at least not immediately). The Handles keyword accomplishes this -- you just tack on Handles Load onto your Form_Load sub and it becomes an event handler.

C#, on the other hand, has no legacy behavior that it needed to maintain. The target audience for C# consisted of people from many languages, most of which had no built-in concept of events and certainly did not have the auto-wireup behavior of VB. So there was no need to introduce this behavior into the language, but instead, new C# developers would just learn the "right way" of doing things from the start.

With the introduction of WPF and MVVM view/model separation and the push for minimal code-behind, a handles keyword becomes a bit more attractive, but it still seems to go against the general principles of how C# handles events. I suspect it would take a very, very strong argument to convince the C# team that it was worth implementing.

Michael Edenfield
  • 28,070
  • 4
  • 86
  • 117
  • Upvoted and marked as correct. "The exact reasons why can only be answered by someone on the C# team". I think that Eric Lippert have a excellent answer to this question. – Guilherme Sep 18 '13 at 18:35
  • While the reasons for vb.net to have incorporated the feature may have been driven by historical practices, that does not imply that it should only be viewed as a "compatibility hack". While there are times when AddHandler/RemoveHandler must be used manually, having a single declaration take care of both ensures that `AddHandler` calls are properly paired with `RemoveHandler`. – supercat Sep 18 '13 at 20:39
  • I wouldn't call it a "compatibility hack" either (and hopefully did not imply that). I would call it a convenience feature geared towards users with experience in an existing language. – Michael Edenfield Sep 18 '13 at 20:46
  • @MichaelEdenfield: I didn't mean the term derisively; what I meant to say was that the idea of specifying event hookup declaratively rather than imperatively shouldn't be viewed as only being useful for people accustomed to such things. I would posit that *in general* declarative specifications are more maintainable than imperative ones in cases where the desired semantics fit those implied by the declaration; that principle is hardly unique to VB and its programmers. – supercat Sep 18 '13 at 21:12