I was made aware that its difficult to add controls to iOSLibScrollView, and I experimented a bit with it.
The reasons I found are not inherent to iOSLib and may appear similarly in a lot of other iOS projects (not only those including iOSLib). Therefore (and because I realized I stumbled a number of times about this situation myself) a few hints:
Whenever you add a subview to another UIView, make sure the constraints fit. The most frequent fact of subviews behaving strangely, like you add a textfield to another view and it shrinks to its contents, although sizetoFit is false, are inherited layoutconstraints (or undefined ones if you create the view from code).
Instead of the tedious task of adding or removing constraints programmatically, I found assigning a value to the AutoresizingMask of the view (currently only available by declare) much easier. In most cases you will either want a value of 0 (no resize) or 18 (full resize).
Then, just set the views TranslatesAutoresizingMaskIntoConstraints to true.
Everything inheriting from UIView has a ContentMode property. This should be set according to your project too. In a ScrollView, you will in most cases want a ContentMode of TopLeft. If it is set to a resizing mode, the content of a scrollview will in most cases be only partially visible (and available).
Because of the IDE inheriting properties from superclasses like they were invisible inspector behavior properties, a future release of iOSLib will have this property visible in all custom controls depending on a view subclass. Its so easy to oversee else.
While the open event may be ok in Simulator for many tasks, it is often too early on a real device. During the open event, a control does not know its final size.
In the past, I recommended using the HasMovedToWindow event (named “Shown” in iOSLib custom controls). Currently, when it fires in Simulator the control still does not know its frame size. I have not checked on a real device yet.
@Jason, Antonio and the others doing iOS declares: Can you confirm this Simulator (mis)behavior? I think it is related to Simulator / Xcode 7.2. Or is the same valid for devices too?
I could find no reliable once-only event that could be used when in Simulator the control is initialized in its starting size. I have therefore added a “Init” event for customControls that fires when the first LayoutSubViews event would fire. Youll find it in the next iOSLib release. Anyway, its an workaround while the DidMoveToWindow event fires too early on Simulator.
The last is only valid for ScrollViews:
The most important property is the ContentSize. With it you define the area your scrollview will display.
Every control you put on a scrollview will be added to its contentView (again: The contentview is just the subviews of the scrollview), and you can also add Containercontrols (more easily in the next release). It is important that you set the frame of every ContainerControl to the size you want it to have. The connection between a ScrollViews frame, its ContentMode and a possible AutoResizingMask/LayoutConstraints of the ContentView would create a lot of unforeseen behavior else.
Because of this, its better not to rely on autoresizing during orientation changes. It doesnt change the contentSize automatically. With wrong constraints set, a resize could even resize the scrollview frame instead. You should better use the LayoutSubviews event (named “Resized” in custom Controls) or the TraitCollectionChanged event (Apple discourages using OrientationChange in the future) and set the contentViews frame(s) (remember this can be several frames as you can have an unlimited number of subviews in a view) and the ContentSize to the values fitting to the new view frame.
With a containerControl as template for the contentView, you can still use layoutconstraints for the controls inside the container of course.
Ill upload a new version with an easier-to-handle Scrollview (and a demo illustrating these points) this month.
Many thanks to Maximilian Tyrtania for informing me about this problem.