TextField KeyDown Event


I have an application I am using a barcode scanner to enter the code into a text field. The scanner appends an “enter key” on the back of the barcode scanned. In most cases this works fine. I look for the enter key in the KeyDown event of the TextField using

If Keyboard.AsyncKeyDown(76) Then do something.

However, sometimes it does not detect the enter key and I suspect that it sends it so fast that by the time the KeyDown event fires the key is no longer down.

It appears from the language reference my understanding of this is wrong and indeed it could be a timing issue. From the language reference:

"The Keyboard module is used to determine if particular keys are being pressed. The async version of each keyboard property tells you the immediate state of the key. If you want to know the state of the key when an event was queued, you should use the non-async version of the properties. These properties are updated constantly during code execution. "

Two questions;

Where is the information on the non-async version of the properties and should I be using that?
I suspect I am going to have to search the string for the enter key using InStr() every key down event but I’d like input and ideas on a better way.


it sounds like you are trying to “simulate” a keypress? if so, none of those functions you mention would do that… they are all to detect actions ON the keyboard… and (76) is not the code for ALL keyboards if I recall…

76 is 0x4c which is the [ENTER] key, the [RETURN] key is 36 or 0x24, but again only for the US keyboard

in the keydown you PROBABLY want to look for the ASCII value of the key (not the keycode)… and the would be 13 or 0x0D

Why do you look for the hardware code, instead of simply using key = chr(13) in the keydown event ?

There are very few situations (none that I can think off off the top of my head) where the KeyCode is necessary…

But certainly not with a device that is not a keyboard and sends characters to a TextField through some pipeline process, would that be blueTooth, USB, serial or otherwise. I think in this instance he would get Return normally by looking at Key in the Keydown event.

Michel, that is exactly my point… I cannot think of a situation that requires KEYCODE, 99.99% would require the ASCII or UNICODE key VALUE where [RETURN] would be 0x0D and [ENTER] would be 0x03

Hi Dave and Michael,

Thank you both for your quick replies

The barcode scanner emulates the keyboard. It is a keyboard wedge and acts like a USB keyboard. It sends the barcode it scans followed by the enter key, just as if the user entered the value with the keyboard and pressed the enter key, albeit VERY fast.

I was using “If Keyboard.AsyncKeyDown(76)” to determine if the key that generated the event was the enter key. Every character generates the keydown event. However, after reading the docs it appears that this assumes the key is still pressed down when the event code is called, which I think is the issue.

The keydown event does return “Key” which is a string that contains the key. I believe your suggestion of looking for CHR(13) is a better approach. I believe AsycKeyDown is not reliable in this case due to timing.

Thank you, I will try in the AM and report back.

I use very seldom AsyncKeyboard, only when I cannot get the value from keyDown key.

You should never use asynckeydown in a keydown event. Period.

KeyCode ?

docs said: the following tables give the keycodes for the US keyboard…

What about the keyboard layout (whan it is different than the US keyboard ?

Of course, if your softwre will never be used on non US keyboard (what about Dvorak layout ?), forget this entry.

Emile… the point is… KEYCODE is next to useless… I’m not even sure why Xojo wasted so much space in the documentation, since there is so little need for it, and it is near impossible to localize you app if you rely on KEYCODE

I am 100% OK with that. I never use it since I know QWERTY (USA and some others) <> AZERTY (FRANCE), but same KeyCode (that is why I talked about keyboard layout: the letters that appears in the keyboard…).

Michael and Dave,

Thanks for the help that did the trick.

Well, I routinely use AsyncKeyDown to monitor keys while I have an app sitting in the background. Also, in Char Menu for Windows, I found out that a window in the background no longer received buttons action. As a result, I ended up using AsyncKeyboard for the whole application.

That said, I agree, using keycodes is not clever in general, especially since it does not react quite the same on each platform. On Mac, keycodes change with the keyboard layout. Typically, Q and A codes are switched between US and FR. On Windows, the keycode stays the same no matter the software layout.

And which is the Asc Code of Command Key, to detect when I’m pressing that key on a textfield Keyup or keydown event?

I answer myself: keyboard.AsyncCommandKey

Use Keyboard.CommandKey. It records the state of the key when the event was fired. A fast typist/slow system can get you out of sync with the state of the keyboard by the time the event is handled. In general, never use Keyboard.Async* in a Keydown event. Always use the non-asynchronous versions of the key state.

1 Like

Ok I got it, I tried to catch it on KeyDown and KeyUp events whiteout success, reading Xojo’s manuals, It recommends to use it on the Action event of a Timer, in order to watch Keyboard activity.

But now I wonder, how can I know if textfield are focused.
By now I’m thinking of have a Boolean Property that changes on GotFocus and LostFocus events of textfield.
And then analyze that property with the timer.

But dunno if there’s another way to do it