UPDATE: The demo project attached has been updated due to a couple of “glitches”. One remaining known issue is that the “Config” page doesn’t move to its original position if changing orientation when the keyboard is already showing. I’ll revisit the article when I’ve come up with a solution.
I’m sure almost everyone who develops an app for mobile devices has, or will, come across this problem: an edit control is low enough on the screen to be covered by the virtual keyboard when the user taps on the edit control. When I first started using iOS, I figured that iOS was smart enough to shift the control automatically. Of course, iOS isn’t that smart, so developers need to determine exactly what is shifted.
For example, you might have a form with a toolbar at the top, and the rest of the form occupied with a tabcontrol. The following is an animation of what can happen when you don’t shift the control(s): (click each image to see the animation)
One issue is that you might want the toolbar to remain visible, but the parent of the control (or a parent of that) should be shifted up far enough so that the control is completely clear of the virtual keyboard. The following animations demonstrate this. First for an edit control:
..and for a memo control:
Note from this animation that the caret in the memo appears just above the virtual keyboard, rather than below the bottom of the memo control.
The link following contains a demo that can be used with any Firemonkey mobile project, that takes the drudgery out of having to work out how to move the control(s).