Call Sub vs. fake a key press

[Ricky W. Hunt]

First, the subject probably doesn't use the correct terms but I'm not sure
what it's called in VB.

I'm writing a media player app. The subroutine that handles the "open file"
button contains an If statement to see if a file was already playing and if
so executes some code to stop the previous file from playing among other
things. There's also a "stop" button on the form that contains the exact
same code. Obviously it would be easier if there was just one subroutine
containing the code and that sub would be called from the If in the open
routine and from the stop routine. My question is, is there a way to make
the program think the "Stop" button was pressed? I.E. is there anything
statement I can put in the If statement in the "open file" sub that will
"trigger" just the same as if the "stop" button had been pressed? If so, are
there any caveats to faking a button click from within the program versus
just putting the code in a sub and calling it from both events?

 

[Lucas Tam]

I can put in the If statement in the "open file" sub that will
"trigger" just the same as if the "stop" button had been pressed? If
so, are there any caveats to faking a button click from within the
program versus just putting the code in a sub and calling it from both
events?

You can just call the sub like:


MyButtonPressEvent(Me, nothing)

The only cavet is your event arg parameter will be empty - unless of course
you pass the eventarg as well.

 

[Jay B. Harlow [MVP - Outlook]]

Ricky,
What kind of "buttons" are we talking about?

Rather then calling an event handler directly, as there may actually be
multiple event handlers attached to the button. You can simply call
Button.PerformClick.

Hope this helps
Jay

 

[Ricky W. Hunt]

Rather then calling an event handler directly, as there may actually be
multiple event handlers attached to the button. You can simply call
Button.PerformClick.

That's exactly what I was looking for. Thanks.

 

[Cor Ligthert]

Ricky,

Although the sample from Jay goes probably in most situations, keep in mind
that this is only with the click, where you ask for the key press this does
not real function because you do not know which key.

As Lucas stated when you want to transfer the event you are in trouble with
the PerformClick.

See this sample beneath I made special for this. In the first buttons is an
emulate of a click event, which is an event with almost no event
information.

The second button fakes a key press here you can see that a key press is
something else than a click.

That button2 is called by button1 by the way, so do not misunderstand that.
You can see that in the sample because when button1 is clicked it says that
it was button2

\\\
Private Sub Button1_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button1.Click
Button2.PerformClick()
End Sub
Private Sub Button2_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button2.Click
Dim mypress As New KeyPressEventArgs("D"c)
TextBox1_KeyPress(sender, mypress)
End Sub
Private Sub TextBox1_KeyPress(ByVal sender As Object, _
ByVal e As System.Windows.Forms.KeyPressEventArgs) Handles _
TextBox1.KeyPress
MessageBox.Show("I am clicked by key " & _
e.KeyChar & " in " & _
DirectCast(sender, Control).Name)
End Sub
///

I hope this helps a little bit?

Cor

 

[Ricky W. Hunt]

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

Thanks Cor. I got that above part to work earlier and it does just what I
wanted. I just wondered if that was standard procedure or do people prefer
to put the common code in a sub and just call it from the two places. I can
see that if you go firing of clicks programmaticaly you could start a whole
chain of events you might not want.

 

[Cor Ligthert]

Ricky,

I have seen so much discussion about this in this newsgroup (without a real
conclusion) that it as with most with VBNet (why it fits most of us probable
better than the what more ancient languages) you can do it in more ways.

Therefore my idea about this is, do what you prefer, the same as that you
are not always using the same words in your native language.

However do it consequent.

I hope this gives an idea.

Cor

 

[Jay B. Harlow [MVP - Outlook]]

Ricky,
I prefer & recommend using Button.PerformClick, using "common code in a sub
and just call it from the two places" or using the same event handler for
multiple events.

I would not call, nor recommend calling, the event handler code directly as
Cor & Lucas showed.

In case you did not realize it you can actually have the same event handler
handle two events. Or the same event can be handled by more then one event
handlers

You can use AddHandler & RemoveHandler statement to connect multiple event
handlers, or you can list multiple controls on the Handles clause of an
event handler.

Either:

AddHandler Button1.Click, AddressOf Button_Click
AddHandler Button2.Click, AddressOf Button_Click

Or Cor's specific example could be simplified to:

Private Sub Button_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button1.Click, Button2.Click
Dim mypress As New KeyPressEventArgs("D"c)
TextBox1_KeyPress(sender, mypress)
End Sub

Hope this helps
Jay

 

[Cor Ligthert]

I would not call, nor recommend calling, the event handler code directly as
Cor & Lucas showed.

To fake a key press Jay

Can you show me how you do that and not faking a button click?

I would recommnend this faking a button click. However a keypress???????

Cor

 

[Cor Ligthert]

Typos and maybe not clear enough

I would not call, nor recommend calling, the event handler code directly as
Cor & Lucas showed.

To fake a key press Jay?

Can you show me how you do that while faking a button click?

(faking keypress char D as I did)

I would recommend faking a button click with a performClick.

However a keypress???????

Cor

 

[Cor Ligthert]

Jay,

Reading it again,

Or Cor's specific example could be simplified to:

Private Sub Button_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button1.Click, Button2.Click
Dim mypress As New KeyPressEventArgs("D"c)
TextBox1_KeyPress(sender, mypress)
End Sub

Hope this helps

What did you simplified in that, it is exactly the part as I showed how to
fake a keypress there is nothing changed?

The other part was to show that a performclick as you recommended would not
go in this situation.

Cor

 

[Jay B. Harlow [MVP - Outlook]]

Cor,
You had two event handlers Button1.Click and Button2.Click where the first
simply called the second. I used that two show that the OP could have used a
single event handler for both buttons.

Hope this helps
Jay

 

[Jay B. Harlow [MVP - Outlook]]

Cor,
I would not "fake a keypress".

The keypress is invoking a command.

The button is invoking a command.

In both cases I would simply "invoke the command", where the "command" is
either a command object via the Command Pattern, or a method in the current
object.

I'm *not* saying "faking a keypress" is bad or anything, I am saying I would
take a more pure OO approach.

If I really needed my program to see the "D" key when I pressed the button,
I would use SendKeys

Private Sub Button_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button1.Click, Button2.Click
SendKeys.Send("D")

End Sub

However I would only use SendKeys if another "more appropriate" method was
not available, such as Control.SelectNextControl.

Again I am not saying you are wrong, I am stating alternatives.

Hope this helps
Jay

 

[Cor Ligthert]

Jay,

I used that button only to start the sample action not to show how a button
was working, I definitly would not do it this way. Did you look at the
subject by the way that is where I am all the time refering too.

Cor

 

[Cor Ligthert]

Jay,

I would not "fake a keypress".

See my other comment.

Cor

 

[Ricky W. Hunt]

Ricky,

I have seen so much discussion about this in this newsgroup (without a real
conclusion) that it as with most with VBNet (why it fits most of us probable
better than the what more ancient languages) you can do it in more ways.

I would hazard to guess the confusion is usually from programmers who knew
BASIC but not VB or have never programmed a Windows app. We seem to
understand what we want but don't know the current syntax (which seems to
change with every version...LOL). Thanks.

 

[Ricky W. Hunt]

Ricky,
I prefer & recommend using Button.PerformClick, using "common code in a sub
and just call it from the two places" or using the same event handler for
multiple events.

I didn't know if this was even available when I asked but it seemed like
something people might want to do. It didn't even dawn on me that the event
handling routines are just subs that I could call at will (will null
parameters). I'm new to Window's programming (though I've programmed since
the late '70s and professionally since the '80s - on mainframes) so I wasn't
sure if anything happened when I called the routines or not. I'm still
trying to digest all the events that spawned even from a simple button
click.

I would not call, nor recommend calling, the event handler code directly as
Cor & Lucas showed.

That approach appeals to me because (as I said above) I'm still not sure
what all events are created (and in what order) when do a normal click and I
didn't want half-a-dozen (or more..) things going off when I just wanted the
one. Is all the PerfromClick does is call the subroutine? If so, it would be
fine. Certainly it doesn't fire off mousevers and everything else just like
I had physically pressed the button does it?

In case you did not realize it you can actually have the same event handler
handle two events. Or the same event can be handled by more then one event
handlers

Yes. I've learned this. Though in the case I was talking about I needed the
one button to do more than just what the other button did so I needed an
event handler for both.

You can use AddHandler & RemoveHandler statement to connect multiple event
handlers, or you can list multiple controls on the Handles clause of an
event handler.

Either:

AddHandler Button1.Click, AddressOf Button_Click
AddHandler Button2.Click, AddressOf Button_Click

Or Cor's specific example could be simplified to:

Private Sub Button_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button1.Click, Button2.Click
Dim mypress As New KeyPressEventArgs("D"c)
TextBox1_KeyPress(sender, mypress)
End Sub

Hope this helps
Jay

Yes. Thanks.

 

[Ricky W. Hunt]

Cor,
I would not "fake a keypress".

I guess I really meant "fake a button press" but I guess the ideas the same.

 

[Ricky W. Hunt]

I'm *not* saying "faking a keypress" is bad or anything, I am saying I would
take a more pure OO approach.

I've always been an organized programmer and used subroutines, flowcharts,
etc. So when I first heard about OOP (possibly in the late 80's/early 90's)
I thought "what's the big deal?" (but I really didn't grasp it all). Even
though I'm usually very A.R. (anal-retentive...not sure if the hyphen is
correct...) I thought it was overkill. I must admit now though that I've
used it some and figured out what it's doing I think it's great and much
easier to use than anything I've done before. Especially how easy it is to
call third-party functions that I really have no idea how they work. All I
have to know is the syntax and, boom, it's working.

 

[Jay B. Harlow [MVP - Outlook]]

Ricky,

one. Is all the PerformClick does is call the subroutine? If so, it would be
fine. Certainly it doesn't fire off mousevers and everything else just like
I had physically pressed the button does it?

Control.PerformClick, simply raises the Click event. It does not invoke any
of the mouse events.

Raising an Event calls the one or more event handlers (subroutines) that are
handling that event.

I believe SendKeys will cause all the keyboard events to occur. Which IMHO
would be a good thing.

Hope this helps
Jay