A user has installed a keyboard and set it to be the default Windows (10) keyboard. The Keyman icon is also visible and both icons indicate that the keyboard is active. However, when the user tries to type, the keyboard is not on. If the user uses the Keyman shortcut key twice (turning off and back on) then the keyboard works.
Or the user can go to the Windows keyboard icon and select US and then the keyboard and it works.
I’ve installed the same keyboard on my computer and it works as expected as the default keyboard.
The user says that something happened about a week ago that seemed to cause this behavior, but has no idea what it is. I’ve installed the 14 beta on her computer, but that didn’t help. Any ideas?
I cannot reproduce this on my side either. I am running Keyman 14.0.229-beta on Windows 10 Pro 20H2. Can you DM me the keyboard so I can give it another try.
I’ve asked the user in question to submit a debug log reproducing the problem but so far have not heard back. If you would like to assist them, see the instructions at https://help.keyman.com/knowledge-base/76
Marc,
Here is the file that she created. The process that was followed was:
Open Keyman
Set keyboard as default Windows Keyboard
Open Word
Type 'o which should produce an accented o. What comes out is 'o
Turn the keyboard off and on again at the Windows keyboard selection
Type 'o and it produces the accented o correctly.
Thanks for submitting this. I am going to be unavailable for the next two weeks but hope to review this after I return.
I’m sorry, this disappeared in my inbox and I never got back to it. I have now had a look at the debug log and it is inconclusive. The log suggests that another non-Keyman text service is being activated shortly after Keyman starts, but we don’t have enough detail in the log to determine what it is.
I don’t think a newer version of Keyman will address the problem, but it is possible – we’ve made a lot of fixes to the core engine since build 14.0.233 so it might be worth trying.
If that doesn’t help, perhaps we should setup a remote support session to investigate further.
Thanks Marc - I’m checking with the translator.
Marc,
Diane is still having the same issue and would love to try and set up a remote session with someone on your team. I’ve copied her here so that you can set up a session.
Marc,
As Phil wrote, I have done the update and still have the same problem. It would be great to set up a remote session to have you or someone on your team look at it.
I am in California. Phil told me you are in Cambodia. I just checked the time difference. 8am for you is 6pm for me. 9am for you is 7pm for me. I can be on in the evening without any problem. I could do this today (Tuesday for you) or tomorrow (Wednesday for you) or the next day (Thursday for you). Could you let me know what works for you.
Blessings,
Diane
Hi Phil and Diane,
I unfortunately won’t be available to check this for a couple of weeks – I am fully booked this week and then have two weeks of vacation. @Makara can assist you in the meantime and if you together still cannot come to a resolution, then I can assist when I return from vacation.
Marc
Please check your DM from me for the invitation to the remote session.
@Phillip_Leckrone Could you send me the keyboard project of QuechuaUnicode2?
It looks like the language selected for the keyboard is “en-US” instead of “qu-PE” as the keyboard gets activated.
This might have been the cause of the issue as Windows thinks en-US is in use instead of the expected qu-PE.
@diane_hintz_sil_org We were on the right right on the remote session, but you might have to restart the machine for the new setting on the language preference to work. Can you try and do so.
Letś go to Zoom again and test it again on you machine. On my machine, 100% of the time the keyboard works on any apps.
Hi Makara, Could we do another remote session at the same time (9am your time) tomorrow. Please send me a Zoom link. I restarted my machine, but it did not help. Now I have two additional problems with Keyman. You can see it tomorrow.
OK. I think the existing Zoom link sent to you on DM earlier is reusable. See you tomorrow.
@Marc The issue persists even when having the right language tag set to “qu-PE”. Despite the fact that the keyboard works for me, the keyboard keeps misbehaving. ;a output ;a instead of ä in Microsoft Office Word 365 (including even Notepad) on Diane’s machine.
What I do that works for me but not for her
- Install the keyboard quechua_unicode2.1.kmp (1.6 KB)
- Go to the Language Preferences and move Quechua keyboard to the top of list of “Preferred Language” so the keyboard will be used for any apps.
- Go to “Keyboard” and choose “Quechua Unicode” to Override for default input method.
Doing these proves to work on my Machine. Open LibreOffice, Notepad or Chrome to type away in Quechua without any issue nor having to switch the keyboard on and off.
As you have mentioned earlier, there might be something getting in the way before Keyman gets to work in per particular machine. I would suggest that you look into it when time allows.
Okay, we’ll have to schedule a time when I return from holidays (in a couple of weeks)
This issue can be tracked here: bug(windows): the keyboard is not working even though activated · Issue #4856 · keymanapp/keyman · GitHub.
I am back from leave and able to setup a remote session now. Please send me a private message and we can set this up.
Hi Marc,
How about what is for you Friday at 9am? You are in the same time zone as Makara, right? I am in California on Pacific time. So that will be Thursday at 7pm for me.
Diane
Continuing this time planning on email. 