Behavior Difference in KeyDown (masking KeyCodes)?

[rubbernilly]

Hello, all. It's been a while since I darkened these corners, but I trust you've kept the place up in my absence. I am digging out some code from an old .mdb file and attempting to update it and purpose it in a new 365 ACCDB. This sort of a thing had worked in the mdb, but doesn't in the accdb, and I'm wondering if there is a known work around?

I'm trying to leave an easter egg in a form using a key sequence. If the user enters the passcode in sequence (caught the KeyDown event), then the easter egg is unlocked. The only thing is, the keys CTRL, SHIFT, and ALT must all be held down while they do it. In the mdb file, I could do this:

[pre]
Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
Dim intShiftDown As Integer, intAltDown As Integer, intCtrlDown As Integer

'Use bit masks to determine which key was pressed.
intShiftDown = (Shift And acShiftMask) > 0
intAltDown = (Shift And acAltMask) > 0
intCtrlDown = (Shift And acCtrlMask) > 0

'do other stuff with the value (like compare it to a hash)
'for demonstration/MRC purposes, I'll just debug.print
If intShiftDown And intAltDown And intCtrlDown Then Debug.Print KeyCode

End Sub
[/pre]

That would work (in the MDB) to give differentiated values for keys pressed. In the ACCDB, however, everything flattens to KeyCode 16, and I can't detect what was pushed along with CTRL, SHIFT, and ALT.

Ideas?

 

[strongm]

You logic is wrong - you need to look for the Keycode first, and then check which of the special keys are pressed (since KeyCode will only return the most recent key pressed). And this was true with MDBs as well. Honest.

>everything flattens to KeyCode 16
Nope - depends what order you press CTRL, ALT and SHIFT

 

[rubbernilly]

Thanks for the reply, strongm...

TL;DR version: it's working. Thanks for sending me back to the logging/drawing board to look more closely at what output it was giving me.

To your points:
You're right that the keys don't always flatten to 16... that must have been my unconscious motor pattern to always arrive at that key last. However, the other point (about the logic being backward) doesn't matter -- at least for my application. Testing for a key in sequence while also having those 3 keys pressed is a logical AND, where both tests have to pass. It doesn't matter whether I test for the 3 conditions first or the KeyCode first. My problem had been that I was using the number pad for input, and the numbers there were not triggering the KeyDown event, at least with the 3 keys pressed. With the 3 keys NOT pressed, the keypad numbers trigger the event and register to the KeyCode; however once the 3 keys are pressed, nothing registers to the KeyDown event from the keypad. I don't seem to remember that particular quirk from the MDB version, but it won't limit what I want to do with this one.

Many thanks!