On the iPad device, when you position a TextField below the center near the bottom of the screen and try to access the Textfield, the keyboard will block the TextField when the device is positioned in Landscape. It does not move the TextField up. It simply blocks it.
It does the same behavior in the simulator in one position of landscape, but if rotate it the other way it works correctly. . It works fine on the device and simulator when it is positioned in Portrait. The problem seems to be limited to the Landscape position on the device itself.
This is happening on both an iPad 4 and on an iPad Pro. I was wondering if there is a solution to this problem? Any suggestions would be greatly appreciated.
In checking this out further, the keyboard also blocks the TextField if you position the iPad in Portrait but with the home button on top.
The thread below shows this problem. I was wondering if there ever was a work around created.
Yes. You have to either catch the WillShowKeyboard event of UIWindow (https://github.com/UBogun/Xojo-iosLib/wiki/AppleWindow) or register a NotificationCenter for the UIKeyboardWillShowNotification (https://developer.apple.com/library/ios/documentation/UIKit/Reference/UITextField_Class/index.html#//apple_ref/occ/cl/UITextField).
For the first solution: That will be in the next version of iOSLib, it’s not yet included in the repository.
The topic came up before. He can also look at TextField.IsFirstResponder (in XojoiOSWrapper, which means the keyboard is displayed) and move the controls with the constraints.
Hi Michel and Ulrich,
Thank you for responding to my thread. I would have thought this would be built into the Xojo iOS right from the start. It seems it would be a critical feature to be able to access TextFields no matter where you are in the view.
Michel do you have any example app where the XojoiOSWrapper helps scroll the view so you can access all the TextFields no matter where they are in the view?
I also don’t know how to catch the WillShowKeyboard event that Ulrich suggests.
I do appreciate your help.
depends a bit on what iOS extension(s) you use. In iOSLib (a different NotificationCenter implementation should work very similar) Id define a KeyboardShown event in the iOSView youre using and a method that takes a Notification (in iOSLib AppleNotification) and raises this event.
Then from the constructor or open event of the iOSview, cast
Dim block as new iOSBlock (address of EventRaiseMethod)
dim NotificationObject as AppleObject = AppleNotificationCenter.addObserverForName "UIKeyboardWillShowNotification", NIL, AppleOperationQueue.MainQueue, block.Handle
The NIL as second parameter will make the NotificationCenter catch every Keyboardwillshownotification and raise the event.
You can of course add more events via Notifications for the other keyboard notifications in a similar way:
When you examine the userdict (a NSDictionary) of the received notification, you get information about the keyboard and can determine at which place to scroll your textfield/view so it’s visible when the keyboard is displayed.
If you want to deregister, call AppleNotificationCenter.RemoveObserver (notificationObject).
I guess Michels solution is easier to implement, but I am not sure if you can use it like an event or would rather have to install a timer-based watcher on the property.
I do not have any example app, but here is the principle :
The isFirstResponder method tells you if the keyboard has been pulled for a particular TextField or TextArea. So what you do is use a timer to monitor your textfields that can potentially be hidden :
if TextField1.isFirstResponder then
// Move the TextField on top of the view by changing the named constraints
// Move back the TextField where it was at design time