Strategy for supporting international keyboards in Flash/Flex

Question

I have an Flash/Flex application that is showing weird behavior when used in conjunction with international keyboards. For example, I have extended TextInput in this app to allow for special behavior when the user presses the hyphen ('-') key. When this happens I want the text of the input to be padded with zeros in addition to the typed text out to six digits. So if the user types in "5-" they should see in the field "000005-".

On a French keyboard, the user is required to have CapsLock enabled to type numbers, and the 6 and hyphen characters share a key. So when the French user types in just "6" with CapsLock enabled, what they see in the field is "000006-". It appears however that both the 6 and - characters are being sent to the field. The 6 causes the numeral to appear, and the - causes the special behavior described above.

I've heard that listing for a TextEvent instead of a KeyEvent might help in this case. I have not tried that yet, but I intend to shortly. However, there are several other issues related to differences between international keyboards. So I am wondering if there are any general strategies for ensuring correct support for the various international keyboards.

Any thoughts or ideas? FYI, this app currently uses Flex SDK 3.5 and Flash Player 10.

Thanks in advance.

Answer 1

Have you ever tried keyboardEvent.charCode with String.fromCharcode?

private function onKeyDown(e:KeyboardEvent):void {
    var c:String = String.fromCharCode(e.charCode);
    switch (c) {
    case '-': ....
    }
}

Manipulating texts in event handler of TextEvent.TEXT_INPUT will be ok, but I don't recommend this approach because the time when TextEvent.TEXT_INPUT dispatched has a little difference in FP10 and FP10.1 (for 10.1 a new API for IME deal with this event)

For more details, I did a limited implementation :

Handling TextField-related Events - wonderfl build flash online

Answer 2

FYI, the correct answer was to listen for the TextEvent rather than a KeyboardEvent. I suppose that makes sense since by the time the actual text is available it has presumably been translated correctly from the keyCode and charCode values.