I’m finally starting to try my hand at putting together an iOS project. I want to create some canvas controls dynamically. So I’ve been experimenting with how to do this. in the open event of a view I have the following:
Sub Open()
For i as Integer = 0 to 4
Dim c as New iOSCanvas
AddHandler c.PointerDrag, AddressOf CanvasPointerDrag
AddHandler c.PointerUp, AddressOf CanvasPointerUp
AddHandler c.Paint, AddressOf CanvasPaint
self.AddControl(c)
MyCanvases.Append c ' MyCanvases() is a property of the view of type iOSCanvas
Dim cleft as New iOSLayoutConstraint(c, _
iOSLayoutConstraint.AttributeTypes.Left, _
iOSLayoutConstraint.RelationTypes.Equal, _
self, _
iOSLayoutConstraint.AttributeTypes.left, 1.0, 10.0)
Dim ctop as New iOSLayoutConstraint(c, _
iOSLayoutConstraint.AttributeTypes.Top, _
iOSLayoutConstraint.RelationTypes.Equal, _
self, _
iOSLayoutConstraint.AttributeTypes.Top, i ,100.0)
self.AddConstraint(cleft)
self.AddConstraint(ctop)
c.Invalidate
Next
End Sub
Now what I don’t understand is that the paint delegate I define never fires for any of the canvases, even though I call invalidate. Also, whenever I check the .left or .top properties of the canvases, they are always 0.00 and 0.00. So I’m not sure if I’m not setting the auto layout constraints correctly or what I am doing.
Without having the paint event fire, my canvases never draw anything so I have no idea where they are at, etc.
there’s no height or width to your controls either so they might actually exist and never show which may influence whether they paint (something thats basically invisible makes no sense to draw)
why not start out poking at the example in ios > controls > dynamic controls example and seeing how to modify that to what you want
[quote=203599:@Norman Palardy]there’s no height or width to your controls either so they might actually exist and never show which may influence whether they paint (something thats basically invisible makes no sense to draw)
why not start out poking at the example in ios > controls > dynamic controls example and seeing how to modify that to what you want[/quote]
I did start by looking at that example. That’s where I got a lot of this. But that’s also a pretty weak example, IMHO.
So here’s how weak that Dynamic Controls example is:
1.) There is no height or width properties specified in that example.
2.) Norman says I need to specify width and height.
3.) You can’t assign values to width and height because in all their infinite wisdom, Xojo decided to use this incredibly cryptic IOSLayoutConstraint object where to even be able to clearly read it, you have to break it into multiple lines.
4.) This cryptic object is like poorly documented and it’s practically impossible to figure out or understand how to implement it.
So this isn’t really the help I was hoping to get…
And even if a canvas has zero width and zero height, the paint event should still fire. But it’s not…
And here’s something else I don’t understand about this IOSlayoutConstraint:
1.) The Width of the control is part of the layout constraints. Why? The width of a control is a property of the control not of the layout.
2.) So I have to create this cryptic constraint just to set the width. However, I have to reference this width to some other object which I assume is that view. But what does a width of a control have anything to do with the view?
examples are intended to show you the basics of “how to” not be a full blown instructional video
that one adds two controls, adds layout constraints for both and sets up the handlers for the events on one of them
adding more or different controls is just a matter of changing type names & event handlers needed to be set up but the basics are all the same
there’s no height or width because they are implicit (it uses leading, top, right & bottom instead)
iOS is smart enough that IF the object is not visible or not showing (because it has no height or width) it doesn’t bother asking the thing to paint
It preserves battery life
[quote=203602:@Jon Ogden]And here’s something else I don’t understand about this IOSlayoutConstraint:
1.) The Width of the control is part of the layout constraints. Why? The width of a control is a property of the control not of the layout.
2.) So I have to create this cryptic constraint just to set the width. However, I have to reference this width to some other object which I assume is that view. But what does a width of a control have anything to do with the view?
You guys did not make this easy at all…[/quote]
the width is a side effect of applying all the constraints
if a label is 80 pixels wide in portrait it might be 180 in landscape (or swap English for German and one is likely longer than the other)
hard wired width & height dont let you dynamically do this
Don’t blame it all on XOJO [Apple and the industry share some of the blame) :)… but I agree… Autolayout is a royal PITA, which is why I
a) skipped XOJO iOS for now
b) developed a non AL method in SWIFT for handling layout across all Device sizes…
[quote=203605:@Dave S]Don’t blame it all on XOJO [Apple and the industry share some of the blame) :)… but I agree… Autolayout is a royal PITA, which is why I
a) skipped XOJO iOS for now
b) developed a non AL method in SWIFT for handling layout across all Device sizes…[/quote]
As convoluted as Auto Layout may seem, when there is nothing it is far from ideal, B4A has none of that, only an autoScale that manages the changes in resolution, but not rotation changes.
People who develop with it have to prepare a set of two views ; one for portrait, one for landscape.
Not ideal.
As a result, several people have created libraries more or less in the spirit of what Elastic Windows and RubberViews Desktop do, that is autoscale all the way to any view aspect ratio. But no constraints. So a button may end up awfully wide and terribly short, or a video would become all the sudden super super super panoramic with a tiny picture in the center.
Auto Layout enables fixing limits to these side effects, to prevent collision when a control must keep its aspect ratio (say a circle), and all sorts of nice things.
The only reproach I would make to Xojo iOS way is that if one needs to change a constraint, it has to be named first. It would be a great deal easier to to have something like
Control.IsPresent(XCenter) as Boolean
So instead of having to name the constraint, after checking if it has been used, one would do something like
Is there anyway to turn auto layout off? It is not something I need, and its implementation in Xojo is not great.
It seems like a tool for people who can’t be bothered to design interfaces properly.
the implementation of Autolayout is not great “period.”… Had little to do with how XOJO implemented it.
However, it can be “turned off”, by (if I understand correctly), not making controls relative to others… just make the positions absolute.
Left=Parent.Left+x where parent is the view etc.
however, doesn’t seem XOJO gives you the ability to easily set position in code
me.left=20 ’ cannot assign a value to this property
which makes it seem that as long as you are building for ONE device (such as iPad) you might get away with it.
but not for iPhone where you have 1/2 dozen sizes (and Portrait vs Landscape) to boot
and unfortuatly Apple defines “Auto Layout” as “the proper way”…
but interestingly enough, their own programming languages (ObjC/Swift) allow you to use or not use AL as you see fit
If you haven’t figure it out by now… I am in no way shape or form enamored with any aspects of AutoLayout regardless of who designed the implementation.
For each control, keep only left relative to Parent.Left, Top relative to Parent.Top, make Width and height absolute.
That will effectively turn off auto layout, but you will then have to manage everything when the user rotates. Also, you will need to change these values when the program runs on a different device than that of the original view.
My reaction to auto layout was the same as yours originally. I encourage you to push through and spend a day playing with it to understand how everything works. Play with percentages, relatives, everything. AL might make no sense to you now, but after playing with it everything will make sense to you and you will see how much AL simplifies your displays and how helpful it truly is.
Yes I completely agree. Auto-layout is “different” and can be a little confusing at first but it fairly quickly becomes clear and makes a lot of sense. It’s worth spending a bit of time to come to grips with it. The results can be pretty great. My iPhone app looks almost perfect on an iPad for no extra work. If I had a few more iPad users I would do a day or so and make some iPad-specific views but, as I say, auto-layout can pretty much take care of all but the real corner cases for you.
One thing is for sure : without Auto Layout between phones and iPad, including the new iPad Pro, that is 7 different screen sizes which would require the appropriate settings and a total of 14 views to accommodate portrait and landscape orientation.
So even if indeed it is possible to work without auto layout, it would be rather foolish to do so.
Taking it one step at a time makes it easier to grasp.
I don’t know why everyone keeps saying it takes 14 different views to support “i” devices without using AutoLayout.
The app is only running on ONE device at a time… and assuming you need to support both Port and Land that is TWO views.
It is such a simple matter to calculate the appropriate position (and size if required) of each control in the view. And something that I don’t think AL can do, change the FONTSIZE … Also, in some cases you might want/need to layout the controls differently (say between an iPhone4s and 6+) …
Plus you have the ability to move controls around much more easily.
But then this is my view and my opinion… and I will allow those who are AL believers to continue, as those of us who are to be considered “blasphemous” will also continue… Seems it is time to add a 3rd item to the list of subjects that cannot be argued.
Religion, Politics and AutoLayout
[but then I again… I use XCODE but despise Interface Builder ]
Have ‘played’ a bit… and had a friend who idoes a lot of IOS dev. (not in Xojo though) have a go, and everytime we tried
to do something it was a case of ’ hmmm,… its not supposed to do that’
Buttons that are 120px wide, but when you query the width Xojo says its 100px.
Trying to set a width in the autolayout- accepts the number but does not change the button width.
Strange values appearing in the ‘offset’ 1.92e-1 or something equally useless.
Buttons vanishing and not being able to get them back
etc… etc… etc…
This app. only needs to run on an iPad, and we will probably just do it as a web page now as that should work.
