I need some guidance for setting up views. It’s driving me crazy.
Have a view with 9 labels, 1 button, 28 fields and 1 image. I just added a label and several of the fields enlarged them self from the left side of the layout to five or six inches off the right side of the layout; and several field moved (disappeared) off the layout.
There got be to a better way to do this. Any advice would be appreciated.
and people wonder why I HATE Autolayout 
“five or six INCHES”… thats a major distance for an i Device…
and 39 elements on the screen? wow
[quote=254262:@Jim Smith]I need some guidance for setting up views. It’s driving me crazy.
Have a view with 9 labels, 1 button, 28 fields and 1 image. I just added a label and several of the fields enlarged them self from the left side of the layout to five or six inches off the right side of the layout; and several field moved (disappeared) off the layout.
There got be to a better way to do this. Any advice would be appreciated.[/quote]
With such a number of controls, the way I would do it is first, to draw the desired layout on paper. Or even do it in a desktop program with a 640 x 960 window. So that gives you the values relative to the window.
If you want a static display, like in Desktop, set for each control the values of Top and Left relative to Parent Top and Parent Left, assign width and Height. That is probably the easiest in a first step.
Auto Layout is not irrelevant, though, at the condition to prepare it carefully. Let us say you have four columns of fields. You can very well make the first left 3% of parent.width, then each field width 21% of parent width, then the distance between fields 3% again.
Such a setting will show fields evenly spaced in portrait as well as landscape, 640 or 960 wide.
The trick is indeed to work on the map first, then determine the relationship between controls, then spend enough time in the Auto Layout constraints for each control.
I do not hate Auto Layout, but have to admit that it is kind of difficult to jump from Desktop to iOS because the editor assumes too much for its own good.
Also, I have to admit I cannot quite imagine a tiny phone screen with so many controls on it. Heck, even a tablet. Are you sure you cannot break that into several views ?
Thanks Michel.
It’s working!!
Solution: Container Control. Move the control to the left of the image to a container control. Then droped container control on to the view (and made changes to use the cc). Much, much easier to work with the control when there are only 10, than a bunch.
Make sure that the virtual keyboard does not occultate the lower fields if they must be edited. Although the 6 ones there may be the result of calculus.
All the iPads but the Pro ar 1024 x 768 points so it should not be a problem not to use full Auto Layout. But you may want to address the iPad Pro which is 1366 x 1024.
This app will NOT update, only display. However I did check it out for data entry and it ok.
For the sake of the eyes of your users: can you tone down the yellow? It hurts my eyes to look at your screenshot.
You may want to use a subclass of Canvas to display data, instead of a regular textfield, to avoid user try to edit it.
[quote=254263:@Dave S]and people wonder why I HATE Autolayout 
[/quote]
This has nothing to do with autolayout
And everything to do with how the IDE lays out controls and creates the constraints for autolayout
They are two quite different things
Why not dynamically change the Enabled property of an editable control? That usually works with my projects.
A disabled control becomes greyish. Too bad we don’t have Read-Only textfields in iOS. But then again, too bad we don’t even have a normal compliment of controls…
You are absolutely right… And what you said before: a canvas control would be the only solution. What about a container control, with all the gesture events, with a label-control on it. I am not really able to test that now though. But is a label not selectable?
A label has no background color, so it would be necessary to lay it over a rectangle to have a background. But then it would not look exactly like a native TextField. The only way to get a rounded rectangle is to use a Canvas. So back to the solution I suggested.
My concern is that a regular iOS user is trained to know that he can modify the content of a TextField by pressing on it. As a result, the keyboard pops up and takes a significant part of the screen. Having a field that does not pops up the keyboard would simplify things.
Can’t that be done through declares?
And it would be useful to add a setting to keyboard-type. Now it has stuff like, numeric, email, etc… if an option like “None” would be golden!
And indeed a checkbox “read only” would make the editfield complete for sure.
It is possible to set editable or not in declares
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UITextField_Class/#//apple_ref/occ/instp/UITextField/allowsEditingTextAttributes
I believe Jason King’s UIKit offers a way to select the keyboard type.
But at this point, I have to admit I am beyond annoyed to have to use declares at every turn for properties that should have been part of the control design from the start go.
For the life of me, I cannot conceive that Xojo could have released a TextField without the most elementary properties familiar in Desktop and Web. I know many times during the beta, more than one year ago (November 2014) Xojo explained they did not want the user to shoot himself in the foot, so they removed any potential danger. As a result, their product is barely more than a toy. I even wonder if that is not a clever white lie to cover a very real lack of completion. How would in this instance a BackgroundColor and ReadOnly properties have harmed the user ?
For over a year, none of the numerous feature requests about iOS has been addressed, except Container Control. I wonder even if there is anybody there looking at them. I know that will scratch some nerves, but is there at least someone in charge of iOS ? Permit me to strongly doubt it.
I love Xojo, but at this point, their iOS product is barely able to do prototypes IMO. Anything more serious either requires a lot of tears and a painful collection of patches and tricks, not to mention more time than reasonable.
Heck, if the donkey won’t move, one better get a horse : XCode and Swift are not that difficult to learn. At least, there, a TextField has all the properties one would expect in a Xojo product, and more.
Edit : I seems that unlike in OS X, Canvas consumes the pointerDown (mouseDown) event, so it effectively prevents editing the TextField.
@Jim Smith : Place a canvas over all the fields you want to keep read only and that will prevent the user from displaying the keyboard. Set Canvas1.Left = TextField1.Left (whatever the Textfield on the upper left corner is named) and Canvas1.Top = TextField1.Top, then make its width Canvas1.Right = Parent.Right.
Call me picky, but would it not be nicer to be able to decide if the Canvas consumes the event or not, like in OS X ? Oh, but I did not realize that there is no way to return True. Maybe that too would harm :-/
Thanks Michel. Have a Container Control that is used on 4 views, had forgot to disable data entry on the six fields. Putting the canvas over the fields took care to eliminate key board entry.
off.[quote=256042:@Michel Bujardet]A disabled control becomes greyish.[/quote]
I don’t see any difference in the display of on or off Enabled.
Speaking of grayish display, I have lots if difficulty seeing the outline of text fields in the IDE, But that a subject for another timek.
[quote=256117:@Jim Smith]I don’t see any difference in the display of on or off Enabled.
[/quote]
It is subtle, but the white background becomes slightly grey.
If you place two textfields on top of one another and disable one, you will notice it.