Tk Source Code

View Ticket
Login
2017-11-19
16:55 Ticket [a9bd2ab9] Partial WM_INPUTLANGCHANGE support ignores keyboard layout changes status still Open with 4 other changes artifact: 3462ff29 user: bll
15:08 Ticket [a9bd2ab9]: 3 changes artifact: 979e5db5 user: dkf
15:07 Ticket [a9bd2ab9]: 3 changes artifact: 09ae1756 user: dkf
08:56 Ticket [a9bd2ab9]: 3 changes artifact: b17a5281 user: dkf
2017-11-17
06:58 Ticket [a9bd2ab9]: 3 changes artifact: 01d481e8 user: bll
2017-11-16
15:17 Ticket [a9bd2ab9]: 3 changes artifact: d5bfd8aa user: bll
15:16 Ticket [a9bd2ab9]: 4 changes artifact: 2ea08ddb user: bll
2017-11-15
20:57 Ticket [a9bd2ab9]: 3 changes artifact: 99e4fd18 user: fvogel
08:33 Ticket [a9bd2ab9]: 4 changes artifact: 31b4f7f8 user: oehhar
06:55 Add attachment 1Language_with2keyboardlayouts.png to ticket [a9bd2ab9] artifact: f43da02a user: fvogel
2017-11-14
22:17 Ticket [a9bd2ab9] Partial WM_INPUTLANGCHANGE support ignores keyboard layout changes status still Open with 3 other changes artifact: a6f45d3a user: fvogel
2017-11-13
08:36 Ticket [a9bd2ab9]: 3 changes artifact: 9b6d3b65 user: dkf
2017-11-12
16:52 New ticket [a9bd2ab9]. artifact: 4501619a user: dkf

Ticket UUID: a9bd2ab98bdedf4420f6f663efabf4448f88a614
Title: Partial WM_INPUTLANGCHANGE support ignores keyboard layout changes
Type: Bug Version: 8.*
Submitter: dkf Created on: 2017-11-12 16:52:08
Subsystem: 68. Win Window Operations Assigned To: nobody
Priority: 5 Medium Severity: Important
Status: Open Last Modified: 2017-11-19 16:55:17
Resolution: None Closed By: nobody
    Closed on:
Description:

As reported here, Tk is not correctly responding to keyboard layout changes on Windows. It does respond to language changes, but ignores keyboard changes because it ignores the lParam that describes what the current keyboard layout is. (Programmers in non-English locales often switch keyboard layouts without changing overall languages.)

The correct behaviour is described here, but I don't quite see how that all ties in (I'm no expert in matters relating to the Windows API).

(bll) Edit: adding text from original stackoverflow question:

I have a Tkinter Entry widget and a Hungarian keyboard. When I press the ő button on the keyboard, the Entry widget displays õ. ű becomes û. (I haven't had this problem in other applications since Windows 3.1.)

I do have two language settings on this computer and when I start changing them around, the problem disappears.

User Comments: bll added on 2017-11-19 16:55:17:
The issue described by the OP was that the mapping was initially incorrect.  Switching languages resolved the issue.  There is (or should be) no keyboard layout change as the user is switching languages while using the same keyboard.

dkf added on 2017-11-19 15:07:03:

It seems to me like an issue to do with when the mapping from keycodes to characters is loaded, as if it was set up once and is never altered when the user changes the keyboard layout. Why that matters in this case isn't clear to me, but even just from reading the comments in the Tk sources one can see that there's a lot of different (and bizarre!) ways that these can work; we're not doing something right, even if we usually manage to get away with it. (Also, this is a pretty obscure part of the Windows API; it's not something that most people have experience with debugging and it isn't very well described in the API docs.)

My very rough guess is that we're looking at one of the less common reconfiguration setups, but as an insight it doesn't really help with identifying a fix. Though the MS page on the message in question does say:

You should make any application-specific settings and pass the message to the DefWindowProc function, which passes the message to all first-level child windows.
I notice that we don't do that; perhaps we should?


dkf added on 2017-11-19 08:56:39:

The bug can't be Tkinter only, as the handling of these notifications is not part of the scripted layer. (It's the sort of thing that can only be done right from the C code.) It does require a specific setup to see, however: two very different keyboard layouts but where each is associated with the same (human) language by the OS.

As far as I can see, the issue is that in TkWinChildProc, the handling of WM_INPUTLANGCHANGE (i.e., calling UpdateInputLanguage, which updates input character encoding only, a formally separate thing) doesn't consider a keyboard layout change. It's different on X11, where a change of keyboard layout has its own message. I can see that we don't really do much with keyboard layouts at all (the only keyboard-related API we call is GetKeyboardLayout(0) during TkWinXInit) and I'm not at all surprised that there are problems.


bll added on 2017-11-17 06:58:38:
Since the OP is not updating the ticket, I suppose we could ask on comp.lang.tcl if anyone has a hungarian keyboard (not a US keyboard with a hungarian setting).

bll added on 2017-11-16 15:16:18:
Unable to reproduce:

Tcl/Tk 8.6.7
Windows 7, set as german keyboard switching between languages (EN, DE) (single keyboard, two languages).

It appears from the image provided that the user is on Windows 8 or 10 and he states that the problem _disappears_ when he switches languages.  So I think we need some details on what the initial condition is when it fails.

Does it only fail with a hungarian keyboard?  Does it fail after a reboot?  Or after some other application is run?

It also might be useful to figure out what type of keyboard returns the o-tilde and u-hat characters for those key positions on the hungarian keyboard.

Windows-7: The windows keyboard layout does not match the link provided in the stackoverflow question (because I have a US keyboard?).

fvogel added on 2017-11-15 20:57:58:
I have installed Python specially to anlyze this bug report. I can't reproduce. I think we lack details about what the OP at stackoverflow is doing. If no more details can be provided I'll close as invalid.

oehhar added on 2017-11-15 08:33:36:

I think, the Bug is tkinter only.


fvogel added on 2017-11-14 22:17:39:

Not sure I understand the issue.

In front of me I have a french physical keyboard. Upper row of letters for this keyboard reads "azerty..."

My Windows Vista OS has french language, and only french language.

I have added an English keyboard layout in Vista, for the french language (see attachment "1Language_with2keyboardlayouts.png"). Upper row of letters for this keyboard reads "qwerty..."

Now:

package require Tk
pack [text .t]

Starting typing in that text widget using the upper row of the physical keyboard, I get "azerty...". Correct.

Now I change the keyboard layout, using the so-called language bar, by clicking on the keyboard icon and selecting the other option. Typing again in the widget using the upper row of letters of the pysical keyboard, I now get "qwerty..." (whereas these keys are physically labelled "azerty...". Again correct!

So changing the keyboard layout works for me?

Note that I did not set two different languages, but really two different keyboards used inside a single language. Or did I screw it up?


dkf added on 2017-11-13 08:36:14:

Note that the fix for this issue should be applied to the 8.5 branch, as well as newer branches, as the workaround is quite user-visible for the affected people.


Attachments: