How to change TextEditor localization

Windows
1

Ok. I’m russian. When I input text in my native language I see incorrect symbols (like Western Europe’s symbols). Please give advise.

2

I’ve heard about this before but couldn’t find the problem. What OS are you using?

3

Hi, Jules. Thanks for replying. So, maybe you’re right. I use English Windows XP Professional SP2. And try to write Russian word.
I need check it. Maybe on Russian Windows XP all is fine.

4

ok, I’ll take another look and see what I can come up with for the next release…

5

Hi,

For the same problem, I was suggested to look juce_win32_Windowing.cpp.

In “void doKeyChar (const WPARAM key)” there is:

// if alt + ctrl are both down, this seems to indicate “alt gr”, so we have
// to temporarily disable these modifiers to make sure the characters typed
// will be treated as normal keystrokes.

But problemmatic Turkish characters are generated via AltGr+…
So Juce blocks AltGr and only use the key’s original Ascii value.
I believe that is the problem. This key strokes should flow through the
OS which will generates translated (ie.Turkish) char event.

I treid to solve it, but couldn’t succeeded. Sorry.

–
Regards,
Hakki Dogusan

6

The problem is alive for Windows XP with Russian MUI. Reading from the file is fine. Symbols look correct.

7

ok, here’s a suggestion. I’ve not tried this, but see if these changes help.

Replace this bit at the start of juce_win32_Windowing.cpp:

[code]UNICODE_FUNCTION (SetWindowTextW, BOOL, (HWND, LPCWSTR))
UNICODE_FUNCTION (DragQueryFileW, UINT, (HDROP, UINT, LPWSTR, UINT))
UNICODE_FUNCTION (MapVirtualKeyW, UINT, (UINT, UINT))

void juce_initialiseUnicodeWindowFunctions()
{
static bool initialised = false;

if (! initialised)
{
    initialised = true;

    HMODULE h = LoadLibraryA ("user32.dll");
    UNICODE_FUNCTION_LOAD (SetWindowTextW)
    UNICODE_FUNCTION_LOAD (MapVirtualKeyW)

    h = LoadLibraryA ("shell32.dll");
    UNICODE_FUNCTION_LOAD (DragQueryFileW)
}

}[/code]

and this bit later on. in doKeyDown():

[code] default:
handleKeyUpOrDown();

            if ((currentModifiers & (ModifierKeys::ctrlModifier | ModifierKeys::altModifier)) != 0)
            {
                UINT keyChar = wMapVirtualKeyW != 0 ? wMapVirtualKeyW (key, 2)
                                                    : MapVirtualKey (key, 2);

                handleKeyPress ((int) LOWORD (keyChar));
            }

            break;[/code]

It might be because it was using an ascii version of MapVirtualKey that it was failing.

8

Hi,

Sorry to report but it didn’t help.

(btw, I tried this in XP. Not Mac :))

–
Regards,
Hakki Dogusan

9

Some investigation. Maybe it helps.
I found JUCE_STRINGS_ARE_UNICODE.
Where I could define it? I think problem that Visual Studio doesn’t see it.
I see in keyPressed() keyCode is less than 255. I’m not sure but in UTF-32 Cyrillic codes are great than 400.
Hm, but this keyKode comes from windowProc().

10

no, no - JUCE_STRINGS_ARE_UNICODE is irrelevent.

It’s something to do with the window itself not getting unicode chars. One other idea is to try replacing CreateWindowEx with CreateWindowExW and RegisterClassEx with RegisterClassExW, so that the window gets registered as unicode when it’s created. (you’ll have to tweak a couple of bits of code to make that compile).

11

Yes, you was right.
I changed functions calling and made some modification in TextEditor -key.getKeyCode() < 0xff. And it works. :smiley:
Russian symols are correctly showing.

12

[quote=“jacque”]Yes, you was right.
I changed functions calling and made some modification in TextEditor -key.getKeyCode() < 0xff. And it works. :smiley:
Russian symols are correctly showing.[/quote]

That’s great. You say you made some other modifications - what were those? Did you change anything in the windows message callback?

13

Nothing in callback. Just casting T("") to LPCWSTR (but it’s problem only for VC 2005) in CreateWindowExW. And in TextEditor in function keyPressed() remove condition key.getKeyCode() < 0xff.
That’s all.

14

ok… I’ve a nasty feeling that the keyCode < 0xff check was there for a reason, but will have a look.