Hi All, does anyone know why this doesn’t break for for CTRL-C in the KeyDown event of a ListBox? I noticed it in 2020r2, but tried it in 2015r4.1 and has the same behavior. CTRL-Z, CTRL-X and CTRL-V all break as expected. But CTRL-C doesn’t register. I thought it may have something to do with the system interfering with the event, but I would think it would happen with CTRL-X as well if that were the case. Any ideas as to why it will not get to the break for that section?
If Keyboard.AsyncControlKey = True Then ' Control key
Select Case True
Case Keyboard.AsynckeyDown(&h06) ' z key
Break ' code breaks
Case Keyboard.AsynckeyDown(&h07) ' x key
Break ' code breaks
Case Keyboard.AsynckeyDown(&h08) ' c key
Break ' doesn't break
Case Keyboard.AsynckeyDown(&h09) ' v key
Break ' code breaks
End Select
End If
I read somewhere on the forum to not use AsyncKeyDown in the KeyDown event so I simplified it some and still can’t get it to go into the KeyDown event when CTRL-C is pressed. z, x, and v work just fine:
If Keyboard.ControlKey = True Then
Select Case Asc(Key)
Case 22 ' v
Break
Case 24 ' x
Break
Case 26 ' z
Break
End Select
I assume there is some reason for this, but I can’t figure out why the c key works differently than the others when CTRL is pressed at the same time. If it is just the ‘c’ key by itself, I can pick it up in the KeyDown event, but not if the Control key is pressed at the same time.
My guess is that something at the window level has enabled the Cut menuitem and that is intercepting the Ctrl-c. I just tried a new project with nothing added to the window except an empty listbox with the keyDown code and each break was hit, including the Ctrl-c. However, if I add a data row to the listbox at Open and then click on that row, the Copy menuitem seems to automatically get enabled and Ctrl-c gets intercepted.
In fact, having a Break as the first line in the Keydown event shows that with a row selected in the listbox, the Ctrl-c doesn’t even get to the Keydown event.
As to why the Ctrl-[v,x,z] don’t I have no good explanation.
Thanks for checking it on your end, Dale. It’s a local app that will only be used by me, so I may just pick some other key. But if two people see this, I’m really surprised a lot of other people have not brought it up. I tried it under 2015r4.1 on an old Windows 7 machine and I see the same odd behavior. I was adding rows to the ListBox as well.
I’ll play around with it some more, and if I seen anything I’ll post it. If anyone else has any ideas, that would be great.
I found this on the Microsoft site, I wonder if this is related:
The CTRL+C and CTRL+BREAK key combinations receive special handling by console processes. By default, when a console window has the keyboard focus, CTRL+C or CTRL+BREAK is treated as a signal (SIGINT or SIGBREAK) and not as keyboard input. By default, these signals are passed to all console processes that are attached to the console.
It is referring to console windows, but I wonder if the Desktop App window is picking up these attributes somewhere?
Well, when a listbox has the focus, the “Copy” menu item is available (one can copy the selected row’s text).
“Undo” has to be implemented by the developper and is thus disabled by default.
“Cut” and “Paste” aren’t implemented because the listbox is read-only for the user; therefore they are also disabled.
Since “Copy” is the only enabled item among the 4 you mention, control-C triggers “Copy” (and is handled: it doesn’t go further). The other 3 aren’t handled by a menu item and is thus passed further (to the KeyDown event).
Yes, I think it is handled at the OS level before it gets to key down. I’d rather do the code myself, instead of relying on the system CTRL-C, because of different datatypes. Just easier for me to implement along with CTRL-V. But not a big deal since it is for in-house only, I’ll just pick another key combination. Thanks for taking the time to help!
Thanks for input. I thought I tried that in the IDE, but I will try again. I thought I read the OS was picking it first, but I’ll try that again today.
I’d class this as a bug as there is some hard coded system in place on the listbox to intercept certain menu functions if a menu is active on the window/app. It’s so ingrained that you can’t even add a menu handler for example on EditCopy to trigger instead of this feature so you have to use a workaround by going via an unrelated event then implementing a state machine to track what happened.
It looks like Arnaud has covered most of it above, your first block of code should work inside the EnableMenuItems event, if you store what happened in there on a window property you can read this in the keyup event and perform your action there. If you’re trying to overwrite the clipboard with some custom info then this would be the most pertinent route to make it happen.
It looks like @Greg_O_Lone spotted this problem back in September <https://xojo.com/issue/61892> but it was closed as by design, maybe @William_Yu can elaborate on that because being unable to intercept this feature using the correct methods provided to users (menu handler) does seem like a bug.
Since it has always worked this way we typically don’t claim those as “bugs.” Yes, it’s a bit of a grey area because it’s debatable for some things, but certainly ok to file a feature request to change the behavior and see how many people subscribe to it.
I’m working around it OK, it is just an in-house app, so I will not be pursuing any changes. If anyone else brings it up, then they can take it up if they want.
I should have searched instead of just taking Greg’s ticket as a new discovery, it seems like its been around for a while <https://xojo.com/issue/22072>
Its interesting that the workaround that Kirk mentioned 9 years ago is still relevant, if you change the menu’s name to EditDoCopy then things just work as expected both when using the menu and keyboard shortcut.
So essentially EditCopy et al are reserved names which never fire down to the developer, even for non-list boxes as I see the event doesn’t fire for TextFields either. It just boggles my mind.
As the issue is already marked as a verified bug I’ll leave it there, if this isn’t a bug, it might as well get documented somewhere to save confusion/time wasting. At least I know where to point people next time they ask.