PerformClick() doesn't work

[tekwrytr]

I have an application that requires data be entered, and after entering, a button is clicked to process that data. Clicking the button works just as it should--the data is processed properly.

In constructing a test module, I provide a set of data values, followed by:

btnWhatever.PerformClick()

Nothing happens. I have used this syntax for years, and it has always worked flawlessly. I have triple checked everything else and isolated the problem to the failure of the PerformClick().

Any experience with this, or any idea why it would happen? The PerformClick() is in a test subroutine that does nothing but fill textboxes and labels with default data, then calls the PerformClick() on the button to begin processing. Again, the button works fine, the data is entered as it should be, but the PerformClick() does not fire the click event.

Any ideas or insights will be greatly appreciated!
Thanks

[Pradeep1210]

Add a new form to your project and set it as startup form.
Then add 2 buttons to it and following code:

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
    MsgBox("Hello")
End Sub

If clicking both the buttons shows the same messagebox with "Hello" in it, then there is something wrong on your original form. It is not related to Button.PreformClick().

[tekwrytr]

The PerformClick() is not broken--it works in other areas. However, in some areas, it does not work. Specifically, it sporadically and arbitrarily seems to not work.

I am curious if anyone else has encountered this problem, and if there is a solution (aside from downloading a new version of VB and hoping for the best). In some areas, the PerformClick() works as it should. In others, it is simply passed over as if it doesn't exist.

[Pradeep1210]

The PerformClick() is not broken--it works in other areas. However, in some areas, it does not work. Specifically, it sporadically and arbitrarily seems to not work.

I am curious if anyone else has encountered this problem, and if there is a solution (aside from downloading a new version of VB and hoping for the best). In some areas, the PerformClick() works as it should. In others, it is simply passed over as if it doesn't exist.

NO, that won't happen without reason.
There is something bad in your code.
Can you show the complete codes where it is not working?
I would assume some error occurs but you ignore it by putting in try.. catch blocks etc.

[tekwrytr]

NO, that won't happen without reason.
There is something bad in your code.
Can you show the complete codes where it is not working?
I would assume some error occurs but you ignore it by putting in try.. catch blocks etc.

On the contrary, I think there is something wrong with Microsoft's code. Believing there had to be "something bad in my code" wasted a substantial amount of development time chasing ghosts that don't exist.

I finally isolated the cause by stepping through the routine one line at a time, and verifying that everything works as it should. It works fine when the button is clicked--it does NOT work when the PerformCLick() is called in the code. As I stated previously, the PerformClick() works fine elsewhere. Code snippet below:

Private Sub btnTestRun_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnTestRun.Click
chkContenderBox1.Checked = True
chkContenderBox2.Checked = True
chkContenderBox5.Checked = True
chkContenderBox6.Checked = True
chkContenderBox8.Checked = True
mintNumberOfContenders = 5

'*********************** TEST FUNCTION *************************************************************
txtEntryNameBox1.Text = "Runner1"
txtWinTimesBox1.Text = "121 121 121 121 121"
txtARTTimesBox1.Text = "121 123 125 127 129"
txtMultipleOddsBox1.Text = "10 10 12 20 25"
txtPLBoxesBox1.Text = "12457"
txtPLFinishPositionsBox1.Text = "24357"
txtPLGradesBox1.Text = "34556"
txtWPSBox1.Text = "12 2 1 2"
btnCalcBox1.PerformClick()
**************************************************************************************************

The last line does not fire the PerformClick(). The button works fine. THe problem is in the call to the PerformClick().

[Pradeep1210]

How does your btnCalcBox1_Click look like?

Can yo attach a sample application here that depicts the problem?
One form with 2 buttons and whatever code to show that problem occurs.

[JuggaloBrotha]

The only thing I can think of is maybe your btnCalcBox1 isn't Enabled (the Enabled property is still False), I don't think PerformClick() works if the button/menu item is disabled.

[Grimfort]

You say you are using this in a test module. Does that mean you are not showing the form? If the button is not visible, the click event will not be raised.

[tekwrytr]

The only thing I can think of is maybe your btnCalcBox1 isn't Enabled (the Enabled property is still False), I don't think PerformClick() works if the button/menu item is disabled.

That was one of the things that made it so mysterious--the button works fine when clicked. It does exactly what it should do. There is no code that disables it.

[tekwrytr]

You say you are using this in a test module. Does that mean you are not showing the form? If the button is not visible, the click event will not be raised.

The button is visible.

[tekwrytr]

My mistake--the button is NOT "visible" at the time the PerformClick() is fired, because it is on a tabbed pane.

I (incorrectly) assumed that because the data could be loaded into textboxes and labels, the button on the same pane should be able to be clicked.

I really appreciate all the suggestions and help. This is the first time I have encountered this particular problem, despite using PerformClick() literally thousands of times over the past four-five years.

Thanks again for all the help.

[Grimfort]

Out of interest, why do you even use perform click? Why not move the code into a method and call it from both/multiple places?

[techgnome]

It's a test harness... testing the clicking of the button. From the first post: "In constructing a test module, I provide a set of data values, followed by: ..."

-tg

[Grimfort]

/slapshead, I even mentioned that earlier .

[Shaggy Hiker]

I found this to be a really interesting thread. Controls on tabs can behave in some very unexpected ways, and this was just one more. The real value of a forum like this is that people, even if they miss part of the question (ha), can still make a suggestion that illuminates the problem in a whole new way and helps reveal the answer.

[tekwrytr]

Out of interest, why do you even use perform click? Why not move the code into a method and call it from both/multiple places?

Because I was one of those poor unfortunates who took several semesters of VB programming in college, from an instructor who believed that every app started with a form. with a big GO button in the middle. The idea was, build the form, click the button, then ask yourself. "what should happen now?" It seems foolish now, but it seemed to make sense at the time. Unfortunately, it also caused some bad habits to be internalized. Too many buttons is one of them.

As soon as I realized the "visible" constraint, that is exactly what I did. In the test routine, the methods are called directly. When the buttons are clicked on the form, rather than the code being in the click event of the button, all the click event does is call the method.

[tekwrytr]

I found this to be a really interesting thread. Controls on tabs can behave in some very unexpected ways, and this was just one more. The real value of a forum like this is that people, even if they miss part of the question (ha), can still make a suggestion that illuminates the problem in a whole new way and helps reveal the answer.

Yes. Especially when you realize I have been using VB for years, have used thousands of PerformClick() as shortcuts and never realized that if the button is hidden from view the function won't work. It is the type of thing that unless you know it, you would never suspect it.

It has been an illuminating (and humbling) experience to say the least. Again, thanks to everyone for all the help.

[Pradeep1210]

PerformClick() is just like when you click the mouse button. If the button isn't visible for one reason or the other, how will you click it?

I'll have to admit that all throughout my programming career there isn't one instance where I have really needed to use this PerformClick() method.

I usually prefer keeping the common code in a separate method and call it from all places it is required from. It is neater and also much reliable.
In the worst cases I code it like this:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
    Button2_Click(Nothing, Nothing)
End Sub
 
Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click
    MsgBox("Hello")
End Sub

[Grimfort]

However, if you mean this to be a real test, then you would have to change tabs first, which could of course have events that would not be fired if you called it directly. Depends on how thorough your test needs to be.

[JuggaloBrotha]

PerformClick() is just like when you click the mouse button. If the button isn't visible for one reason or the other, how will you click it?

I'll have to admit that all throughout my programming career there isn't one instance where I have really needed to use this PerformClick() method.

I usually prefer keeping the common code in a separate method and call it from all places it is required from. It is neater and also much reliable.
In the worst cases I code it like this:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
    Button2_Click(Nothing, Nothing)
End Sub
 
Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click
    MsgBox("Hello")
End Sub

If you're going to call the other button's click event sub directly, the least you could do is pass it the proper params instead of two Nothing's (in case sender is actually used in the event sub itself):

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
    Button2_Click(Button2, EventArgs.Empty)
End Sub
 
Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click
    MsgBox("Hello")
End Sub

But ideally, you should never need to use a Button's PerformClick() method nor should you need to call an event's sub directly either, the code should be placed in it's own sub (accepting the needed params) and called from the multiple places that it's needed.

[techgnome]

But ideally, you should never need to use a Button's PerformClick() method nor should you need to call an event's sub directly either, the code should be placed in it's own sub (accepting the needed params) and called from the multiple places that it's needed.

True... BUT... in the case of a test harness, you want to simulate the button's click event... now, granted, all that the button should be doing is calling a sub, but sometimes you need to be able to actually simulate the clicking itself.

-tg

[tekwrytr]

There are a number of buttons that must be clicked to "do stuff." Some are to select which datasets to manipulate, some for location, time, and so on. The application allows the user to make selections by clicking various buttons, then processes the appropriate data based on those selections.

Certain functions are repeated--at the users option--and perform programmatically in the manner of a nested loop. The selections made in the "outer loop" maintain state so the selections don't need to be made again for similar processing operations.

However, because of the nature of the app, after a data processing routine executes, numerous values are cleared. The PerformClick() is an easy way to get the user back to the "inner loop" for additonal processing.

[BD9000]

PerformClick() works on the main form fine (as do most methods) - it certainly won't work from a different form (unless the called form is active - which it can't be until the calling form closes, so it won't ever work), nor if the button is in a panel and most containers. That's the fatal design flaw of Windows going back to the very first version - you can't touch controls that aren't actually displayed on the screen - it's display dependent.

[JuggaloBrotha]

PerformClick() works on the main form fine (as do most methods) - it certainly won't work from a different form (unless the called form is active - which it can't be until the calling form closes, so it won't ever work), nor if the button is in a panel and most containers. That's the fatal design flaw of Windows going back to the very first version - you can't touch controls that aren't actually displayed on the screen - it's display dependent.

2011 thread dude...