Keyboard taller with Xojo apps..

So sent my first iOS app to my device, had a little fun due to the simulator being a bit more forgiving but I felt the keyboard was taller than other apps on my iphone 6. Yup, they’re about a row higher. Seems more spacing between rows.

Just curious…

Not saying you’re mistaken… but I find that difficult to understand, unless XOJO is bypassing the iOS standard keyboard in lieu of their own “custom” one…
Other than the type of keyboard (ASCII, numbers, phonepad etc), the color (dark or light), and the display of certain chek-ahead word suggestions (which can be turned off), the keyboards should be 100% identical regardless if XOJO, ObjC, Swift or any other language for that matter.

Would it be possible that Xojo apps show the predictive zone on top while other apps hide it ?

Thats a better description than my “chek-ahead word suggestion” :slight_smile:

Hum. I looked at terminology before posting :wink:

Then the following question would be “how can I display the keyboard without the predictive zone ?”.

Since that is not available in Xojo iOS, it calls for declares (as usual. Sigh)…

They SHOULD be exposed properties of the TextField/TextArea… but I’m guessing XOJO opted to not do that…

  self.keyboardType           = UIKeyboardType.ASCIICapable
        self.keyboardAppearance     = UIKeyboardAppearance.Dark
        self.autocorrectionType     = UITextAutocorrectionType.No
        self.autocapitalizationType = UITextAutocapitalizationType.Sentences
        self.spellCheckingType      = UITextSpellCheckingType.No
        self.returnKeyType          = UIReturnKeyType.Next

Xojo decided to protect users against shooting themselves in the foot, and did not expose anything considered dangerous.

As a result, either one codes with the equivalent of Fisher Price roller skates, or one uses potentially highly explosive declares.

A bit like shooting real ammo with a toy gun…

LOL… a more apt description I have never seen! Bravo

No, See the images, one is the Apple Mail, one is my prototype. iPhone 6, OS 9.02. (Xojo 2015 r4). I’ve only added one LaunchScreen for now as opposed to all flavors, wonder if that upsets it. Other controls seem ok. I’m pulling a night shift at work so won’t get any other time to fiddle until end of the weekend. (Images scaled down 50%). Huh, even the top status bar jumps up a bit! :frowning:

Note : those are NOT the same keyboards (one has Siri Mic)
Not saying that is the REASON, just that there is a difference already accounted for.
and notice the KEYS are also bigger (note the bottom row)

and I’ve seen references to the fact there is a 3finger zoom that will change keyboard size, so there must be some internal parameters that can control all that

Good catch. I use the email keyboard for that textfield, I use the general one for the access code one, that does show the Siri button, same size though.

It’s not the keyboard. Your app isn’t using the full resolution of the selected iPhone.

the danger of using the old-fashion message of requiring launch images to control the resolution… a practice Apple abandoned over two iOS versions ago

Actually, we did what we could accomplish for version 1, knowing that getting an app to run on the device was the most important feature. If there isn’t a feature request for adding keyboard options to a text field, I’d do that.

So it looks like I need to fully load the Launch Images then! I’ll try that later this weekend.

Until then, iOSLib features full keyboard support for textfields:

So, bottom line, don’t skimp on the Launch Images. Once I loaded them all, keyboard was correct size.

So, just not affecting black bars top & bottom but a whole lot more :slight_smile:

[quote=241664:@Richard Gorbutt]So, bottom line, don’t skimp on the Launch Images. Once I loaded them all, keyboard was correct size.

So, just not affecting black bars top & bottom but a whole lot more :)[/quote]
This doesn’t surprise me. It’s probably because on smaller screens it’s harder to hit the keys properly.

[quote=241596:@Ulrich Bogun]Until then, iOSLib features full keyboard support for textfields:[/quote]

Ulrich I’m trying to use an iOSLibTextField on my login screen because I like the ability to specify a UITextAutoCapitalizationType of None. However I can’t seem to set the UIKeyboardType to EmailAddress. I’m doing this in the control’s Open event:

me.keyboardtype = AppleTextField.UIKeyboardType.EmailAddress

But I don’t get the EmailAddress keyboard displayed (the one with the “@” symbol). So for now I have gone back to the standard Xojo iOSTextField.

Thanks, Jason! I checked the code and found that I had skipped NamePhonePad in the enumeration. That’s why everything from EMail address was +1 …
I was wondering why there were no inspector properties for these types anyway. Have changed that, but currently I would have to refine a few demos to up the changes. If you’d like, I can send you a working copy privately. Or just insert NamePhonePad into the enumeration at the place of EMailAdress and shift everything from there +1 accordingly.

Sorry & thanks again!