Keyboard Location

[RustyE]

Is there a way to set the location of the keyboard on a web page or even a Windows Forms application?
i.e. I have Textboxes down the page; As the user completes each box, I’d like the On-screen keyboard to move where it is NOT covering the textbox.

[makara]

KeymanWeb can be added to your website with just a few lines of code. The following example sources both the core engine and two keyboard layouts from the Keyman Cloud CDN; the code can be hosted on your own servers just as easily.

https://keyman.com/developer/keymanweb/?_ga=2.226912021.968083457.1618190000-30305726.1574652282

[RustyE]

Thanks Makara,
I have the keyboard loading just fine, but it will come up on top of the textbox/textarea it is filling. My question was how, once the keyboard is displayed, can one move the location without the user using his/her mouse to do it. Thus the question “programmatically move the keyboard” so that it does not obscure the field into which the user is keying information.

[Marc]

By default, the on screen keyboard should move to display below the current text field. You can choose to set its position with setPos. Also, the setRect function lets you control whether or not the end user can move and/or size the on screen keyboard.

[Marc]

Also, if you have manually moved the on screen keyboard, click the pin on the title bar to ‘pin’ it to the active text field.

[RustyE]

Thanks Marc,
For some reason, the keyboard appears in one location (where ever the user puts it or the default location). As I progress through text fields, the keyboard appears as it is supposed to, but it doesn’t move as I progress through the vertically aligned fields. As I tab from one to the next, they disappear behind the keyboard.
How does the automatic or “the on screen keyboard should move to display below the current text field” work or how is it set up to do so? Does the HTML screen need to be tall enough for the keyboard to move down?

UPDATE: When the on-screen keyboard is displayed, there is “pin” icon on the upper right. I tried clicking this and it now follows the text fields.
Is there a way to set the pin setting programmatically so the user doesn’t have to do it?
Thanks again!

[Marc]

The pin is the end user way of doing this.

@jahorton are you able to chime in on this? I’m not aware of a programmatic way to reset the pinning…

(There is a cookie that you can play with which is how Keyman remembers settings from page load to page load, but it’s not the politest way to control Keyman’s settings…)

[joshua_horton]

UPDATE: When the on-screen keyboard is displayed, there is “pin” icon on the upper right. I tried clicking this and it now follows the text fields.
Is there a way to set the pin setting programmatically so the user doesn’t have to do it?
Thanks again!

Wait… so when the OSK is first displayed, that “pin” icon is already showing? That shouldn’t be happening; the “pin” should only appear after you have manually moved the OSK at least once. That said, this setting will persist across page reloads; KMW tries to remember the user’s last preference for the page.

By default, KMW is supposed to follow the text fields automatically. We simply don’t do that if the user has directly relocated the OSK. While we do offer the userLocated function to detect if a user has manually repositioned the OSK, we don’t currently offer a function to undo that setting.

[RustyE]

You are correct. I think the pin only shows if the user moves the keyboard.

Apparently, this was done and the pin did show and this must have prevailed.

Once the pin is re-selected, the keyboard follows the text fields appropriately.

It would, however, be good if there was a programmatic way to manage the pin so initialization and control of location was possible.

Thanks for all your great support!

Rusty

[Marc]

Looking at the source I can see that there is a public function restorePosition() which does exactly what you want – but only if the OSK is currently visible, which seems silly.

I also note that the code in restorePosition() is duplicated in an onclick handler in the controlBar() function. I have no idea why this code is there twice…

The whole state machine for OSK visibility is rather complex – too complex – but certainly I would suggest the following:

1. Tweak restorePosition() to restore the position of the keyboard even if not visible
2. Publish restorePosition() as a public API
3. DRY out that duplicated code (bigger question: why do we have largely duplicate code in the controlBar() and _TitleBarInterior() functions?)

A hacky workaround you could use for now, which would work with 14.0.271 but may break in a future version (as neither _Visible nor restorePosition() are published API names they are subject to change):

keyman.osk._Visible = true;
keyman.osk.restorePosition();

I’ll throw together a quick pull request covering this off for @joshua_horton’s approval – and I think given the minimal scope we can probably back-port to 14.0.

[Marc]

Righto, here’s a PR: fix(web): publish restorePosition() function by mcdurdin · Pull Request #4946 · keymanapp/keyman · GitHub

Once that hits stable-14.0, you’ll be able to do keyman.osk.restorePosition(); safely in all circumstances I hope!