In the IDE when you create a container control, the inspector shows 4 locks top,left,right,bottom… This is at the ‘root’ of the container control.
What effect do these controls have? Are they the default state of a control when placed in the IDE?
Objects like buttons and container controls, within the control also have their own locks and those apply to their parent (the container) only right?
I still wish there was a way to say that one control was attached to the side of a different object in the ide ‘locking’ mechanism.
I think apple’s xcode ide uses ‘springs’.
[quote=480830:@Brian O’Brien]In the IDE when you create a container control, the inspector shows 4 locks top,left,right,bottom… This is at the ‘root’ of the container control.
What effect do these controls have? Are they the default state of a control when placed in the IDE?
[/qyuote]
pretty sure the answer is “no” and these probably shouldnt have been shown - ever
you set each instance’ locks on a layout just like any other control
[quote=480830:@Brian O’Brien]Objects like buttons and container controls, within the control also have their own locks and those apply to their parent (the container) only right?
[/quote]
yes
take note that IF the istance is locked on whatever layout it is then that will also have an effect when you resize the layout
yeah the old way was springs & struts
and you could still use it in Xcode
Apple tries to get everyone to use autolayout since you CAN express everything that you could do with springs & struts using autolayout constraints
Xojo never had springs & struts - theyd still be useful until such time autolayout happens on the desktop
i’ve contemplated creating custm classes that mimic these based on canvases or something but I think it would clutter the interface far too much
and then there is the issue of trying to perform all the layout passes to make things bechase the way I’d want
basically you’d have to use a custom subclass of windows I provided or something and … yeah
its gets complex reasonably fast