iosLayoutConstraints and layout order

I’m still getting to grips with AutoLayout.

If you have a complex layout, where the edges of controls are dependent on the positioning of other controls, then it seems that you also have to pay attention to the order in which the controls are placed on the layout. This seems logical after you’ve thought about it - but frustrating if you are not aware.

For example - if the edge of control1 is supposed to align with an edge of control2, then control2 needs to be behind control1 in the layout order, so that it is positioned before control1.

If you have them the other way around then you can get spurious (and frustrating) results.

This is complicated further by the fact that some controls - eg textFields, cannot be positioned in in the layout order - so I assume they are at the front then push all the other controls in the correct order to the back.

It would be nice if there was some form of indication of layout order on the layout view in the IDE.

Then there seems to be the further complication of iosLayoutConstraint.Priority - which seems to give you 5 layers (low, auto,manual,high, required) of priority but little in the reference seems to say how these work. For this to work would need to specify consistent priorities for each of the layout constraints for all the controls (at least 4 times the number of controls - yuck!).

Is there a right way of getting consistent layout positioning?

Click on the text field and the move forward move backward buttons at the top of the layout editor should enable
They’re definitely not special in that way

The priorities set which rules can be ignored, or broken, before others
Lower priority rules can be broken before others with higher priorities

Norman - selecting textField1 doesn’t enable the forward/backward buttons when it is inside a containerControl - I’ll submit feedback.

Re the rest of Auto Layout - looks like it needs a lot of study of the Apple documents to understand its intent and which parts Xojo has implemented. One difference I see is that Xcode shows a list of constraints for the view/container - whereas Xojo lists them individually per control - so it takes much longer to examine and check the relationships.

Is there a simple description somewhere showing how Xojo has implemented the priorities?

Seems the forward/backward problem was an issue of my containterControl. Copy/pasting a new version seems to have fixed that.

There seems to be a difference between Xojo and Apple implementations of AutoLayout and Priorities, i.e. determining which constraints can be broken if auto-layout cannot find a solution.
Apple provides a range of integers from 1000 to 0 - allowing clusters of priorities around:
Required = 1000
High - around 750
Medium - around 500
Low - around 250.

Xojo seems to define it differently. No range of integers provided, just what looks like preset values of:
Required, High and Low (presumably 1000, 750 and 250 fixed values).

In addition it provides Auto and Manual - but nothing in the guide says what these are for. Does anyone know that these mean?

Each time I tried to understand better the order in which auto layout is applied to controls, a deep silence was the answer.

Seems that’s the way. I wish it was all a bit better defined - seems whenever I move, add or remove a control, some of the other layout constraints get modified so you have to revisit them all again. For the moment I’ve left all constraints on “Auto” but I have no idea what that really means since the whole layout is Auto.

Forward/Backward also seems somewhat haphazard. Sometimes I have to cut/paste a control to get it to the front again even though the buttons at the top imply it is already at the front.

I deeply hate the editor. I tried several times to suggest it should not double guess the user, but rather behave like the XCode editor, where by default the editor works with left and top, as in any civilized layout editor.

Depending on what the editor thinks your control should be relative to, it happily destroys named constraints, and imposes its own conception of things. In practice, the editor is unusable. One has to use exclusively the constraints, for fear of some random fantasy from the layout editor.

Unfortunately, that layout editor seems to have been all but abandoned since 2015R1, like a lot of things in iOS.

When you have a control positioned where you want and want to make sure its constraints do not get touched lock it in position (the little lock icon in the toolbar or right lick & select “lock position”)

For many layouts its not necessary to worry about constraint priority but for SOME it really is
ie/ if you have a control that MUST occupy a certain amount of space at all times then that width should be required
There are other scenarios where setting the priority helps get the desired layout

And yes there are only a handful of defined priorities as opposed to Apples scheme (although apple does define a handful of presets as well)

Thanks Norman, so what are Auto and Manual?

low = 1

auto could be labelled “medium”
auto is 500

manual should probably be labelled “normal”
its 501

high is 750

required 1000

and reviewing this stuff I think I spotted a bug
will have to test & see

That helps.

Perhaps low should be 250 and manual should allow direct entry - then has some consistency with Apple.

Just one bug? :wink:

manual wasn’t intended to be directly enterable
That COULD be submitted as a FR though

and yeah I did spot one specific bug
one that would have direct bearing on what you’re trying to do now and why things behave as they do

Precisely, a layout editor is commonly used to tweak ever so slightly positions with a graphic representation. Having to fear the editor messes up names constraints, for instance, is counter productive.

It would be much better if the layout editor did not transform for instance a Top myControl_Top constraint in Bottom, or downright destroy it. Named constraints are supposed to be important enough for the user not to be treated so lightly IMHO.

feedback://showreport?report_id=47880

This morning again an example of stupid auto layout ruining things in the layout editor. I have this named constraint PiOSTextBox1_Top which of course applies to the top. I move ever so slightly the control for it to look better, and my Top constraint becomes Bottom, while it keeps its name. This is utterly ridiculous.

Between not being able to assign the parent and this kind of vagaries, Xojo iOS is a true nightmare to use.

To better illustrate why Xojo iOS layout editor is beyond inadequate, here is XCode layout editor in action. I can move controls with the usual references X and Y, no fuss with constraints that have their own life and f*ck up my work :
XCodeLayoutEditor.mov

[quote=327928:@James Pitchford]That helps.

Perhaps low should be 250 and manual should allow direct entry - then has some consistency with Apple.

Just one bug? ;)[/quote]
Yes actually - one
Just happens to be kind of crucial to making things work as expected at run time

Design time is a different kettle of fish and I actually filed a feature request to make Xojo’s system work differently
feedback://showreport?report_id=43194
Basically so you could drag & drop controls onto a layout and not require ANY constraints at design time
And when you hit RUN it would minimally constrain things (set top left height & width constraints for everything)
And then you could add extra constraints IF that behaviour is not to your liking to get the behaviour you want
This way the layout editor would simply change offsets as you move controls rather than wholesale rewriting rules which is what it does now
I think people would find that less antagonizing

Hey Norman, this is great ! Exactly what I have hoped all along. Thank you.

I have added it to the #1 of my top cases. I hope many others will do the same.

At this point you should position a control. Lock it. Position the next one. Lock it.
Their constraints wont get modified.

That is how I work, but is mighty unnatural for someone with a graphic eye.

Another annoyance I discovered today, is that I need controls to rest on a canvas, but NOT to be children. Since in iOS it is not possible to set parent to nil, as we do in desktop, I spend a good time making sure they were not.

I saved the project, and sure enough, a couple canvases had become again children. So before building the project, I have to tediously take the controls off the container control, and back in with the constraints.

This is terribly uncomfortable. I have already filed a FR asking to make parent writable so long ago …

Should I file a bug report about the changing parent ? Is it only worth it ?