Solved Key Events - Ctrl-Delete UnDetected

[dalski]

Built a simple testing form; in a separate db to obtain what the keys should be As per Richard Rost. Trying to assign KeyDown/ KeyUp the form itself one or the other:

• Seems ctrl-delete = Keycode-46 & Shift-2
• Frm - Key Preview = Yes
• The KeyUp event is detected but I cannot generate/ detect the combination 46-2; which is generated from my test (attached) to in my real db frm in question
• KeyUp/ KeyDown not tested simultaneously so that's not the issue
• Originally was trying to test with individual ctrls (textboxes) but event detected but multi-key undetected (obviously turning of KeyPreview property of form)
• Frm is datasheet - tried testing same frm in continuous frm; no joy

Sidenote - Seems KeyUp is more likely to capture a multi-key combination; guessing there is more of a generous timer between keystroke separation?

 

[arnelgp]

you also add Keypreview to the datasheet subform.

 

[dalski]

Thanks Arnel, I didn't have property set in parent frm, regardless the event was still firing but the multi-key combination not detected. I still cannot detect the multi-key combination. Maybe because the record is going in edit mode with depressed keys (pencil is indicated in selector).

 

[arnelgp]

i tried it with your sample db.
even in edit mode (pencil), it detect the ctrl-del key.
open the db in post 2 and edit edit a record and press ctrl-del.

 

[dalski]

Thanks, I can't seem to detect it. Sure it detects the event firing, as it did without the parent having it's Key Preview property = True, & without the duplicate procedure (actually I didn't even have a subform in there; you kindly assumed correctly so thanks).

But it does not detect the ctrl-del shortcut combination of 42-6. Which happens regardless whether the parent contains the same code & has it's Key Preview = No.
The subform's event fired without all that, the key combination is not detected. So I must be wrong with 46-2 as key combination ctrl-del. But it was what generated from test. So maybe OS reserved shortctut; I don't think it is.

 

[Imb]

Thanks, I can't seem to detect it. Sure it detects the event firing, as it did without the parent having it's Key Preview property = True, & without the duplicate procedure (actually I didn't even have a subform in there; you kindly assumed correctly so thanks).

But it does not detect the ctrl-del shortcut combination of 42-6. Which happens regardless whether the parent contains the same code & has it's Key Preview = No.
The subform's event fired without all that, the key combination is not detected. So I must be wrong with 46-2 as key combination ctrl-del. But it was what generated from test. So maybe OS reserved shortctut; I don't think it is.

In your code you use: KeyCode = 42 & Shift = 2

& is for concatenation, better use AND:

(KeyCode = 42) AND (Shift = 2)

 

[dalski]

Thanks, agreed but still yeilds no result sadly, mystified as to why the combination (not event) is not detected.

& is for concatenation, better use AND:

Even if I nest the If's despite Keycode being 42 (well at least in my tests) does not catch:

Private Sub Form_KeyUp(KeyCode As Integer, Shift As Integer)
  MsgBox "keycode: " & KeyCode & " - Shift: " & Shift
  If KeyCode = 42 Then
    If Shift = 2 Then
      MsgBox "ctrl del detected"
    End If
  End If
End Sub

 

[arnelgp]

Ctrl-Delete is a normal event of the Textbox to delete Text.
so the "Normal" event will take place before your own (made event).

here i remove the keyup event on both Main and subform.
I add a Class on the subform (see Load event of the subform).
i use Timer event on the subform (TimerInterval=50) to somehow catch the Ctrl-Del combination
and Undo it.

 

[dalski]

Thanks Arnel

 

[Imb]

Thanks, agreed but still yeilds no result sadly, mystified as to why the combination (not event) is not detected.



Even if I nest the If's despite Keycode being 42 (well at least in my tests) does not catch:

Private Sub Form_KeyUp(KeyCode As Integer, Shift As Integer)
  MsgBox "keycode: " & KeyCode & " - Shift: " & Shift
  If KeyCode = 42 Then
    If Shift = 2 Then
      MsgBox "ctrl del detected"
    End If
  End If
End Sub

Beware!
vbKeyDelete = 46
vbKeyPrint = 42

Did you really test for "ctl del"?

Perhaps better to use the Constant vbKeyDelete.

 

[dalski]

Thanks, I do agree on a later test I got 46 for del key. But I tested countless times prior & got 42 for the delete key. Really strange, print is quite a different place on my keyboard so I'm pretty sure I wasn't mis-keying, really strange. I'd be thinking the same if I was reading this; donkey miss-keyed.

 

[isladogs]

I find KeyDown works better than KeyUp and use the descriptors rather than the value
The following works but the KeyUp equivalent didn't fire for me either:

Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)

    Select Case Shift
    
    Case acCtrlMask       'Control pressed
      
        If KeyCode = vbKeyDelete Then '46
            MsgBox "Ctrl+Del detected", vbInformation, "KeyDown info"
        End If

    End Select

End Sub

 

[BlueSpruce]

Maybe detecting key combinations, such as Ctrl+Delete, is not reliable in KeyUp and KeyDown events, due to time related reasons?

 

[Minty]

I agree with Colin, I always use the KeyDown event when trapping keystrokes.
It never occurred to me to try and use KeyUp.

 

[dalski]

Maybe detecting key combinations, such as Ctrl+Delete, is not reliable in KeyUp and KeyDown events, due to time related reasons?

My thoughts exactly, as per OP it seemed that KeyUp provides a more generous time constraint & I got slightly better results; albeit not good results & spent all afternoon/ eve & most of this morning. Thank god Arnel saved me.

Thanks Colin, at least it's a little reassuring that you also had bad luck with it. The experience has left my quite dubious on Keyed Events. Even the simplest thing as the test producing different keystroke results on debugging what was pressed is most concerning.

 

[BlueSpruce]

My thoughts exactly, as per OP it seemed that KeyUp provides a more generous time constraint & I got slightly better results...

Perhaps inserting a time delay, like Sleep (500) somewhere might help proper detection?

 

[dalski]

Yeah that's what Arnel did with the class; works great; I'm very grateful.

 

[The_Doc_Man]

The thought occurs to me that "CTRL/DEL" is a keyboard shortcut for "delete word to right of cursor" which means it MIGHT be pre-empted for program use, particularly since the change to references a couple of decades ago that rearranged libraries. VBA stopped being "built-in" and became just another DLL that EVERY Office utility could use. Can't remember WHEN that happened, but VBA got changed to make it uniform across the Office spectrum.

 

[isladogs]

@dalski
Just tried Arnel's code. It detects Ctrl+Delete in both the form and subform but only undoes that action in the subform.
In the main form, it triggers the message about undoing changes but doesn't actually do so in my tests.
All characters to the right of the cursor are deleted in the main form.

On checking the code is only in the subform. So the subform is detecting that key sequence even though the main form has focus.
Adding the same code to the main form didn't change anything other than the message appearing twice
Does that matter in your situation?

 

[isladogs]

The thought occurs to me that "CTRL/DEL" is a keyboard shortcut for "delete word to right of cursor" which means it MIGHT be pre-empted for program use, particularly since the change to references a couple of decades ago that rearranged libraries. VBA stopped being "built-in" and became just another DLL that EVERY Office utility could use. Can't remember WHEN that happened, but VBA got changed to make it uniform across the Office spectrum.

The VBA Library is still built-in and cannot be removed. That has always been the case since Access 95