Opened 14 years ago
Closed 14 years ago
#24 closed defect (fixed)
Input of umlauts (å, ä , ö) sometimes does not work
Reported by: | dmik | Owned by: | |
---|---|---|---|
Priority: | blocker | Milestone: | |
Component: | odin | Version: | |
Severity: | Keywords: | ||
Cc: |
Description
A user reports (http://svn.netlabs.org/java/ticket/41) that he cannot enter umlauts with the recent Odin release under some circumstances.
This is clearly a regression of r21529.
Change History (7)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
Tracking it down reveals that both problems showed up because I changed the USER32 initialization code (InitPM()) so that it switches the main thread to the Windows ANSI codepage (cp1252 for Latin countries).
In case of Flash, this means that the Firefox main thread gets unexpectedly switched from the OS/2 codepage to the Windows ANSI codepage (cp850->cp1252 for Latin countries) once the Flash plugin gets loaded and drags USER32.DLL in. This completely confuses Firefox which still assumes it gets input in cp850. Hence, the invalid character translation. I will avoid switching the main thread's codepage in such a case; the rest of my code in r21529 expects this situation and will still work correctly.
In case of Window titles, it seems that the SetWindowText() implementation in Odin unconditionally assumes that the window thread is in the OS/2 codepage and therefore when it gets actual input in the Windows ANSI codepage it performs a wrong conversion. This is also proven by the fact that rolling back r21529 only fixes windows created on the main thread; windows of other threads (e.g. *all* Java windows) still remain broken (and I actually remember the very same problem with Innotek Java). The proper fix here is keep r21259 and fix SetWindowText() instead.
comment:3 by , 14 years ago
Small addition. All Java windows are broken because Java creates all GUI windows on additional threads and because Odin has been always switching all additional threads to the Windows ANSI codepage even before r21529.
comment:4 by , 14 years ago
Issue 1 is fixed in r21543. I had to disable the main thread's code page switch since there is no good way to detect if it's us who initializes it (i.e. a normal Windows/Odin executable) or it's a foreign non-Odin thread (e.g. Firefox). After all, the code will still perform the correct conversion of WM_CHAR messages from the OS/2 to ANSI code page when needed. This additional footprint for the main thread is not that critical (it's the user input).
comment:5 by , 14 years ago
Issue 2 is fixed in r21544.
The new user32.dll with both issues fixed is available as ftp://ftp.dmik.org/tmp/slivan/user32.zip. Please check and report the results.
comment:6 by , 14 years ago
ok i testet all 3 cases. java, odin app and flash. i did not see any wrong characters.
There are actually two problems that reappeared after r21529 (i.e. Odin release 2010-12-30):