Bleh, why does Studio .NET always do things funkily?

[wyrd]

Okay.. with events in ASP.NET, for the code behind, the VS for some odd reason makes all of the functions for the events private. Because of this, in the main aspx page you cant use OnClick because the functions are private.

Can someone please explain to me the logic in why VS does this? Because it does this it has to add a ton of code (well, not for VB, but for C# it does) for adding events;

this.Button2.Click += new System.EventHandler(this.Button2_Click);

Sure it may not be to big of a deal when using the IDE, because it adds all this code for you when you double click something. But generally when you code by hand, why on earth would you want to do allllll that typing?

Is there a specific reason why it makes the functions private rather then just protected? Is there some benefit in this that Im not seeing?

 

[SteveD]

Actually, the .NET way of programming events really makes a lot of sense. Whats happening when you see:

this.Button2.Click += new System.EventHandler(this.Button2_Click);

is the "external" handling of that event through a function you create. Compared to the old VB style of doing things, where you were just given a function "Button_Click" and VB knew what that meant, the .NET languages provide you with facilities to make this extensible and powerful.

For example, you could make a single function handle events from 18 different controls, and vary how that function operated based on the control which fired the event. A feature that Ive found useful from day 1. (Imagine writing custom apps for someone who needs over 120 input fields in a particular way within a single window!)

If you write a few Windows.Forms apps and examine whats going on behind the scenes (in the "Windows Form Designer generated code" section), youll soon come to realize why C# and VB (yes, VB.net does it the same way) have this ability.

There isnt (that I know of) a way to do this with less code, pseudo VB6-style. But once you start making use of this - and related - features, you probably wont want to anyway.

If I didnt really answer your question, feel free to let me know. Later!

 

[wyrd]

I know what delegates are and why they exist for Events, how they work, etc. Except Im not talking about a real application here, Im talking about ASP.NET, where you can do things differently.

Instead of using delegates, you can match controls up in ASP.NET with events like so;
<asp:Button id="Button1" OnClick="Button1_Click" Text="blah" />

And yes, you can point several controls to the same event. This may make less sense if youre coming from an application stand point, however looking at it from a web scripting stand point (which is where I originally started programming), it makes much more sense (and less code for C#) to point the control to an event from the control tag.

I know this is probably a null point topic and argument, but the main things Im trying to get at is that not everyone uses the .NET IDE, and if some guy came along who doesnt have the .NET IDE and was looking through code that was built using it, then theyd have to sift through a lot of delegates to see which buttons triggered which events, rather then simply looking at the control in the main HTML page.

 

[SteveD]

Im not talking about a real application here, Im talking about ASP.NET, where you can do things differently.

Youre missing a lot of why ASP.net was designed the way it is. If the foundation used to construct ASP.net was bent to allow us to do things the "easy way" (i.e. like classic ASP or classic VB), you lose all the extensibility.

ASP.net doesnt provide us with any more flexibility than Windows Forms, and it certainly shouldnt. When you do something like:

<asp:Button id="Button1" OnClick="Button1_Click" Text="blah" />

It is (as far as I understand) creating a delegate behind the scenes. The reason the VS IDE separates these out is simply to layer the code and the interface, which is intended to abstract things for you. Granted, VS could be a little smarter and act like Web Matrix if/when you want it to, but Im sure that will come in time.

 

[wyrd]

I didnt say anything about an "easy" way to do something, I just said you can do things differently.

I ment that it provides us with flexibility in coding style, not through the language itself. Being a web language they added the ability to use properties and events for a control through the HTML tag if you choose, which in most cases makes for clearer code (ie; events in the case of C#).

What .NET does behind the scenes makes no difference, my point still stands that coming from a web language it makes sense for events to be declared inside the tags, not through delegates in the code behind (the way the IDE does it).

Maybe Im just not making my argument clear enough.

 

[SteveD]

Ah, I see where youre coming from. And yeah, that makes sense in a lot of contexts.

I think the reason Microsoft designed the VS IDE the way they did was in anticipation of it being used in a corporate environment to develop enterprise applications. Take me, for example. I will be writing a web-based front end to a MS SQL database (hopefully sometime in the near future). Thanks to govmint beurocracy, I might actually have to give the interface part to the "I am good with FrontPage"-types in a web dev department. I feel a lot more secure knowing that they have absolutely no control over what controls are doing what.

For most small ASP.net apps, however, youre right: All that abstraction and layering probably isnt needed at all. And for those poor saps with Notepad or vi and a command line compiler, its even less fun. (Especially if they have to share code with a friend whos using visual studio.)

I guess well just have to see what vs.net 2003 brings us for goodies. Anyone get a copy of the beta yet? Id love to hear what its like.

.steve

 

[wyrd]

Ah, I see where youre coming from. And yeah, that makes sense in a lot of contexts.

Ah finally someone is starting to understand... sort of. Let me take your example and see if I can clear up where Im coming from.

I think the reason Microsoft designed the VS IDE the way they did was in anticipation of it being used in a corporate environment to develop enterprise applications. Take me, for example. I will be writing a web-based front end to a MS SQL database (hopefully sometime in the near future). Thanks to govmint beurocracy, I might actually have to give the interface part to the "I am good with FrontPage"-types in a web dev department. I feel a lot more secure knowing that they have absolutely no control over what controls are doing what.

Okay, lets break this down to two scenarios to see if this really is a good idea.

1) We use code-behind to control what controls go to what events, which the IDE does automatically (and sets the events to private). To do this we need to declare each control before we can even use delegates to point them to the appropriate events (ie; Button b1 = new Button(); ) .. the IDE of course does all this for you as well.

Now, thats all fine and dandy. You got all the controls matched up with the events. The page works and everything is good. Now, a month later maybe, youre FrontPage geek comes back to you and says "hey, I want to use an ImageButton instead so the page looks better". Sure, no problem.. you crack open the code-behind, change Button to ButtonImage and all is good.

Now multiply this scenario 100000 times, because as a previous web designer I know how it goes.. you are always changing things on the site to make it look better until it is absolutely finished.

2) We use code-behind like normal, except this time we make the events public by hand (not using the IDE to auto-create events). This eliminates the need for controls to be declared in the code-behind as well (well, maybe not all if you use them throughout the code, but for the most part, generic controls dont need to be.. ie; a submit button).

Now, in this instance it allows your friendly FrontPage geek to determine which control goes to which event from the design page (ie; OnClick="SomeClickEvent"). If he wants, he can change this, that, and the other, and you hopefully wont have to change any trivial code (like changing Button to ImageButton).

Now I ask you.. which way sounds better to you?

 

[SteveD]

Hehehe... you make a good point.

Ill still defend Visual Studios abstract development, though. It may not always be the best way, but it certainly is the engineering way. And so... well.... uhmm....

Touch

 

[dsgreen57]

Erm and another note wyrd you have given your FrontPage Geek, access to Business Logic and he can break your application thinking he knows what he is doing...