will C# ever get a more declarative way of handling events? VB is gold on this issue

[Eric Newton]

VB's more declarative nature of handling events is golden. I'm hoping C#
will acquire this type of deal, in addition to the anonymous delegates.

could do same as vb (actually would be easier to parse then vb due to
braces) whereas you look for Handles keyword after method sig, but before
opening brace of the method.

compiler would implicitly build event handling code for all typed
constructions, ie, any variables instances constructed via "new" operator,
compiler would follow with <instanceName>.<event> += new
<eventHandlerType>(<methodNameOfHandler>)

Seems like the algo could work like this

if "Handles" is found between method signature and first opening brace,
follow rules for dereferencing a simple expression of a type, followed by an
event name.
if expression is valid then
build implied code event handler creation for all found "new" operators
of the class
end if

c#:
private void Button_Click(object sender,EventArgs e) handles Button1.Click,
Button2.Click, Button3.Click
{
}
protected Button Button1;
private void InitializeComponent()
{
Button1 = new Button();
// implicit compiler event handling addition
Button1.Click += new EventHandler(Button1_Click); // statement is
implicit compiler addition
Button1.Text = "Button1";
// (finish building button1's properties)
Button2 = new Button();
// implicit compiler event handling addition
Button2.Click += new EventHandler(Button_Click);//statement is implicit
compiler add
Button2.Text = "Button2";

}

 

[Jon Skeet [C# MVP]]

VB's more declarative nature of handling events is golden. I'm hoping C#
will acquire this type of deal, in addition to the anonymous delegates.

could do same as vb (actually would be easier to parse then vb due to
braces) whereas you look for Handles keyword after method sig, but before
opening brace of the method.

compiler would implicitly build event handling code for all typed
constructions, ie, any variables instances constructed via "new" operator,
compiler would follow with <instanceName>.<event> += new
<eventHandlerType>(<methodNameOfHandler>)

Seems like the algo could work like this

if "Handles" is found between method signature and first opening brace,
follow rules for dereferencing a simple expression of a type, followed by an
event name.
if expression is valid then
build implied code event handler creation for all found "new" operators
of the class
end if

<snip>

While I can see some of the appeal, this strikes me as a really nasty
thing to happen in terms of the language. It's just not the kind of
thing the language should be trying to deal with. It would also be open
to problems - for instance, what if your button wasn't generated by a
"new" operator but by a method returning a button reference?

I'm sure there's an elegant solution around somewhere, but I don't know
what it is. Here's another idea though:

// Variable declaration
eventhandled Button button1;

// Method declaration
private void Button_Click(object sender,EventArgs e) handles
Button1.Click

generates code equivalent to:

Button _button1;
Button button1
{
get { return button1; }
set
{
if (button1 != null)
{
button1.Click -= new EventHandler (Button_Click);
}
button1 = value;
if (button1 != null)
{
button1.Click += new EventHandler (Button_Click);
}
}
}

In other words, the field is turned into a property and code is
generated to add/remove the event handlers whenever the value is
changed.

Things would get very sticky when it came to inheritance though - the
base class would only know about events within the class itself, so a
derived class couldn't "add" event handlers. Maybe that would be a
reasonable restriction though.

I'm not sure I like disguising a property as a field, but I feel it's a
bit nicer (and more reliable) than other ways. Mind you, it still has
problems:

Button tmp = button1;
button1 = new Button(...);
// The original button no longer has event handling; is this okay or
// not?

 

[Eric Newton]

I do see your point, and its something that I'm not completely comfortable
with either

However, the zeal of a more declarative event handling mechanism would make
it easier when transferring Control code from form to form, more similarly
like our VB counterparts.

Of note, the first notion of this came about from the C# designer tending to
"lose" the events when a control was cut and pasted... with the VB
declarative syntax, this is lessened, even though the VB designer tends to
screw that up too.

Its always annoying to cut/paste a control because of trying to get the
docking order correct, then finding out that you have to hook up all the
events again because the designer wiped them all out.

Incidentally, as I think about this more, I wonder if the same thing will
happen to the anonymous delegates? In theory it would, however, anonymous
delegates probably wouldnt show up in InitializeComponent and if they did
then I would blame to programmer for messing around in "auto generated" code
regions.

following VB code is very easy to cut/paste from form to form, (ignoring the
fact that I hate cut/copied and pasted code)

Dim WithEvents txtOcr as TextBox
Private Sub txtOcr_MouseUp(Byval sender as Object, byval e as
MouseEventArgs) Handles txtOcr.MouseUp
'code to display a contextmenu at the current position
End SUb

with C#, you have multiple things to cut/paste: the contextmenu code, the
declaration, AND the event hookup, obviously with the VB code, the hookup is
handled already.

AGAIN, I'm not totally comfortable with the compiler emitting arbitrary
code, so I'm looking for a good solution that can bridge the gap, then to
eventually hound the compiler guys ;-)

--
Eric Newton
C#/ASP Application Developer
http://ensoft-software.com/
(e-mail address removed)-software.com [remove the first "CC."]