I have a view with multiple textfields added dynamically.
When I type into a textfield at the bottom, CVV Code e.g., the View scrolls down but the Top Navigation bar is moving up and is not visible anymore.
It seems the keyboard is pushing the navigation bar upwards.
The navigation bar should stick to the top, as it does with other iOS apps.
The problem exists in the simulator and on a real device.
Tested with 2014r3.2 and, before posting this, with 2015r1
I know the iOSView is not scrollable yet, but here the navigation bar scrolls out of sight.
Not bug. You have placed the CVV field too low, so if the view did not scroll, it would be under the keyboard and inaccessible. So to let you enter your data, the view pushed up until you are finished with the keyboard. When the keyboard goes away, your view comes back in place.
I understand what you mean …
But the view is not scrollable and we have to use views, don’t we ?
That makes a big part of the view unusable …
I feel more and more frustrated having to rely on so many people providing help and tools for free (wrapper, ioslib, declaremaker, gluekit, …) and still being unable to develop basic apps…
I’ll check your “scroller” solution and see if I can solve my issues.
[quote=166348:@Olivier Colard]I understand what you mean …
But the view is not scrollable and we have to use views, don’t we ?
That makes a big part of the view unusable …
I feel more and more frustrated having to rely on so many people providing help and tools for free (wrapper, ioslib, declaremaker, gluekit, …) and still being unable to develop basic apps…
I’ll check your “scroller” solution and see if I can solve my issues…[/quote]
In this particular instance, all stems from the small space available when the keyboard is displayed. I ran into the same issue in my first app and even asked about the same question.
Smart phone apps are all about dealing with limited screen real estate.
From what I see of your screen, you could use placeholders in the textfields instead of labels to indicate what goes where. That would save room to get the fields closer to each other and gain room vertically.
Likewise, the date field and CVV could be on the same line. Actually, looking at your screen shots, it may suffice.
If you manage well the some 300 x 250 screen area available for your field, you won’t have the push up phenomenon.
You should have read what I wrote during the early beta days. I have been developing with RB/Xojo for two decades, and yet, it was quite a learning curve. Take it one step at a time. You will get there
Using placeholders was my first option but these are displayed when the fields are empty only. Once the user fills them the placeholder is replaced by data and it could be ambiguous.
All textfields are placed dynamically and each field label, keyboard type, length, validation, sequence on screen is defined in a database.
Users can create new “forms” add as many fields as they want on each form.
Of course I can spare some place but this would affect the views readability.
My frustration is not to struggle to get somewhere, it’s more the way Xojo sells a very limited tool and rely on “free” manpower to make it somewhat better.
I didn’t see the 2015r1 release note but I’m afraid we’ll have to wait years to have something… but this is another story… Just hope they prove I’m wrong.
If I may, what you bumped into with these fields is the inherent limits of the portable devices in terms of screen size. Surely, scrollable views would do wonders for your particular app, but they are not here yet. Although dtPlugins for iOS will provide that hopefully soon.
I have been quite hard on Xojo when I saw their iOS product for the first time. But on the other hand, for having dabbled with XCode and Swift, I still appreciate Xojo for its usual ease of use and simplicity, versus the inherent complexity and paradox of choice incarnate of XCode.
In many aspects, the story of RealBasic is pretty much the same. Look at Xojo today : Windows Functionality Suite, MacOSLIb, MBS plugins, dtPlugins, BK classes, piDog classes, and so on all started pretty much the same way as what you refer to. We all support each other to obtain results Xoio cannot deliver yet. Nothing wrong about that.
Now, I would really love to have in Xojo all the bells and whistles iDevices currently enjoy with XCode. But in all honesty, I am already glad they finally got their thing together and at long last produced an iOS version. Then it was barely on the market, and Apple came up with this new 64 bit requirement. Sort of a softer replay of the Quicktime issue at the end of 2013. Passed the holidays, the Xojo team had to work quite a bit to produce 2015R1 which should be available in a matter of days, and complies with Apple diktat.
My hope is now that this is done, they will indeed add more to that indubitably very coarse product, and make it more in tune with Desktop and Web in terms of controls, and finally able to exploit iOS devices particular hardware.
I have sympathy with the OP’s situation. If you take a look at the first screen shot posted, there’s a whole heap of empty space at the bottom of the view and yet there’s still not enough room for the keyboard to appear without affecting the Navigation Bar. So what is the OP to do? Make his fields stop halfway down the view? I think that would be poor UX design and that the only practical solution is just to allow the Navigation Bar to scroll out of view while the lower fields are edited.
I have found the lack of scrolling views is a very big issue for making business apps. Xojo has to address this sooner rather than later.
However we look at this issue, the room taken by the keyboard remains exorbitant. De facto, a 5 inches screen becomes a 3 inches screen akin to an antiquated pre-iPhone handset.
People at Apple must have thought long and hard about what to do precisely with the kind of UI design the OP has.
The view push up seems the most reasonable.
Scrolling would not resolve things entirely. Contrary to a keyboard device, there is no Tab key that would move the focus from one field to another. So scrolling would have to be done manually. Even with techniques such as the scroller I posted, it remains a whole lot more cumbersome than to let the system manage it automatically.
That said, I really look forward to be able to scroll views, would that be with dtPlugins or a native feature. Although 2015R1 won’t have it, so if it comes, it will not be before next quarter.
Using a scrollview and adding the fields, these scrolls as aspected.
But if you have a keyboard open then the behavior is the save as showed here (with the navigation bar that scrolls up)
Maybe there is a partial implementation in the Xojo view.
For the next field (tab) equivalent, on iOS you should implement a delegate action in order to have the return button behave as a Next button. But, again, iosTextField has a delegate so you can’t design your own without breaking the Xojo implementation and we don’t know if this delegate has this event… but could at least raise it so we can use it to set the next responder.
[quote=166593:@Antonio Rinaldi]There is something strange…
Using a scrollview and adding the fields, these scrolls as aspected.
But if you have a keyboard open then the behavior is the save as showed here (with the navigation bar that scrolls up)
Maybe there is a partial implementation in the Xojo view.
For the next field (tab) equivalent, on iOS you should implement a delegate action in order to have the return button behave as a Next button. But, again, iosTextField has a delegate so you can’t design your own without breaking the Xojo implementation and we don’t know if this delegate has this event… but could at least raise it so we can use it to set the next responder.[/quote]
No Return in the iPhone keyboard
Maybe use Done and move the focus when the field stops being first responder ?
