From: Walden H. Leverich
If you mean VB6 and VS 6, forget everything you know.
Right. But that's the rub. MS went to great lengths to make Web projects "appear" to be as close to desktop projects as possible. But they're not. And it becomes a puzzle to figure out differences.
Oh, and use a real language like c#. :-)
Okay, some folks get pedantic about having a semicolon at the end of a line ;-)
The handler for a button makes a ton of sense to me,
as that's the code that runs when the button is clicked, simple.
To me, that's another rub. The Web-Forms IDE brings up an editor to insert server-side code - as though a Web application were the same as a stateful single-user desktop application - except the nuances of state management may not be clear, at all.
The code for an on-change handler for a drop-down that posts back
automatically also makes sense as I likely want to do something there
and then.
A browser UI event may need to trigger client code - a JavaScript function. The event may then need to forward "something" to the server. The event may need to update a variable in, or submit something from a different document in a separate in-line frame. Maybe the event should trigger a complex set of client actions, followed by a series of AJAX interactions.
There's often a need for some leeway in what code is run on the client and what code is run on the server. It may improve the UI to have additional control on the client - no fixed rule for every case. Other times it may be better for the server to be in control - in which case you don't want a UI event to "trigger" server code, but rather let the server decide which code to run - perhaps based on overall state.
Of course, ASP.Net developers may learn work-arounds to IDE built-in behaviors, but to me, it feels cumbersome.
I'm not even sure I know what an object-inspector is ...
I meant the Object Browser - I was thinking of a different IDE that had a different name for it.
Nathan.
midrange.com
