C# Winforms - why not show a controls events in the IDE?

  • Thread starter Thread starter Greg Muncien
  • Start date Start date
G

Greg Muncien

In VB.Net, when you double click a control you see all available
events of that control in a combo box. Click on one, and the
interface code is right there waiting for you to type implementation.

Why does this not occur in C#? I have to write the function header
myself? Why does it seem C# goes out of its way to be less productive
than VB.Net? Has this been fixed in 2005?
 
In VB.Net, when you double click a control you see all available
events of that control in a combo box. Click on one, and the
interface code is right there waiting for you to type implementation.

Why does this not occur in C#? I have to write the function header
myself? Why does it seem C# goes out of its way to be less productive
than VB.Net? Has this been fixed in 2005?
Click to expand...

I'm not sure what IDE you're using, but in my Visual C#.NET I find it even
easier...

For the most controls it's sufficient enough to simply double click the
control itself, as then the code for the most common event will be generated
(e.g. the Click-event for a Button, etc).

If I want to use another event, I simply mark the control, then there's a
property view (bottom right in my version), where I can select to view
properties (kategorized or alphabetic) or events.

If I choose to look at the events, I simply double click on it and voilà,
there's all the code I need.

IMHO the C#-editor is in that sense more productive than the corresponding
VB-editor, as you have described it...

// Bjorn A
 
Seek and ye shall find. :-)

In the properties window there is a lightning bolt icon on the toolbar
at the top of the property grid. Click on that and it switches to the
events view. Double-clicking beside each event writes the header and
connects the event handler to the control's event. Or, if you already
have a method coded, you can click beside the event and choose the
method from the combo box that appears.

This is already available in VS2003.
 
...

I'm not sure what IDE you're using, but in my Visual C#.NET I find it even
easier...

For the most controls it's sufficient enough to simply double click the
control itself, as then the code for the most common event will be generated
(e.g. the Click-event for a Button, etc).

If I want to use another event, I simply mark the control, then there's a
property view (bottom right in my version), where I can select to view
properties (kategorized or alphabetic) or events.

If I choose to look at the events, I simply double click on it and voilà,
there's all the code I need.

IMHO the C#-editor is in that sense more productive than the corresponding
VB-editor, as you have described it...

// Bjorn A
Click to expand...

Ok, on second glance I admit it may come down to an apples and oranges
type of comparison. Whats really goofy about C# is that if for
example you just create a form, then drag a listbox to it, then look
in the properties/events window for the events, and choose the
dropdown for the DoubleClick event, any events that might have already
been wired up (i.e. the SelectedIndexChanged event) shows up in the
combo. To me it seems much more logical to wire up the DoubleClick
event handler to the DoubleClick event (and generate appropriate code)
than to suggest the SelectedIndexChanged event.

The way it works in VB.Net is pretty much the way it worked in VB (and
Delphi) for many years before DotNet came along, which may be why it
seems more intuitive to me.. Perhaps the way it works in C# is more
like Java or C++ environments? I don't know, but I guess thats one of
the rationales behind Microsoft pitching VB.Net as the solution for
higher productivity, and c# as the solution for.... well... to make
it easier for java folks to transition over to DotNet.
 
When you select a control in the designer, the properties window displays the
properties of that control. There are two buttons at the top of the
properties window - one labeled "properties" and one labeled "events". Click
on the "Events" button. The properties window will now list all the events
exposed by the control, along with the names of any functions that have been
assigned to those events. Simply select the event you want to handle, and
type the name of a handler in the space provided. The stub for that routine
will be created for you. You can then fill in the code to do whatever you
need to do.

Hope this clears things up a bit.
 
It works this way so that you can share event handlers between controls
or different events from the same control, and the IDE understands that
and supports it.

For example, I might have 10 radio buttons but only want one event
handler method called when any of the ten radio buttons changes state.
In that case I would use the dropdown.

If I want a new event handler, I just double-click in the empty space
and it makes me one.

It strikes me as the best of both worlds.
 
It works this way so that you can share event handlers between controls
or different events from the same control, and the IDE understands that
and supports it.

For example, I might have 10 radio buttons but only want one event
handler method called when any of the ten radio buttons changes state.
In that case I would use the dropdown.

If I want a new event handler, I just double-click in the empty space
and it makes me one.

It strikes me as the best of both worlds.
Click to expand...


Actually the best of both worlds was a wonderful feature of VB6 called
the ControlArray. Got 10 option buttons with similarities? When the
buttons are set up as being grouped together, you have one event
handler that accepts the index of the button being clicked. Then you
just put a Select Case statement (switch equivilent) in that event if
you want to do different things depending on which control in the
array youre dealing with (or just put all code thats common to each
control in that event). You could pass this array around to do things
common to every control in the array, etc... very nice.

It seems some aspects of DotNet are really a step backward technology
wise (I'm saying the same about VB.Net, not just C#)... ahh the price
of progress.. :)
 
Actually the best of both worlds was a wonderful feature of VB6 called
the ControlArray. Got 10 option buttons with similarities? When the
buttons are set up as being grouped together, you have one event
handler that accepts the index of the button being clicked. Then you
just put a Select Case statement (switch equivilent) in that event if
you want to do different things depending on which control in the
array youre dealing with (or just put all code thats common to each
control in that event). You could pass this array around to do things
common to every control in the array, etc... very nice.
Click to expand...

I used to get hung up over this back in the day, also. I was a VB purist
(whatever that means). When I switched to .NET, VB.NET frustrated me for a
while. It was a while before I ventured into C# (perhaps 2 years). Many of
the things I wanted (and still want) to do could very easily be simplified
with some of the features that VB6 had (such as control arrays). But as I
started to do some very complicated stuff (and tons of wheel reinventing) in
VB.NET mainly for the sake of having some good VB.NET code out there
(everything tends to be C# these days) I began falling in love with C#.
Now, I do VB.NET at work some of the time and C# most of the time and at
home I've mostly discontinued my use of VB.NET. When I got into the early
betas of VS.NET 2005 I took a preference to C#. For some reason, and one I
can't explain, VB.NET just doesn't make me feel at home anymore. I haven't
investigated VB.NET 2005 very much. I will soon enough when our company
migrates but in the meantime, I'm a C# guy.

In any case, the event wiring mechanism in C# is, lets say, convenient. I
like the way it is done in VB.NET/VB6 quite a bit, but the C# way is
actually a step forward (to me, your mileage may vary). In short, many of
the things that .NET does vs. VB6 ruffled my feathers but once I opened up
my mind I learned how to be productive with them and even started to like
them. Now we have .NET 2.0 and with all the new stuff my feathers are
ruffled again and, well, we just have to keep an open mind. Personally, my
career depends on it. But rather, I enjoy it. All the new stuff is
awesome. Sure, it isn't achieved the same way it was (in some cases), but
that's the price of progress. I suspect that given a short amount of time,
you'll start to prefer the new way (unless you do more development in legacy
environments than you do next-gen).

Thanks,
Shawn

http://www.zenofdotnet.com
 
I used to get hung up over this back in the day, also. I was a VB purist
(whatever that means). When I switched to .NET, VB.NET frustrated me for a
while. It was a while before I ventured into C# (perhaps 2 years). Many of
the things I wanted (and still want) to do could very easily be simplified
with some of the features that VB6 had (such as control arrays). But as I
started to do some very complicated stuff (and tons of wheel reinventing) in
VB.NET mainly for the sake of having some good VB.NET code out there
(everything tends to be C# these days) I began falling in love with C#.
Now, I do VB.NET at work some of the time and C# most of the time and at
home I've mostly discontinued my use of VB.NET. When I got into the early
betas of VS.NET 2005 I took a preference to C#. For some reason, and one I
can't explain, VB.NET just doesn't make me feel at home anymore. I haven't
investigated VB.NET 2005 very much. I will soon enough when our company
migrates but in the meantime, I'm a C# guy.

In any case, the event wiring mechanism in C# is, lets say, convenient. I
like the way it is done in VB.NET/VB6 quite a bit, but the C# way is
actually a step forward (to me, your mileage may vary). In short, many of
the things that .NET does vs. VB6 ruffled my feathers but once I opened up
my mind I learned how to be productive with them and even started to like
them. Now we have .NET 2.0 and with all the new stuff my feathers are
ruffled again and, well, we just have to keep an open mind. Personally, my
career depends on it. But rather, I enjoy it. All the new stuff is
awesome. Sure, it isn't achieved the same way it was (in some cases), but
that's the price of progress. I suspect that given a short amount of time,
you'll start to prefer the new way (unless you do more development in legacy
environments than you do next-gen).

Thanks,
Shawn

http://www.zenofdotnet.com
Click to expand...

Well just to be clear I didn't mean to come across like I want to hang
onto VB6 forever. It actually irks me to see people doing new
development in VB6, and/or trying to make classic ASP and VB6 apps
live forever without at least attempting to upgrade.

I love C# and VB.Net probably equally with regard to the language
itself. I do a mix of both at work, although most of my Winforms
experience is with VB.Net. But, while I don't want to go back to VB6,
I do feel its important to notice whats improved, and what's a step
back. In terms of overall productivity, there is no denying that .Net
is a step back.. what we gained was huge improvements in the way web
applications are written when compared to classic ASP with VB6 dlls,
and a lot of very nice features.. Is it worth the tradeoff? Sure, I
think so. But its also worthwhile to point out what VB6 did do
better, regardless of the fact that it is human nature to get
comfortable with whatever language you've worked in most and to lean
toward that language. If I were starting a new application right now
and had a choice, I would choose C# because I like coding in it, and
learning various things about it (like what I learned today about the
IDE.. I had been manually typing the events both in the code module
and in the "stay the hell out" portion of the designer generated code
until today! :)

But honestly, despite the fact I love coding in C#, if I were a
manager of a software team today, I would probably mandate that my
team stick to VB.Net, for several reasons:

1. Easier to transition classic ASP and VB6 developers to.
2. Tends to lead to higher levels of productivity (even Microsoft
bills it as the more productive of the two languages). In my
observations, given equal skill in both languages, a C# developer
seems to take longer to complete a task, and the results of the task
tend to be heavier in the way of code-complexity and less heavy toward
actually solving the problem at hand
3. VB.Net has a background compiler which has many productivity
advantages
4. Its easier to read someone elses code, because the IDE does such a
good job (better than C# that is) of enforcing consistent code
formatting.
5. VB.Net seems to be higher in priority with Microsoft. VB.Net code
E&C first, it was added to C# only after much whining. Reporting
Services 2000 only supports VB.Net for scripting inside reports. I
suspect C# is supported in the 2005 version, but Im not sure about
that one, maybe someone else can comment?
 
Actually, to be honest, I tend to create my WinForms applications as VB.NET
and ASP.NET applications as VB.NET (in .NET 1.x). Then, they are just
shells to the assemblies (written in C#) that contain all the real logic and
such.

Why? Well, I personally feel that C# gets in my way on WinForms forms and
ASP.NET. Don't know why. Could be psychological. In any case, it takes
longer to write them in C# for me than in VB.NET.

In .NET 2.0, OTH, there is no such problem and I'm just as happy to create
in C# as I am VB.NET, except that I prefer C#. I really don't know how to
explain it. Could just be a consequence of the cleanup they've done with
the language and codegen (sans partial classes).


Thanks,
Shawn

http://www.zenofdotnet.com
 
Back
Top