Keyboard taller with Xojo apps..

Richard_Gorbutt · January 15, 2016, 11:33pm

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…

DaveS · January 16, 2016, 12:18am

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.

Michel_Bujardet · January 16, 2016, 12:55am

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

DaveS · January 16, 2016, 12:58am

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

Michel_Bujardet · January 16, 2016, 1:02am

Hum. I looked at terminology before posting

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)…

DaveS · January 16, 2016, 1:06am

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

Michel_Bujardet · January 16, 2016, 1:11am

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…

DaveS · January 16, 2016, 1:26am

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

Richard_Gorbutt · January 16, 2016, 1:58am

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!

DaveS · January 16, 2016, 2:20am

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

Richard_Gorbutt · January 16, 2016, 3:24am

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.

Thomas_White · January 16, 2016, 9:23am

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

DaveS · January 16, 2016, 1:09pm

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

Greg_O_Lone · January 16, 2016, 2:09pm

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.

Richard_Gorbutt · January 16, 2016, 6:59pm

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

Ulrich_Bogun · January 17, 2016, 12:28am

Until then, iOSLib features full keyboard support for textfields:

Richard_Gorbutt · January 17, 2016, 4:07pm

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

Greg_O_Lone · January 17, 2016, 4:09pm

[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.

JasonTait · January 25, 2016, 5:11am

[quote=241596:@Ulrich Bogun]Until then, iOSLib features full keyboard support for textfields:
https://github.com/UBogun/Xojo-iosLib/wiki/iOSLibTextField[/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.

Ulrich_Bogun · January 25, 2016, 2:53pm

Thanks, Jason! I checked the code and found that I had skipped NamePhonePad in the enumeration. Thats 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 youd 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!