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
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.
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 So even in a real Chinese keyboard you are going to get this same stepwise keydown entry.
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.
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?
So even in a real Chinese keyboard you are going to get this same stepwise keydown entry.
.