Inferring absence of physical keyboard in Win 10 'convertible' device
David V Glasgow
dvglasgow at gmail.com
Fri Mar 23 06:18:47 EDT 2018
I apologise in advance for the ugliness of my attempt at a solution to the above.
Just a brief gratuitous update on strangeness associated with Inferring absence of physical keyboard in Win 10. The Win 10 tablet itself knows the keyboard has been detached, because the cursor disappears (although LC continues to detect the location of the invisible cursor, because tooltips are sometimes triggered). However it seems there is no flag accessible to developers. Various online recipes appear in different languages, but none appear to be accepted as foolproof.
The simple kludge I came up with works fairly well. Counting mousemoves generated on a setup screen allows me to reliably determine whether the input is mouse or touch (the latter presuming keyboard absent). However, the cut off isn’t as clear as I thought it might be. This is because mousemoves appear to be generated when the pointer doesn’t actually move
Opening the card containing the mousemove counter always generates 3 mousemove messages without the screen being touched in any way. Any tap generates 4 mousemoves. So open card + popup + select option + radio button + go button = 3+4+4+4+4= 18 minimum. I could reduce that a bit by zeroing the mousemove count after the popup selection.
Luckily it seems impossible to do the same using a mouse-pointer with fewer than 70 mousemoves, so if the platform is Win and mousemoves <60 I present a “It looks like you are using this device as a tablet, is that right?” dialog. A ‘Yes’ enables the use of on screen keyboard and numeric keypad on the main card. Also, someone using the screen as a tablet but with a mouse attached would slip through the net. However, a false positive here is not a great inconvenience.
False negatives remain a possibility, though. Obviously a rather touchy, clumsy, strokey tablet user could generate another 42 mousemove events, and thus transition to the main card with no means of entering data.
The built in on-screen keyboard is also pretty horrible. Often obscuring the important parts of the screen, and apparently arbitrarily invoked or not invoked. In short, Microsoft’s ‘continuum’ seems to be more ambitious and complicated than Apple's ‘continuity’, and rather difficult to manage as a user and developer.
More information about the Use-livecode