A workaround for missing real support for keyboard layout APIs

[Dmitry Timoshkov]

Hello,

Winword uses return value of GetKeyboardLayout as a codepage
to translate ANSI keyboard messages to unicode. But we have
a problem with it: for instance Polish keyboard layout is
identical to the US one, and therefore instead of the Polish
locale id we return the US one, and it's later get used for
MultiByteToWideChar call which leads to wrong results.

This bug arised at the time of introduction of LCID identifiers
attached to every keyboard layout in x11drv.

Since X11 doesn't provide information about locale of the currently
active keyboard layout we can do nothing about this problem.

Changelog:
    Dmitry Timoshkov <dmitry at codeweavers.com>
    A workaround for missing real support for keyboard layout APIs.

--- cvs/hq/wine/dlls/x11drv/keyboard.c	Sat Apr 10 01:50:28 2004
+++ wine/dlls/x11drv/keyboard.c	Wed Apr 14 12:48:18 2004
@@ -1554,7 +1554,18 @@ HKL X11DRV_GetKeyboardLayout(DWORD dwThr
     if (dwThreadid)
         FIXME("couldn't return keyboard layout for thread %04lx\n", dwThreadid);
 
+#if 0
     layout = main_key_tab[kbd_layout].lcid;
+#else
+    /* FIXME:
+     * Winword uses return value of GetKeyboardLayout as a codepage
+     * to translate ANSI keyboard messages to unicode. But we have
+     * a problem with it: for instance Polish keyboard layout is
+     * identical to the US one, and therefore instead of the Polish
+     * locale id we return the US one.
+     */
+    layout = GetUserDefaultLCID();
+#endif
     /* 
      * Microsoft Office expects this value to be something specific
      * for Japanese and Korean Windows with an IME the value is 0xe001