iosTextField and iosTextArea both bring up keyboards when touched - but it seems the keyboard type is the wrong way around.
TextField brings up a keyboard with a “Done” button - whereas for single line text, a “Return” or “Enter” button would be more appropriate.
TextArea brings up a keyboard with “Return”, but has no “Done” button. So once you are in the text area, you can’t get out.
Am I missing something obvious?
I think that’s just how iOS works, not a Xojo bug.
Single lines you can’t put in a new line, so the key says “Done” instead of “Return”
Text-areas (multiple lines) allows for new lines, so the key says “Return” and not “Done”
To get out of a text field or text area, tap anywhere else on the screen.
Tim, thanks.
What you describe is what happens in the Notes app - but they have added a “Done” button themselves at the top of the screen.
However, when I put just those two controls on a view and touch the textArea, everything else disappears, including the done button in the toolbar, there’s nowhere else on the screen that I can touch.
It looks a bit better when running it on a device rather than the simulator - still no “Done” button on the top, but have access to a tab bar at the bottom - though it is rather messy.
James take a look at the iOSLibTextField, part of iOSLib. I have a Login view with textfields for username and password and, using iOSLibTextFields, I am able to set the returnKeyType to AppleTextField.UIReturnKeyType.Next_ for the username field, which allows the user to move to the password field, and then on the password field I set the returnKeyType to AppleTextField.UIReturnKeyType.Go. There is also a type of AppleTextField.UIReturnKeyType.Done if you’d like to use a Done button.
I agree with your comments about the way Xojo scrolls the entire view up when the keyboard appears and you lose the NavigationBar. I reported this a couple of years ago but it’s still that way. It’s very frustrating in the real world ;-). My solution to that problem is to never make a TextArea extend past the middle of the screen so there is enough space for the keyboard to appear without causing an entire view to scroll up. I also use iOSTables for all my data entry forms which helps solve the view scrolling problem.
I reported that as a bug early on, but this is standard behavior for iOS and Android. If you think about it, without it, a TextField or TextArea that would be under the keyboard would be unusable.
Once again, the very limited screen real estate has to be managed very carefully.
It’s not the scrolling of the view that I think might be a bug Michel. It’s the scrolling of the navigation bar off the top of the screen. I think the screen contents should scroll underneath the navigation bar when the keyboard appears. Instead, the navigation bar scrolls right off the view along with the rest of the view contents. I don’t see this in other apps. Maybe I’m wrong about it but I don’t think Xojo has definitively answered this one way or the other.
For example, choose a contact in your Apple Contacts app. Then tap the Edit button in the navigation bar. The data is presented in what appears to be a customised UITableView (i.e. equivalent to a Xojo iOSTable). Now tap on a field towards the bottom of the view. For me, that’s an email address. The keyboard appears and the table scrolls up so you can see the field/cell that you’re editing. But the navigation bar stays put. The table scrolls beneath it. You can see the same thing in the Apple Notes app which doesn’t seem to be using a UITableView. This is pretty stock-standard stuff but Xojo has never behaved in this way.
As I said, happy – very happy – to be proved wrong. 
I see what you mean.
You mention a bug report. It would greatly help to attach a screen movie showing how Apple apps behave versus Xojo’s. I feel I am not the only one who overlooked the fact that the navigation bar should stay in place.
Here’s a little movie that demonstrates the issue
I’ve been getting around this problem in my shipping app by using some code that @jean-paul devulder wrote for his iOSTable replacement. But Xojo really needs to look into this. I’m going to escalate this with Xojo outside of the forum as well, in the hope of a faster solution.
Once again, I really regret Xojo never saw the interest of buying dtPlugins for iOS, which are now all but gone from the market.
Without Jean-Paul Devulder’s job, Xojo iOS remains extremely toyish.
That makes me extremely worried about their forthcoming Android product. If it is yet another Fisher Price contraption, with limitations obviously dictated by contempt for users, I am afraid Xojo will have missed the boat for good with all mobile products.
i don’t mean to distract from the issue that Jason highlighted but I agree with Michel. I wish Xojo Inc were forced to make and maintain a serious iOS Xojo app, with minimal declares. And I don’t mean a full-screen canvas control which they ship as Xojo Draw or something on the App Store.
If they were forced to eat their own dog food when it comes to iOS, they would realize how challenging it is to make something that isn’t Hello World.
I agree that this does seem to be the consequence of Xojo’s lack of dog-fooding with a real-world iOS app. I would prefer that they get iOS right - and it isn’t too far off being pretty good IMHO - before adding yet another target in Android.
They will tell you they eat their dog food once a year by making a gadgety app for XDC, which BTW would not work without declares. In reality, they simply don’t realize that they are pushing people away fast. I am not the only one, for sure, planning to change development tool to, at last, get a decent support for iOS.
As for Android, they better get their manure together, late to the party as they are, in front of established and very complete products such as B4A. Sure, their IDE will be cute, but what is that worth when the product is incomplete and botched ?
When, on top of it, the smallest requests for events and properties commonplace in Desktop Xojo have been purely and simply ignored, it shows the utter contempt for Xojo iOS users. If the same happens for Android, Xojo can kiss good bye all hope to ever be a decent player in the mobile market.
I’ve just confirmed an additional bug. When the keyboard appears and the whole view scrolls up, if you then tap on a row, the row number reported in the Table_Action event is wrong. Instead of being the row that you tapped on, it’s the row that would have been in that location had the entire view not scrolled upwards.
Xojo really needs to stop the view from scrolling up in this situation for the iOSTable to be usable for data entry (which is the way that UITableView is used in many apps, particularly line-of-business apps).
I’m going to write up a Feedback case now.
How many bug reports did you file for iOS, and how many were fixed ? How many feature request for exposing small properties or events in iOS, and how many have ever been granted ?
I rest my case. They are beyond redemption as far as I am concerned.
Has anyone found a viable workaround for this yet?
This is killing me today.
+1
@Chris Halford
https://github.com/UBogun/Xojo-AppleLib
Should have what you need. Take a look at the first comment by @Jason Tait in this thread and he explains what is needed.