Autolayout names

I’ve been converting an Objective-C app to Xojo simply to learn the Xojo iOS stuff. Autolayout is problematic at times. Especially since I need to move controls in code occasionally.

Would this be useful: The IDE fills in the names for us? Say I have a label (named “label1”) and I need to position its top position. The IDE could fill in the name as label1_top or some such thing. This would ensure there are not duplicate names (I seem to have created some). And, since there would be a standard naming convention, it would be much simpler to use the constraints in code if needed. I assume that having a constraint name doesn’t cost too much.

Although this coule be a good idal, what should the Xojo IDE do when you add two “top” constraints ?
I think that layout constraints shouldn’t have a name by default and it is the responsibility of the developer to name them. But maybe this is only because I’ve been used to this behavior for the last year.
And to avoid duplicate names I usually name the constraints using the name of the control as a prefix : label1_top for example.

and since you can enable disable constraints its entirely possible to have duplicates like top - one enable the other not enabled

maybe that is how you handle different constraints for different layouts (which is possible)

One thing I would like above all, is to have a way to inhibit the “guessing” feature of the layout editor. After patiently setting all constraints, if one moves all too gently a control, suddenly the IDE decides to dump the constraints set, and switch to new ones instead, like replacing top by baseline or bottom, and left by right.

Long minutes of work in the not so easy to use constraints editor down the drain …

In effect, the layout editor seems to fight the inspector more than helping.

<https://xojo.com/issue/44162>

Absolutely I agree with Michel. Having the IDE change things after one has carefully set things up is most unproductive.

Thanks for the info about names.

Named constraints should not be deleted that way.

Lock the controls and this wont happen
Thats exactly what locking is for

That is what I use, but does it not defeat the purpose of having a full fledged graphic layout editor not to be able to use it to visually move controls ?

In essence, what is terribly frustrating is that the layout editor can be used only to drag the control onto the view, then it starts fighting the settings in the Constraints editor.

One of the minimum I would like, is that the IDE does not dump constraints which have been named. One could assume that a name constraint is important enough not to be discarded.

Essentially, what I would love is a mode in which the IDE would simply modify the existing constraints without adding or discarding any.

I know you have probably poured a huge amount of work in that “intelligent” layout editor, but I am sorry to say the end result is that using the mouse becomes impossible.

With that line of reasoning we should remove locking on the Desktop & Web layouts as well

You don’t understand. My problem is not with locking (which I use), it is with the ability to graphically position controls. That is the whole point of having a graphical layout editor.

In Desktop, or Web, if I see a control slightly off, I can move it at any time with the mouse until it looks good to my eye. The IDE will simply update the constraints left and top to the new position.

In iOS, because the IDE will infer all sorts of relationships with other controls and parent, and jump from constraint to constraint, I will simply ruin the constraints I created in the Inspector.

I just wish the iDE let me use the constraints I decided to use instead of inventing its own.

Let us say I named and decided to use Left and Top, it does not feel right that the IDE, instead of simply updating these constraints to the new control position like Desktop or Web would have done, decides to dump them and replace them by bottom and right.

It is sad you take it as an attack, when all I am trying to explain is how difficult it makes things, as compared to Desktop and Web.

Desktop & Web do NOT use “constraints” in any way shape of form.
They ONLY have top & left to be able to position any control - so they are blindingly simple.
When you move a control the IDE adjusts the top & left - because that is the ONLY possible thing they can do regardless of where the layout guides are positioned.

iOS is entirely different and so it uses the blue guides to try & infer what you intended as positioning.
Often that why your constraints get rewritten to use the new guides as the basis for the position.

We’re aware of this.
The IDE’s handling of things was modelled on Xcode 4’s which, if you go look at Xcode 8, has changed in an enormous way.
I would expect that the IDE will also evolve in its handling of layout constraints etc

I just looked at XCode 8, it seems indeed very different. From what I see, constraints are created at build time.

As it stands, Xojo iOS may be very smart and all that, but in practice, I end up having to decide myself the constraints I want to use, and to set everything in the constraints editor, because the graphical layout editor precisely infers things I may not want. So I am back at the code level instead of Wysiwyg.

From what I regularly read in the forum, it seems I am not the only one.

Creating constraints in the constraint editor is a long way from hundreds or thousands of lines of code in the Open event.
Been there done that and having to create or edit a few constraints per controls is much simpler

We have plans on how to improve things - but right this second it is what it is

I am not asking for an immediate solution :stuck_out_tongue: