Calling functions from Events
-
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
I make my applications so that they have only one Event (the ApplicationStartUp Event). In this Event I code ALL logic etc. I do not use Try Catches so this is bound to go wrong somewhere. The application will close itself. When a user calls I say I even automated the UI and that everything actually went as planned (RTFM it's all in there!). My customers are happy and I am happy. The only thing that is not happy is my software, because it cannot feel emotions :D
It's an OO world.
-
I make my applications so that they have only one Event (the ApplicationStartUp Event). In this Event I code ALL logic etc. I do not use Try Catches so this is bound to go wrong somewhere. The application will close itself. When a user calls I say I even automated the UI and that everything actually went as planned (RTFM it's all in there!). My customers are happy and I am happy. The only thing that is not happy is my software, because it cannot feel emotions :D
It's an OO world.
Naerling wrote:
The only thing that is not happy is my software, because it cannot feel emotions
I wish I could upset or frustrate my software sometimes, then it might have some empathy and stop doing the same to me!
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
-
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
Depends. I use anonymous event handlers for events often, b/c it's useful for them to run in the scope of the calling method, and often useful to define the behaviour right there, from a readability stand point. But, for form events, I often factor them out in to a method, again for readability and reuse.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
-
Naerling wrote:
The only thing that is not happy is my software, because it cannot feel emotions
I wish I could upset or frustrate my software sometimes, then it might have some empathy and stop doing the same to me!
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
:laugh:
It's an OO world.
-
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
It's all relative really. You fume when you see event handlers with many lines of code. An MVC purist would cringe if he sees you calling a class method from the handler, since he would expect the call to be routed somehow to a controller or view-model. An MVVM purist would cringe at the event handler - since he'd want to see an event bound to a VM command in XAML. So don't judge the people who wrote that code because others will judge you just as sharply and just as unreasonably.
Regards, Nish
Are you addicted to CP? If so, check this out: The Code Project Forum Analyzer : Find out how much of a life you don't have! My technology blog: voidnish.wordpress.com
-
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
I only do it if the same code can be called from non-event code.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
Overall it is a good idea to call functions, that way you can change the logic pretty easily and also make the code readable (assuming functions have good names). It is pretty easy these days with refactoring support to extract the code into separate methods. For instance,
void serverName_changed(object sender, EventArgs e)
{
ResetUserNameAndPassword();
}is more readable then
void serverName_changed(object sender, EventArgs e)
{
Username.Text = "";
Password.Text = ""
// Some other code usually gets very long
//}
-
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
I'll second JSOP's method. Why cause function call overhead if you don't need to? Probably a moot point, especially if it's a button click, but something like a resize or repaint event could be called thousands of times.
- S 50 cups of coffee and you know it's on! Code, follow, or get out of the way.
-
Overall it is a good idea to call functions, that way you can change the logic pretty easily and also make the code readable (assuming functions have good names). It is pretty easy these days with refactoring support to extract the code into separate methods. For instance,
void serverName_changed(object sender, EventArgs e)
{
ResetUserNameAndPassword();
}is more readable then
void serverName_changed(object sender, EventArgs e)
{
Username.Text = "";
Password.Text = ""
// Some other code usually gets very long
//}
The worst is when you see code that calls an event handler, passing EventArgs.Empty, in order to trigger the same behaviour.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
-
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
I'm with JSOP.
-
The worst is when you see code that calls an event handler, passing EventArgs.Empty, in order to trigger the same behaviour.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
Interesting, I did not even realise there was an EventArgs.Empty, see the things you learn at CP
Never underestimate the power of human stupidity RAH
-
Interesting, I did not even realise there was an EventArgs.Empty, see the things you learn at CP
Never underestimate the power of human stupidity RAH
It's amusingly close to useles, b/c there's no MouseEventArgs.Empty, etc, which means you can only use it where an event takes the base class, not one of the derived ones.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
-
I'll second JSOP's method. Why cause function call overhead if you don't need to? Probably a moot point, especially if it's a button click, but something like a resize or repaint event could be called thousands of times.
- S 50 cups of coffee and you know it's on! Code, follow, or get out of the way.
Yeah, but I'm usually painting custom controls in layers, so it makes more sense to put each layer in its own method. Then you can turn those layers on and off at will and replace them quite easily. Chances are you're not going to paint anything at 30 frames a second so it doesn't matter that much. If you wanted that kind of performance, I'd look to something other than GDI/GDI+.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
Depends on how much they're doing. If it's just a couple lines, and won't be used anywhere else, I stick it in the event handler. If it's more substantial than that, or looks like it belongs in the model layer, or will be called from elsewhere, then I move it to a separate function.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)i agree... couple of lines, not worth the effort... a lot of lines, probably will make the code a lot cleaner
-
I only do it if the same code can be called from non-event code.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997good point
-
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
Yeah, only if large, have common code, or need to be on a separate thread, otherwise I don't sweat it.
wizardzz wrote:
All my event handlers call functions, nothing more.
That sounds needless, why not simply rename the handlers to whatever the methods are named?
-
The worst is when you see code that calls an event handler, passing EventArgs.Empty, in order to trigger the same behaviour.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
I pass
nullinstead. -
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
There isn't any one way to split this stuff up and everyone has their own way of understanding it. My rule of thumb is that every chunk of code (function, event handler, whatever) is relatively simple to understand on it's own. Code with too many function calls can be harder to understand then 3,000 line nested if and switch statement monstrosities. If you have to go poking around in 5 or 6 files just to understand what one method does, that's a complete mess. As long as you stay away from the super long or super short clever function extreme, you should be good. As far as your team is concerned, the most important thing is that you guys roughly agree on the basics.
Curvature of the Mind now with 3D
-
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
wizardzz wrote:
it is driving me mad looking at and updating code that doesn't do it
Perhaps a refactor is in order? The senior engineer would learn from it and it would reduce your angst. Double win.
wizardzz wrote:
All my event handlers call functions, nothing more.
Excellent. My WinForms event handlers call methods in the
Form's view model. /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Not a question, more of a survey. How many people here always separate code from event handlers, especially Form events. I always do it, but it is driving me mad looking at and updating code that doesn't do it, written by a senior engineer. All my event handlers call functions, nothing more.
Craigslist Troll: litaly@comcast.net "I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
Always always always... Well - sometimes while developing and testing I don't immediately - but I always try and move code out of the handler because otherwise some goose will come along and call the handler in order to execute the code
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
