Chinese Keyboard Entry in Listbox Keydown

I’m testing some input entry for Simplified Chinese in the Listbox Keydown event. Problem is I don’t have a Chinese keyboard. I set the keyboard to Pinyin-Simplified and I can see you can get character substitution with prefix entry if you are in an edit field but I am capturing characters in the listbox keydown event and drawing them into a canvas so I can’t see a way to test that.

Would my app catch the characters from a Chinese keyboard and what ascii range would that be
If I want to accept letters and numbers and Chinese characters as input entry what would I add to the following which I thought might be on track but can’t test?

if (asc(uppercase(key)) > 64 and asc(uppercase(key)) < 91) or (Asc(key) > 48 and asc(key) <58) or (key >= &h4E00 And key <= &h9FFF) Then

CJK text entry generates several low level events which won’t be presented to the keydown event so your idea won’t work properly.

At minimum you would need the TextInputCanvas plugin to capture the events and build on top of that.


Due to Han Unification, it may not be possible to tell that some characters are Chinese as they have the same Unicode value as Japanese or Korean characters.

@Martin_Fitzgibbons Is the problem to do with activation of edit mode for the listbox or are you just attempting to filter what is allowed to be entered. If it is about activation of edit mode I have a solution of the Mac, which must have an equivalent on windows.

The problem for edit mode activation is that users can enter half of a character, which then gets fed into your keydown event. You see this and then activate the edit mode and they continue with their key sequence. You then run into the problem that the link between the initial keystroke and the later ones is broken, meaning they don’t get the character they were expecting. If that describes your problem the solution lies in reposting the keyboard event after you activate the edit mode. I can provide code for this if it would help.

Hi Ian,

It’s for a crossword player program which currently works fine for all languages I have tested so far. You click on the clue in the listbox which activates my position in the canvas to start drawing the character now captured in the listbox keydown.

I just don’t know what will happen when a Chinese keyboard character is pressed. It would be pretty ugly and not in line with the rest of the languages but I could pop up a dialog for them to enter the answer in a text field then grab the answer and draw it in the position. At the moment the characters are drawn in the canvas as they type

The trouble with Chinese input is pin-yin keyboard input. You will get anything up to 3 keydown events for a single character entry. You’ll find very similar issue with entering accented characters using a US / UK keyboard. The likes of the “Option-e e” sequence for entering “é”, the “Option-e” causes a keydown event. How you deal with that “temporary partial character” I suspect is your issue.

Chinese keyboards do not have every Chinese character on them, they would be pretty large if they did :slight_smile: So even in a real Chinese keyboard you are going to get this same stepwise keydown entry.

1 Like

The Textfield input entry works just not as nice as placing a character at a time into the puzzle

The latest beta has a “CharacterCount“ property for strings. If you were to check that in KeyDown you would be able to tell if the event had provided a complete new character.


That could work, in the meantime I used the workaround which isn’t too bad.

I find it confusing, these days, as to whether or not we’re allowed to speak about beta stuff in the forum. It used we were not, but anyone can see fixed issues in the feedback system. Has this rule been removed?

Everything is visible in feedback and being pro he has beta access. I didn’t intend to discuss it further.

It wasn’t against you that I made my reply :wink:.
But now, everyone knows about a next-beta feature, thus my wondering.

1 Like