Button Click

[Lop]

Button.PerformClick();
or
Button_Click(null,null);

Which method do you use?

[moonrise]

Button_Click(null,null);
is the method i use

[Crane]

Button_Click(null,null);
is the method i use

Same here.

[brackett]

First off, why do you have any code in your button event handler? If it was in a (hopefully well named) method, you could just call it instead.
But, okay, you've got it in your event handler. Well, you should still probably call Button.PerformClick. Why?
For starters, you may be on another thread. And calling the event handler directly isn't going to marshal the call to the UI thread. That may or may not be a problem depending on your handler code.
Secondly, you're passing null as the sender parameter (and the eventargs, but nobody uses the eventargs anyway). If the handler is expecting to use that parameter (perhaps you have the same button handler for multiple buttons, and it's expected to get the calling button from the sender parameter), now it'll get a null reference exception - not good.
Thirdly, what if there's another event handler attached to the Button.Click event? By calling your handler directly, the other handler(s) won't be fired. Maybe this is what you want, but probably not.
So, to answer the question: if I use it, I'd do Button.PerformClick() - but I'd try not to use it to begin with.

[Jordan]

First off, why do you have any code in your button event handler? If it was in a (hopefully well named) method, you could just call it instead.
But, okay, you've got it in your event handler. Well, you should still probably call Button.PerformClick. Why?
For starters, you may be on another thread. And calling the event handler directly isn't going to marshal the call to the UI thread. That may or may not be a problem depending on your handler code.
Secondly, you're passing null as the sender parameter (and the eventargs, but nobody uses the eventargs anyway). If the handler is expecting to use that parameter (perhaps you have the same button handler for multiple buttons, and it's expected to get the calling button from the sender parameter), now it'll get a null reference exception - not good.
Thirdly, what if there's another event handler attached to the Button.Click event? By calling your handler directly, the other handler(s) won't be fired. Maybe this is what you want, but probably not.
So, to answer the question: if I use it, I'd do Button.PerformClick() - but I'd try not to use it to begin with.

Nice post Brackett.

I think what is being said here is you click a button such as button1
button1_click() {
params = true;
callFunction(params);
}

So when you need to execute this again from inside your code such as ran with a param you can instead call the button1

button1.performclick(); instead of retyping
params = true;
callfunction(params);

With the above example it is hard to see why you would call the button function instead of just callfunction(true). button clicks that call multiple functions with larges amounts of data that require information based on click location or whatever may need code insde of the button function.

That being said, I see both ways as beneficial and I do not see a reason why you would or wouldn't put code inside of the button function - that is what it is for, correct?

[brackett]

Nice post Brackett.

I think what is being said here is you click a button such as button1
button1_click() {
params = true;
callFunction(params);
}

So when you need to execute this again from inside your code such as ran with a param you can instead call the button1

button1.performclick(); instead of retyping
params = true;
callfunction(params);

With the above example it is hard to see why you would call the button function instead of just callfunction(true). button clicks that call multiple functions with larges amounts of data that require information based on click location or whatever may need code insde of the button function.

That being said, I see both ways as beneficial and I do not see a reason why you would or wouldn't put code inside of the button function - that is what it is for, correct?

That's way too UI centric for me. Except in quick 'n' dirty situations, I'd prefer that any real logic be handled by a business object (or, at the very least, a decently named method in the Form) - not in a UI event handler. You get the benefit of reusable business objects containing all the "processing" logic, easier testing of your methods (automated testing of a GUI is pain that I really don't want to get any better at ), decent names, and being able to swap out your GUI code (relatively) effortlessly. The UI event handler only serves as a notification that a user clicked the button, and the Form code maps that button click to a business method.
Basically, the only thing a Button.Click event handler has access to is the sender and an empty EventArgs parameter. Nothing useful can be gleaned from that that the business object would need. In your example of grabbing the click location, calling the event handler directly wouldn't help - as the user didn't actually click.