what IOS version are you running?
Also what version of Go?
FYI- I have over 400 iPads out there and have not had this happen.. (hopefully it won't)
Thanks for the reply JP. I have been unable to replicate the issue myself, but one of the users who reported the issue is on Go:13.0.4 and iOS 7.1.2 as am I. I'm on an iPad 2 as are a majority of our field personnel.
I've tried breaking things every way i can imagine wrt keyboard/accessibility settings without any luck.
ok... I have all iPad 4's mainly... Some 3's... I wonder if it is an iPad 2 bug...???
Are there any triggers on the regarding fields or layouts? Did you test with user permissions?
Thanks for the reply. There are triggers in my solution, of course (very few keystroke triggers though), but the problem has appeared on different layouts and so I have not been able to find anything common between them besides the file and app. I can't imagine permissions to be the cause either, largely because all of our ~70 users are on the same permission set and they all use the file almost daily and we've only seen the issue a few+ times and only recently.
Maybe if you elaborate on how those things could cause what I'm describing (albeit secondhand) I might be able to more precisely confirm or deny my doubt that those things are causing the issue.
If it is not a FMGo bug (possibly related to our hardware, iOS) then my biggest guess would be along the lines of a trigger.. or some kind of script being 'stuck' while running.. but again the lack of common context makes that a difficult theory to track.
Do you have any script triggers of any kind specified for the field where the keyboard is disappearing.
And when the keyboard disappears, is the cursor still in the layout or not?
If something, either script or user interaction puts the focus in another object on the layout, that keyboard would likely disappear. Just tapping Next or Previous might cause this with some layout designs.
Thanks for the reply Phil. No, there are no triggers on the field where the keyboard is disappearing, because it is happening all over the place. I have some triggers, naturally, in my solution, but I use them sparingly and I have not been able to link the reports i get back from users with fields that have them. I don't know whether the cursor displays when it happens because I have been unable to reproduce the issue myself and I hadn't thought to ask that question, I will do so if/when I get the opportunity again. I ruled out the possibility that they are tapping the screen or that they're hitting the hide-keyboard button. I've played with keyboard settings, including un-docking & splitting, everything you can imagine, without luck recreating the issue.
My team and I have ruled out these, more trivial possibilities with some confidence. It never hurts to circle back and double check, and so I will do that, but I am really here wondering if anyone else has seen this. If it were bad programming, maybe someone else whose made the same mistake that yielded matching symptoms.. the sporadic nature of the issue, for us, paired with the fact that we've been dealing with the iPad files becoming damaged during use, and the fact that replacing the file resolved the issue when even restarting the iPad did not (if it were triggers, this should fix), makes me wonder whether some kind of corruption can cause this. On the other hand, when I had the field personnel send their file in, I am still unable to replicate the problem..
edited for spelling
Not related to your keyboard issue, but we too have had numerous amounts of database corruption in Go 13... It was not this bad in Go 12..
My guess is it has to do with the user hitting the home button instead of exiting the database.. causing a force close, and corruption... I can't narrow it down and it is very sporadic.
Solved: We have multiple deployed files. One of the other files has an on script timer that runs on a particular layout. That is well managed within that file, but if a user leaves that file open in the background and opens the file about which I was posting, then the OnTimer function still fires and, although I'm not sure whether the script attached to it is actually running, it is at least dismissing the keyboard. BTW, it equally affects bluetooth keyboards..
I would guess that the script is running and causing focus to leave the field and that is why both keyboard are effected.
My guess is it has to do with the user hitting the home button instead of exiting the database.. causing a force close, and corruption
Hitting the home button does not close any FM GO files let alone a force close... I'd be more suspicious of a forced disconnect due to loss of wireless signal than accidentally hitting the home button as the source of possible file corruption...