![]() ![]() TGetMoveControlEvent = procedure(Sender: TObject FocusedControl: TControl var MoveControl: TControl) of object įVKBounds: TRectF // modified by Patrickįunction GetFocusedControlOffset(KeyboardRect: TRectF): Single // modified By Patrick #VIRTUALKEYBOARD RETURNKEYTYPE FIREMONKEY UPDATE#The final code here (tested with Delphi XE5 Update 2, IOS 7, iPad Mini):įMX.Forms, FMX.Controls, System.Types, FMX.Types ![]() I have used too a class TFMXUtil posted in this QC for the solution: I have been working with your code, and with suggestions that people post here to correct the problems of your ControlMover class, and I get a definitive code for the class that works in all situations. #VIRTUALKEYBOARD RETURNKEYTYPE FIREMONKEY HOW TO#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). 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 following animations demonstrate this. 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. Of course, iOS isn’t that smart, so developers need to determine exactly what is shifted.įor 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) When I first started using iOS, I figured that iOS was smart enough to shift the control automatically. 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. I’ll revisit the article when I’ve come up with a solution. 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. UPDATE: The demo project attached has been updated due to a couple of “glitches”. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |