A system I’ve been working on utilizes a lot of operator input to process parts through the system.
We have added content to put the focus into text boxes in the views when the operator takes an action of one sort or another (submitting parts, changing lots, etc.). This system is utilized with both PCs and tablets (with the Perspective App). The latter is having some issues. For instance, if the operator goes back to the lot entry view, the lot Id text box is focused. This causes the On Screen Keyboard to open. When this occurs, it looks like the OSK pushes the view upward and off the top of the tablet’s screen. Kind of like a docked view that does a push as opposed to a cover.
Are there any settings that can be changed to define how the on screen keyboard behaves in the Perspective App?
And I did it again! Forgot to post the version.
I’m on version 8.1.10.
Hi Mike,
Unfortunately no there isn’t any settings to adjust how the On Screen Keyboard behaves in the Perspective Android App. We currently rely on some of the android defaults for handling the OSK’s behavior which is designed to keep the input visible. Does this push of the content cause the focused input to be pushed off the screen?
Thanks,
Jonathan C
Yes, unfortunately it does push the text box off screen.
Thanks for the info. I’ll have to see if there is a way to alter the behavior of the OSK from the tablet side.
I wouldn’t expect it to push the Input component off the screen. Let me look into this a little bit
I’ve got a little more information now.
When using the menu tree to navigate to a page, the OSK does NOT push the page up and content at the top off screen. It seems to be when an operator pressing button on one embedded view that then changes display prop values for the embedded views in the page and the focus to the the text box on the now visible view.
Not so quick explanation:
There are at least 2 views that makeup the pages. When the menu is used to navigate, the chosen page is displayed and the view “value_entry_with_tablet” is displayed normally.
When all the necessary information is entered (Lot, Part Number, etc.) the above view is hidden and the “part_assignment” view is displayed.
When Switch Lot /Complete buttons are pressed, the display status of these two views is toggled (“value_entry_with_tablet” is displayed and “part_assignment” is hidden).
A message handler is used to set focus on the text box of the view “value_entry_with_tablet”. This is when the odd behavior happens. No navigation is actually happening at this point, just views’ position.display param values changing.
If the user drags down on the page at this point, the page scrolls to reveal the content at the top of the page as shown in the first image above.
