Hi I’m reporting bugs and looking for possible solutions when using non-english characters in the TextEditor component. The non-english characters I’m using are Korean.
Select All does not work. I’m on a mac and when using Cmd+A Korea characters do not get selected.
After typing in Korean characters, when I click with a mouse on the TextEditor and type again, the character I last typed before clicking on the TextEditor gets written, followed by the new character I type.
Has anyone experienced these issues? If so, has anyone found a workaround? Thank you very much.
I’d like to look into this, but my knowledge in this area is extremely limited, so I will need additional pointers.
Do you find that the TextEditor works well otherwise when using Korean input?
E.g. I added a “2-Set Korean” input source, and when typing into the TextEditor I’m seeing completely different glyphs than in other programs (TextEdit or Sublime Text are showing the same glyphs).
What I’m finding is that Cmd + A doesn’t work when using the 2-Set Korean input source, but it does work with some other input sources even if there are previously typed Korean characters in the TextEditor.
Thank you for your response attila. The TextEditor seems to work well with Korean input other than the issues I have mentioned.
The glyphs that you’re seeing might have to do with your current font in the Juce program not supporting Korean. I had to set my program’s font to one that supports both English and Korean for the characters to appear correctly (I used Nanum Gothic).
I also just tried with Japanese input and although Cmd+A seems to work fine, it has the same issue of previously typed characters appearing again when writing something, clicking on the text editor, then writing again.
Making the shortcuts work with any language layout seems to be a bit tricky so at this point I can only share a workaround.
On my system the keycode for the ‘a’ key when using “2-Set Korean” is 12609. So to hardcode that value, you could override
bool keyPressed (const KeyPress& key) in the
Component that contains your
TextEditor and also call
setWantsKeyboardFocus (true); in its constructor. So the function would look like
bool keyPressed (const KeyPress& key) override
if (key == KeyPress (12609, ModifierKeys::commandModifier, 0))
This is of course far from ideal, but it could be a band aid until a better solution.
I’m going to take a look at the previously typed characters problem as well.
Thank you! The bandaid fix will work for now. Please let me know when you see any progress on the other issue!
The command+A problem is the same as the one previously reported here: Keyboard shortcuts problem (there’s also some more discussion on the issue there)
Thanks for the link.
I was faced myself with the “I don’t know how others do this”, because whenever a layout produces a letter bound to a shortcut on a different key, the key bindings will follow the letter to that key. So shortcuts will move around with different layouts to different keys.
But the strategy of “checking if the letter is part of ASCII, and if not, execute the shortcut based on the hardware key code” sounds reasonable. Not certain that it won’t break someone’s fringe use case, but it’s worth exploring.
I made some changes that aim to eliminate the 2nd problem with the reappearing characters. I’m not a user of multi-keystroke layouts myself, so while this looks okay to me, I would very much appreciate your input on this change.
Applying this patch against
develop fixes the problem as I understand it. Can you try and see if it behaves as you would expect?
texteditor_fix.patch (2.5 KB)
I hope to address the shortcut problems soon too.
Thanks so much for tending to this issue! Gives me faith in Juce that you’re paying attention to issues like this that probably don’t even affect the majority of devs using juce.
I’ll check out the patch and get back to you!
Commits 87061fb7 and 2b3abd3c are now out on develop, which should fix the shortcut problem and the IME composing problem on MacOS.