Window.KeyUp doesn't fire

General
1

Has been discussed before (years ago), and I’d hoped it was fixed long ago.
As the subject states. No matter what you return from keydown, keyup never fires. the window has no controls, so nobody can steal the event.

2

Which control ? Just the window ?
Which version of Xojo ?

Have you created a small project demonstrating the issue, and attached it to a feedback report ?

I just verified in 2016R3 Keydown fires in a plain window, AND KeyUp when True has been returned in Keydown.

Under Windows 10.

3

I just created a single window with nothing more than a KEYUP and KEYDOWN event… .and I too cannot get KEYUP to fire regardless of what I have KEYDOWN do.

and according the the LR… KeyUP should always be called regardless .

I’m on macOS

4

I’m with Dave. macOS 2019r3. the project can’t be simpler, like Dave: 1 window, 2 events: never a keyup.

Sam Rowlands reports this over a year ago, verified but never fixed: <https://xojo.com/issue/52938>

5

You should probably mark this thread as answered since now you know it’s not fixed.

6

Maybe I am coming from an alternate timeline, but I have always believed that in Desktop, one has to return True in Keydown for KeyUp to fire.

My little Windows test shows clearly that when True is returned in Keydown, KeyUp does fire. And of course KeyUp does not fire when false or nothing is returned in KeyDown.

I believe the error is not in the language, it is in the vague formulation of the LR.

<https://xojo.com/issue/58741>

58741 - The LR is ambiguous about Desktop keydown/keyup

Steps: See Window.KeyUp doesn't fire - General - Xojo Programming Forum

Obviously, the LR needs to make it clear that KeyUp won’t fire if True is not returned in KeyDown.

Here:
http://documentation.xojo.com/api/deprecated/window.html#window-keydown

This is not precise enough. It lets the reader believe that KeyUp will always fire. When in fact, it fires only when True is returned in Keydown:

“Returns a Boolean. Returning True means that no further processing is to be done with the Key, although the KeyUp event is still called.”

7

BTW, if for some reason you still want to know when the user releases a key, you can use a 20 millisecond multiple timer started in Keydown to monitor Keyboard.AsyncKeyDown().

Something like this in the timer Action event handler:

[code]Dim keydown as boolean
For i as Integer = 0 to 256
If Keyboard.AsyncKeyDown(i) then keydown = true
next

If not keydown then
me.mode = Timer.ModeOff
// Here goes code you would put in KeyUp
'Do Stuff
end if[/code]

If you need to know the key, put it into a property in Keydown, so you can access it in the timer Action event later on.

Please forgive API 1.00. I am not able yet to do code from memory in API 2.00.

8

It seems like the same problem for container control.

9

I’ve also noticed the problem in container controls. Workaround is to add a canvas covering the container, then use the events in the container. Feedback #16577.

10

You mean to add an event on the canvas instead of the container, right?

11

Yes, add the events to the canvas.