Possible to "click" a button by code ?

  • Thread starter Thread starter Tee
  • Start date Start date
T

Tee

Hi,

Is it possible to click a button by code ?
I want it to be as simple as it can, eg : button1.click() ... any idea ?

assuming I don't know which sub will be fired when the button is click.
or is there any way to check the handler that the button have so we direct
call it ?


Thanks,
Tee
 
Hi Tee,

We love easy answers, but sometimes it helps to search this newsgroup.

This was an answer from Tom Shelton on Friday

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click, Button2.Click
....
End Sub

or...

Button1.PerformClick()

or...

Me.Button1_Click(Button1, New EventArgs())

I hope this helps,

Cor
 
Oh ... thanks a lot ...

I didn't notice the performclick while I see the member of a button.

Thanks.
 
Tee said:
Is it possible to click a button by code ?
I want it to be as simple as it can, eg : button1.click() ... any
idea ?
Click to expand...

Although the theoretical answer is "PerformClick", the real world answer
is "Just don't do that".

If you use such calls in your code, you definitively bind your code to
the user interface. Which is what any serious programmer wants to avoid.
What if the button against which you call PerformClick is removed? This
will break your code.

You should define an isolated, stand-alone handler function that does
exactly what you want and call it from the button click handler and from
the part of your code where you wanted to use PerformClick. This way,
changing the UI will be a zero impact operation.
 
Patrick Philippot said:
Although the theoretical answer is "PerformClick", the real world answer
is "Just don't do that".

If you use such calls in your code, you definitively bind your code to
the user interface. Which is what any serious programmer wants to avoid.
What if the button against which you call PerformClick is removed? This
will break your code.
Click to expand...

But then you wouldn't be able to compile, because there is no reference...

Don't get me wrong, I totally understand with your point. But I can't say
you don't want to bind "some" code to your UI. Just not "Business Logic
Code" (There is absolutly nothing wrong with having code that reacts to
changes in the BL, just as long as you don't change your BL from the UI. =)

-CJ
You should define an isolated, stand-alone handler function that does
exactly what you want and call it from the button click handler and from
the part of your code where you wanted to use PerformClick. This way,
changing the UI will be a zero impact operation.

--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(replace .xx with .fr when replying by e-mail)
Click to expand...
 
Hi Patrick,
If you use such calls in your code, you definitively bind your code to
the user interface. Which is what any serious programmer wants to avoid.
What if the button against which you call PerformClick is removed? This
will break your code.
Click to expand...

Sorry, but this is how Microsoft does it when you are using the designer.

Start first telling them that that is a wrong methode before you confuse
people who visits this newsgroup

Just my thought about this.

Cor
 
Cor said:
Hi Patrick,


Sorry, but this is how Microsoft does it when you are using the
designer.
Click to expand...

??
The designer attaches a handler to the click event of the button. But
nobody tells you that you *must* put your processing there. The handler
can be a one-liner just calling another routine, say MyRoutine, that
could also be called from another part of the program when necessary,
instead of calling MyButton.PerformClick. This is cleaner and not
confusing at all, IMHO.
 
Hi Patrick,

I would not say that I use it, better I do not use it and probably shall not
do that.

There is something that goes agains my thinking about programming.

Although it is in one short sentence totally clear what happens and that is
a big advantage.

If somebody find that important, than I think your arguments are not
statisfactionary to prevent that.

Just my thoughts,

Cor
 
Gonna actually have to go with Cor on this. Not because I necessarily
believe his arguments are the best, but the fact that I agree it doesn't
really matter. It's a matter of preference as far as I see it.

Think about a button click event handler signature.

private sub button1_click (sender as object, e as System.EventArgs)

How often do you actually use the sender or event args objects? Probably
very little, in which case the way you call it isn't important... just
preference... its just a friggin' button.

Second of all. Processing? What processing? UI Logic? Why not? Business
Logic? Of course not...

Sometimes I think people take the idea of presentation vs. business logic
separation a little too far.

-CJ
 
Hi,

I don't see there is really any big down point for using PerformClick ...
if it's really that bad, I dont think it will exist in .NET ...

it must have it's own usage, so I guess we just depend on our needs and code
it.


Regards,
Tee.



Patrick Philippot said:
Tee said:
Is it possible to click a button by code ?
I want it to be as simple as it can, eg : button1.click() ... any
idea ?
Click to expand...

Although the theoretical answer is "PerformClick", the real world answer
is "Just don't do that".

If you use such calls in your code, you definitively bind your code to
the user interface. Which is what any serious programmer wants to avoid.
What if the button against which you call PerformClick is removed? This
will break your code.

You should define an isolated, stand-alone handler function that does
exactly what you want and call it from the button click handler and from
the part of your code where you wanted to use PerformClick. This way,
changing the UI will be a zero impact operation.

--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(replace .xx with .fr when replying by e-mail)
Click to expand...
 
Hi Herfried,

It was more on that the UI should be disconnected from the event, although
that was how I did read it (not the code itself).

This part of the message.
------------------------------------------------------------------
If you use such calls in your code, you definitively bind your code to
the user interface. Which is what any serious programmer wants to avoid.
What if the button against which you call PerformClick is removed? This
will break your code.
----------------------------------------------------------------------
designer.

What? It doesn't /call/ any event handlers.
Click to expand...
But let us not make it bigger than it is.

Cor
 
Cor,

* "Cor said:
It was more on that the UI should be disconnected from the event, although
that was how I did read it (not the code itself).
Click to expand...

OK, that's how I understood your message too, but I was not sure about that.
This part of the message.
------------------------------------------------------------------
If you use such calls in your code, you definitively bind your code to
the user interface. Which is what any serious programmer wants to avoid.
What if the button against which you call PerformClick is removed? This
will break your code.
----------------------------------------------------------------------
Click to expand...

ACK, that's a little bit misleading, at least for me as a non-native
speaker. Certainly you have the same problems in getting the right
interpretation.
But let us not make it bigger than it is.
Click to expand...

:-)
 
Hi Herfried,
ACK, that's a little bit misleading, at least for me as a non-native
speaker. Certainly you have the same problems in getting the right
interpretation.
Click to expand...

I am sure I did not misunderstood it. And although Patrick is French, I also
do not think that he wrote it wrong. It is just an idea I do not share with
him.

:-))

Cor
 
Cor... I'm fairly certain the reason behind Patrick's suggestion is the
same as mine. That one is likely going to have a menu item and a toolbar
button and possibly the OnClosing and maybe even a timer event which needs
to process things. In many cases the "same" thing., for instance "saving or
cancelling changes." If you write the code directly into the button event
handler you pretty much have to cut and paste the code you have in one event
into the other event.

You have to admit that duplicating the code is extra work and can result in
the two copies getting out of sync. So Patrick (I'll guess) and I just
avoid it right from the start by not doing that. _Something_ initiates the
call to "SaveData" but we don't honestly care who or what does it. It could
be the "Save" button, it could be the Save menu choice, it could be the
"autosave" routine when the user decides to close the window.

Granted there are lots of ways to accomplish things... I can't help but
think

<button click event>
PromptUser()
SaveData()
SetUIStuff()

and things along those lines is easier to understand than directly imbedding
the lines of code used in the PromptUser, SaveData and SetUIStuff routines.

I seriously cannot understand why this has become an issues suddenly? Are
there no more pressing problems to solve :-)

Tom
 
Hi Tom,

I find not one solution I have seen until now nice for forcing an UI event.

Those are always solutions on rare places somewhere in a program and are in
my opinion always hard to find.

As you stated, it can be a menu click, a forcing at a close, a button, or
whatever.

The solution from Patrick looks to me than one of those, which has the
thought that with minimizing the used code possibilities, the problem is
solved. I think it is not.

(For me this is not the only one, by instance the same problem is with
making controls invisible, hiding etc).

Moreover, I love solutions, but I hate bandages.

I hope that I make my whys a little bit more clear with this.

Cor
 
Cor said:
I find not one solution I have seen until now nice for forcing an UI
Click to expand...
event.

I tend to agree but while the suggestion was posted in this thread it wasn't
intended to be an example of how to force a UI event. :-)
As you stated, it can be a menu click, a forcing at a close, a button, or
whatever.
Click to expand...

That's one example. More to the point perhaps... consider a Tic-Tac-Toe
game (Naughts & Crosses for the English.) One can place all the code that
changes a square from a blank image to an "X" or "O" directly in a
picturebox click event and it would absolutely work. But if the click event
called a method named Game.UpdateSquare it would tend to be more clear.

And we know where to go if there is a bug. Not the click or double-click
event but rather to the method of the TicTacToe object responsible for
drawing the square. Furthermore that method can check any rules needed as
well as the current state of the game. So could the click event itself but
then some code is either duplicated in the click event or the click event
queries the TicTacToe object to see what it should do.

I'm fairly certain that was the point of "isolating" the event that
(notifies an action needs to occur) from the code that (makes the action
occur.)
Moreover, I love solutions, but I hate bandages.
Click to expand...

I'm with you there!

Tom
 
Back
Top