Is there any “detailed” documentation on how XOJO implements and how the developer should interact with AutoLayout that goes beyond the 3/4 of a page that I found in “Getting Started”???
and while we are at it… AutoLayout for FONTSIZE? A bigger or smaller button for example will need a bigger or smaller font
Under the hood it IS Apple’s autolayout engine
We just write constraints for it and you have access to the constraints in effect vis the iosLayoutConstraint class
I realize that … which is why I phrased the question as I did.
Apples documentation sucks as you well know… and about Autolayout seems to be their worst.
And I don’t really think not including a little bit more is out of line.
at least definitions as to what each parameter is (and its possible values)
and I would think that XOJO would be more “helpful”, as the more one has to rely on documentation from another company to support their use of your product, the more likely they are to see potentials in that other companys products that exceed the product that they are attempting to use.
Plus (side question) does it make sense to be able to associate LEFT or RIGHT with TOPLAYOUTGUIDE or BOTTOMLAYOUTGUIDE (as an example)
I tried to use a declare to setAdjustsFontSizeToFitWidth: on a button but it crashes. But I believe it is possible to do it in Xojo code via a change in iOSFont according to the button size in the view Resized event.
While that is a possible solution, it assumes you want the largest font the “fits”, which may not be the case
What do you mean ? I can change the font size according to the size, limit the expansion, and make sure it does not grow larger than the control, eventually by using g.TextBlockSize.
Like http://xojo.helpdocsonline.com/ioslayoutconstraint ?
Or something more ?
[quote=158082:@Dave S]
Plus (side question) does it make sense to be able to associate LEFT or RIGHT with TOPLAYOUTGUIDE or BOTTOMLAYOUTGUIDE (as an example)[/quote]
Possibly not 
I know there are a few areas in the IDE where it will allows things that seems nonsensical like this
It’s on my to do list to deal with some of these issues
The state of Apple’s docs on this doesn’t help my understanding either.
I’m sure our docs on auto-layout will continue to get more information as I spend more time with auto-layout.
And Norman is scheduled to present an AutoLayout session at XDC 2015.
[quote=158090:@Norman Palardy]I know there are a few areas in the IDE where it will allows things that seems nonsensical like this
It’s on my to do list to deal with some of these issues[/quote]
In particular, it seems whenever you create a new constraint, it is automatically relative to the left of what it is relative to. For top and bottom, it is strange 
Is it valid to have multple “rules” defined for the same constraint?
Left=Parent.Left+20
Left=Parent.Left+193
the IDE allows you to do this… but I assume it choose only one
No
How would you define minimum & maximum size with only one constraint ?
It should not permit two equals constraints for the same item1 & attribute - thats on my to do list already
But this should be legal
Left>=Parent.Left+20
Left<=Parent.Left+193
so there are definitely some edit checks that still need to be in place
<https://xojo.com/issue/36303>
<https://xojo.com/issue/36237>
[quote=158101:@Norman Palardy]No
How would you define minimum & maximum size with only one constraint ?
It should not permit two equals constraints for the same item1 & attribute - thats on my to do list already
But this should be legal
Left>=Parent.Left+20
Left<=Parent.Left+193
[/quote]
This is part of what is confusing… given you example… how do those two rules resolve?
Assume that Parent left is ZERO
Left>=20 (or? and?) Left<=193
I thought the purpose was to determine what LEFT was for a given “Parent.Left”, becuase if you set those rules by editting the rules, then drag the control… the rules change to be the equivalent of EQUAL
Left>=100
Left<=100
or in you example does it do the equiv of this ???
for x=0 to device_width
if x>=Parent.Left+20 and x<=Parent.Left+193 then
Left=x
exit for
end if
next iConstraints are basically ALWAYS ANDed together.
How they resolve at runtime is by making sure left fits within those constraints.
That left is >= 20 and <= 193 when all rules are solved.
Editing in the IDE tries to determine what you intended to change - and its not always determining that correctly.
When / if you find it alters rules in a fashion that is counter to what you’d expect (like this) a bug report is in order as it probably SHOULD just alter those rules constant by whatever amount you moved the control left or right and not change them into equivalence rules.
[quote=158107:@Norman Palardy]Constraints are basically ALWAYS ANDed together.
How they resolve at runtime is by making sure left fits within those constraints.
That left is >= 20 and <= 193 when all rules are solved.
Editing in the IDE tries to determine what you intended to change - and its not always determining that correctly.
When / if you find it alters rules in a fashion that is counter to what you’d expect (like this) a bug report is in order as it probably SHOULD just alter those rules constant by whatever amount you moved the control left or right and not change them into equivalence rules.[/quote]
Ok… that still doesn’t help me understand what LEFT would end up being… Seeing as how “left” is an equation with 173 answers
Left will be a value between 20 and 193.
Really depends on everything else around it.
At design time you set up relationships - not fixed positions.
Try this example http://great-white-software.com/miscellaneous/autolayout%20by%20example.zip
The only code its to paint squares different colors
Everything else about positioning is set via constraints
And all I can tell you for sure at design time is exactly what the constraints say
spacers are 10 pixels
canvas1 and canvas2 will be the same width
spacers will be between the canvases
but at runtime depending on what device you run this for & what orientation the various left for any item IS only expressible as a relationship - an equation
BUT at runtime it DOES resolve to some position - and you can query that from the control itself.
and if there is nothing around it? and what if there is?
I’ll be honest here… I cannot relate XOJO implementation to XCODE implementation (not that either is better or worse than the other, both are confusing beyond belief).
In Xcode it looks like you can’t do anything but set a hardcode width/height, but Xojo allows it to be flexible.
Right now I have two controls in Xcode with tons of colored lines and numbers, and noboby explains what it means, all the docs, just say “Do this and this, and See! it works!”, but nothing to explain WHY, or exactly what to do to get what you want
Sorry, this is very frustrating
In Xcode you can set flexible widths
Its just not as obvious how
If there’s nothing to the left, say another control that can resize, then its very likely to be 20 from its parent which could be the containing view or control this one is parented on.
If there is something to its left that might force it to move further right then it will be something up to 193.
The whole point is that its NOT fixed positions.
Its relative positions - so when you rotate a device things stay positioned relative to each other
Or when you run on a phone vs an ipad where available space is radically different things are still spaced relatively correctly
Or on a 11" Macbook air vs a 5K iMac
so if one control exists… having MIN and MAX is a waste… if will most likely revert to MIN anyways
If its the ONLY control on the view then it would not be useful to specify left as something between a min & max since there’s no reason for its left to change.
More likely it’d be parent.left + some std offset or some fixed offset
If there’s nothing to its left that will cause its left to change then its also probably not useful either.
Min/max is useful in other situations where you want to have it flexible within some defined range.
But, the solver COULD find a solution that is left = 156 and it would be perfectly valid given the constraints.
Thats possible however unlikely.
In a desktop app currently you don’t have a lot of flexibility beyond writing a ton of code to move controls or resize them if the layout resizes. Trust me we have LOTS of that kind of code in the IDE.
But much of that code is just to maintain relationships between various UI elements.
“Keep button2’s left edge 20 pixels from button1’s right edge”
“Keep button2’s width the same as button3s width”
“Make sure the navigator doesn’t end up more than X pixels wide”
“Make sure the library doesn’t end up more than Y pixels wide”
That kind of stuff
Now you don’t need code to do that - those relationships are what constraints codify.
IF that makes you uncomfortable then specify EVERY constraint as “Parent.Left + X” where X is what currently is the LEFT in a desktop app. Same for top. Then always set width and height to some absolute size.
Thats basically what top left width & height are today in a desktop app.
You’ll get no dynamic behavior and effectively you will have to write all the code that you would get for free using autolayout when a view resizes (say it runs on an iPad and you designed for the iPhone) or changes to be landscape instead of portrait.