Problem from users' perspective: Windows users of my 
Tk-based app who  
have Czech keyboard (CS) set as *default* couldn't
input 
Czech characters into input entries until they switch 
from CS->EN->CS using the Alt+Shift  
Windows shortcut (until they do, messy characters 
appear on the screen instead). After the switching to 
EN and back everything worked fine (it also  works 
fine if EN keyboard layout is the default and the 
user switches to CZ after the app starts).    
Going through the win32 sources, I identified the 
problem win/tkWinX.c. The best patch I could manage 
is attached.    
Here's what happens: tkWinX tracks keyboard layout  
switches by listening to the  Win32 
WM_INPUTLANGCHANGE event in order to keep its info 
about the current  input encoding up-to-date. The 
problem is, that it doesn't initialize its  internal 
variables according to the initial layout at 
aplication startup (probably 
assuming its always EN).   
The patch adds a short code to TkWinXInit that uses 
GetKeyboardLayout winapi call to determine current 
keyboard layout, then translates this information 
into charset code which it uses to update the Tk's 
variables in the exact same way as WM_INPUTLANGCHANGE 
event does.   
Please have a look at the patch and consider applying  
it. The diff is taken against CVS head.   
Logged In: YES
user_id=72656
This just missed the 8.4.12 release ... in any case, there
is no patch attached???
Logged In: YES
user_id=430096
Hm, I probably forgot to check the checkbox beside "Attach
a File" when creating the report, sorry about that. Hope
this time the patch gets there.
PATCH
Logged In: YES
user_id=72656
The patch seemed odd - proper ini in TkWinXInit is now set as:
if (GetLocaleInfo(LANGIDFROMLCID(GetKeyboardLayout(0)),
LOCALE_IDEFAULTANSICODEPAGE | LOCALE_RETURN_NUMBER,
(LPTSTR) &lpCP, sizeof(lpCP)/sizeof(TCHAR))
&& TranslateCharsetInfo((DWORD *)lpCP, &lpCs,
TCI_SRCCODEPAGE)) {
UpdateInputLanguage(lpCs.ciCharset);
}
added to 8.4.13 and 8.5 head as soon as SF cvs returns.