PerformClick works sporadically for just one button

[topshot]

I just noticed some weird behavior in one of our programs where the PerformClick for one button in the same GroupBox as several others doesn't always work. Essentially we're looking for function key presses (which rarely get used except when testing) to simulate touching various buttons on the touchscreen. The only thing I see potentially different with this particular button is routine being called handles 3 Click events. In the form's KeyDown event...

            Case Keys.F1
                btnDelLast.PerformClick()
                e.SuppressKeyPress = True
            Case Keys.F3
                btnEditPLU.PerformClick()
                e.SuppressKeyPress = True
            Case Keys.F4
                btnPrintPallet.PerformClick()
                e.SuppressKeyPress = True
            Case Keys.F5
                btnPrintRpt.PerformClick()
                e.SuppressKeyPress = True
            Case Keys.F10
                btnPrint.PerformClick() '< This is the problem child
                e.SuppressKeyPress = True

    Private Sub btnPrint_Click(sender As System.Object, e As System.EventArgs) Handles btnPrint.Click, btnPrint2.Click, btnRe_Print.Click
        If relabelMode = False Then... 'I have a breakpoint on the first line here to see if it hits though it would be obvious anyway if it did

Some times F10 works and some times it doesn't (while the other F keys always work) and I don't see a pattern. I can fix it by calling the routine directly...

            Case Keys.F10
                btnPrint_Click(sender, e)
                e.SuppressKeyPress = True

but I'm curious what the issue is. There are no tab pages and the button is always visible and enabled.

[Shaggy Hiker]

Does this happen in production, or only when running under the debugger? I ask because F10 is one of only two of those keys (the other being F5) that has some significant role in debugging, which makes me wonder if the IDE might not be messing with you.

[topshot]

It happens in both.

[jmcilhinney]

Are you disabling those Buttons at any time? If you have an accelerator key set on those Buttons then you wouldn't need any code at all and could just use those keys, e.g. Alt+D for btnDelLast.

[topshot]

Are you disabling those Buttons at any time? If you have an accelerator key set on those Buttons then you wouldn't need any code at all and could just use those keys, e.g. Alt+D for btnDelLast.

Never disabled though the main GroupBox may be made invisible (I think - not at work now) but only if one of those buttons is pressed to get it into rework mode. The problem exists from program startup though.

No accelerator keys since a keyboard is almost never used (factory floor system). The main reason I was concerned is we were going to configure an arduino board to simulate an F10 upon pressing a real button to print a label. When it wasn't working well I started looking into why.

[topshot]

Confirmed the button's enable property is never used. The GroupBox can be made invisible if one of the buttons not used with a function key in it is clicked, which makes a panel with another set of controls visible where the GroupBox is(was). A button on the panel will return visibility to the GroupBox.

Confirmed all properties on the problem button match with a button that works with a function key all the time.

The only thing I see different is the Handles is for 3 buttons rather than just one.

[Shaggy Hiker]

One thing you might try is changing that to some other F key. No other change, just that.

I'm still thinking that this is the OS messing with you in some way that is specific to F10. By changing to a different key for a test, you would rule that out. If the issue kept happening, then you'd know that it was nothing special about F10, but something about the code itself. If the problem went away, then you'd know that it was specific to the F10 key, though you wouldn't be any closer to knowing what it was.

[passel]

If you look closely at most applications, if it has a menu bar, if you press F10 then you should see the menubar go active, i.e. the first item on the bar should be highlighted. You can then use the arrow keys, etc.. to navigate the menu.

I wouldn't doubt that since Windows uses the F10 key, that the initial press of the F10 key may not be passed to the Form since focus has to shift to a menu bar, if you have one.

[topshot]

Menu bar isn't visible on this form unless an Advanced button is pressed (debug mode basically).

Doing Shaggy's suggestion points to code/.Net

            Case Keys.F9
                btnPrint.PerformClick() '< This is the problem child
                e.SuppressKeyPress = True
            Case Keys.F10
                btnPrint_Click(sender, e)
                e.SuppressKeyPress = True

F9 had the issue while F10 would work without doing anything else (order didn't matter).

[topshot]

It doesn't seem to be the Handles clause. It's not worth my time to debug any further. I was just curious what was up. It must be related to Windows F10 usage somehow, but works perfectly fine when I call the routine directly instead of using the method.

[Sitten Spynne]

Here's what I would do. You're two steps away from the Command pattern, and being one step away from it might be most appropriate.

When you have several UI actions that should do the same thing, it's not the best to implement the code inside of one event handler, then figure out how to make all of the event handlers synthesize that event. It's intuitive, but can result in weird situations like you see here.

The better thing to do is implement your logic in a callable method, then call that method from every event handler:

Private Sub DoPrint()
    ' Code to print.
End Sub

Private Sub btnPrint_Click(...) Handles So Many Print Buttons
    DoPrint()
End Sub

Private Sub Form8378_KeyDown(...) Handles Me.KeyDown
    Select Case e.Whatever
        ' ...
        Case Keys.F10
            DoPrint()
            e.SuppressKeyPress = True
        ' ...
    End Select
End Sub

This way we don't have to worry about if there's some other aspect of methods like PerformClick() that might be getting in the way. That you said this:

I can fix it by calling the routine directly...

Makes me wonder if that isn't part of the problem.

Now, I want to connect two things you said:

Some times F10 works and some times it doesn't (while the other F keys always work) and I don't see a pattern.
[...]
There are no tab pages and the button is always visible and enabled.

Menu bar isn't visible on this form unless an Advanced button is pressed (debug mode basically).

My guess is you have the problem either when the menu bar is visible or when it isn't. Odds are the way Windows handles F10 interferes with that. You might have a way around it, but personally I think people are more used to CTRL+P for printing. The F keys are often tricky and mysterious to users, they're far more likely to remember "P for Print".

[topshot]

My guess is you have the problem either when the menu bar is visible or when it isn't. Odds are the way Windows handles F10 interferes with that. You might have a way around it, but personally I think people are more used to CTRL+P for printing. The F keys are often tricky and mysterious to users, they're far more likely to remember "P for Print".

Menu bar was never being used. It exhibited the problem right from program startup where the menu bar isn't visible.

I believe the reason for using function keys is because the touchscreens being used have function keys along the side that can act like either the real key or be programmed to do certain actions. I don't believe the normal operators have ever used those or the normal keyboards (which aren't easy to get to) but Fx was included in the button text for any button using that functionality. It's only techs that may need the keyboard.

I wouldn't have been concerned by this odd behavior at all except that we are making an arduino act as an F10 keypress instead of sending a string on the virtual Com port when a real button is pushed in order to print a label.

[Sitten Spynne]

Bleh, that just makes things more complicated. You're dealing with some kind of exotic software keyboard that may not even be behaving the same way a physical keyboard operates.