I’ve a iOSScrollableArea in a view.
Everything works great in portrait mode but when switching to landscape mode, the container’s width doesn’t change.
Of course all the auto-layout contraints are set to make it happen.
Any idea ?
Nobody on this ?
Am I missing something ?
The scrollable view change its size but don’t update the size of the content view.
That’s how it works.
If you need to change the content dimensions you have to do by code (named constrains are useful for this) and update (via declare) the contentSize of the scrollableView
In other words, as you create your ScrollableView the size of the contentView is automatically created.
If you need to change it you have to know the new size and tell the ScrollableView about it.
The declare involved are:
to set the newSize:
Declare sub SetContentSize lib “UIKit” selector “setContentSize:”(o as Ptr, p as CGSize)
to get the currentSize:
Declare function GetContentSize lib “UIKit” selector “contentSize”(o as Ptr) as CGSize
where the Ptr is the scrollableView handle and CGSize is a structure {width as CGFloat, height as CGFloat)
Thanks @Antonio Rinaldi
This is another proof of that Xojo iOS framework is not mature.
I’m really thinking about switching to another tool.
I know it’s not really the place but is there any suggestions ?
Or better, can Xojo quickly announce a true and precise roadmap to reinsure their users ?
Could one of you file a bug report about this?
Done : #46608 - iOSScrollArea content size doesn’t change on screen resize
That done, I insist on having a true and precise “near future” roadmap.
Perhaps using sprints and weekly versions would help a lot (a lot of us use this method with their customers).
Otherwise, a lot of upset mobile developers will switch to other platforms…
Please no
It’s not the contents size that must change on rotation.
It’s the lack of content size assignment/reading
in your app you need to set the content size as width as the the screen, there are other cases (most) that doesn’t need it.
@Greg O’Lone <https://xojo.com/issue/46607>
[quote=309777:@ValryTarondeau]Done : #46608 - iOSScrollArea content size doesn’t change on screen resize
That done, I insist on having a true and precise “near future” roadmap.
Perhaps using sprints and weekly versions would help a lot (a lot of us use this method with their customers).
Otherwise, a lot of upset mobile developers will switch to other platforms…[/quote]
Don’t hold your breath… Xojo never does (or has) announce anything until its a done deal.
At best Xojo release 3 to 5 releases a year. Doubt they will ever go Agile (except perhaps internally)
you best alternative is SWIFT
The catch 22 here is Xojo in its present state is indeed a Xojo product, meaning it remains simple to use. But it lacks power.
XCode with Swift is much more powerful with access to the entirety of the framework, but it is more complex to use. Admitting one has a good mastery of both languages, otherwise learning Swift compounds difficulties. That also includes the Swift language which has been in a state of flux for a while, breaking previous code in a way that Xojo never did, even with the advent of the new framework.
Mind you, Apple forums are nowhere near as warm and cosy as here. IMHO this is a valuable asset as well. Plus, Apple is notorious for giving no roadmap whatsoever, and to change/deprecate/remove stuff on their developers with little or no notice.
Swift is NO more complicated than learning any other language (I’d put it on the same level as Xojo in this respect). And while it is true that Swift 2 broke things in Swift 1, and Swift 3 broke things in Swift 2… The NICE thing is, that XCode for the most part (95%) detects those things and alters the syntax approriately. I had a Swift 2 project, that Swift 3 detected 295 changes, and when Xcode did its thing, I had 3 or 4 to deal with… Total upgrade time… 10 minutes
WIth this I will agree.
Another thing… Xojo for iOS for the most part “forces” you to use AutoLayout, and only thoses controls that are available in the IDE (or 3rd party libaray)… SWIFT offers no such restriction… Use Interface Builder (with or without AL), or don’t use Interface Builder at all, and be a flexible as is necessary… You CAN (and I Do) write a Swift app 100% in code (views, controls, logic the whole 9 yards)
XCode is more complex. Even if Swift is indeed not that difficult to learn.
Guess you can have your opinion… Not sure how/why you think that… you type code… you compile code… just like Xojo
XCode, like Visual Studio, exposes all the properties of native controls, which results in a more complex Inspector and a complex set of choices. Or should I say potential paradox of choice.
The way to manage views and implement actions is not as straightforward as Xojo.
And I am not even talking about auto layout…
This is indeed my opinion, but are not forums meant to exchange points of view ? What a dreary world would it be if everybody had the same opinion 
No but you ARE talking about Interface Builder, which if you notice I do not like either, and as such do not use it. As to IB exposing more choices, that (my opinion) is called flexibility, something that Xojo current does not offer. And if you ignore IB, you use those properties that pertain to your application, and dismiss the rest (as in you never see them, and never have to deal with them)… But now this “exchange of viewpoints” seems to become a religious/political discussion…
Seem the best we can agree, is the Xojo for iOS is far from ready to be a prime time player.
As I have expressed many times… I think Xojo for iOS would become a much greater product, if the current level was FREE (and I don’t mean just IDE free). This would either create a much larger iOS community (of which I may have become a member), but I’m not willing to shell out $300 for an under-powered, feature lacking environement, when there is a much more powerful (and just as easy to learn) alternative for FREE
Without Interface Builder, we are stepping back in the dark ages.
But as you say, I don’t want to hurt your beliefs.
Concerning Xojo iOS, I feel it has evolved to something usable, albeit not quite as potent as Desktop. But as Norman quite rightly said, it is only two years old, versus 20.
I do regret that Xojo never considered bringing in dtPlugins, or contracting Jason King or Ulrich Bogun to incorporate their libraries, or simply to create badly missing controls. I frankly don’t understand what the strategy is, here, not exposing most properties, having no regard for any small requests in that respect… I said it before, but I don’t think anybody is in charge of that unfortunate platform.
I can just hope Android will be more complete than the toyish thing that iOS was two years ago. Otherwise it has no chances in front of B4A, or, even, Android development kit. After all, one could do worse than Java and their IDE. Pretty much the same as XCode if you tell me…
This is becoming really off-topic.
Of course, I agree that Xojo iOS is actually not a solid and mature tool for developing iOS apps.
I really hope for this to change quickly.
But, comparing Xojo to Apple is a nonsense. Of course Apple has real reasons not to communicate on their roadmap !
In my opinion, Xojo has no good reason to do so (and their real competitors do).
The real comparison would be Xojo vs B4I/B4A and that’s a real concern for all of us.
Mobile development is become the most important market for us now and it will increase in the near future.
So, we all do want a simple tool to quickly make good looking apps for iOS and Android.
For me Swift and Android SDK will never be a choice. I’ve invested all these years in Xojo beacuse it’s exactly the kind of tool I need.
But now, it’s a dead end, and that makes me upset.
Hoping for this thread to help Xojo decision-makers modify their strategy.
It should be a major concern for Xojo. As for us customers, frankly I hope Xojo understands that providing incomplete products and on top of it showing attitude at the slightest criticism, is probably the best way to lose us.
I don’t care about roadmap. I care about seeing that efforts are made to catch up, and to listen to users.
I have been a user of B4A for several years. Their IDE sucks, but frankly the product is at the same level as Xojo Desktop in terms of features. When Xojo Android comes, it better be on par for me to consider it. If it is anywhere near the state of incompletion as Xojo iOS today, I will never come back. Heck, without the help of dtPlugins, I could not even print from Xojo iOS ! And I filed a feature request back in December 2014 !
Yes, Xojo better not take customers from granted. As much as I love Xojo, I simply can’t have my business depend on half baked tools.
As far as XCode, Visual Studio (VB.Net is not as terrible as it’s made to be), or Google Android SDK, the comparison is indeed far fetched, but for a competent programmer, it is far from being a nonsense. At some point, the limitations of Xojo may command usage of these tools. Let alone to avoid convoluted and sometimes badly bugged declares.
I dont see it that way. I understand the wish for more complete native controls perfectly (and I surely hope they will mature soon too), but it will never be possible to include the complete APIs of all platforms natively. Somehow, there seems to exist an idea that declares are kind of cheating and one could endanger the Xojo side of the app by incorporating declares. They are not, they offer a way to use all the missing features. Sometimes easier, like in your case, sometimes more difficult in cases where no native Xojo control exists.
About the roadmap: Xojo has communicated their roadmap for 2017 very in-depth. While there was nothing said about more or better iOS controls, it will become much easier to declare into APIs later this year. If you use Xcode, you have to dig into the control and view hierarchy and understand the API features. Thats basically the same thing you have to do if you declare into a control from Xojo, only currently you need one more line to make use of it a declare. iOS controls have their handles available, so you are only a few lines away from solving your problem. Antonio sent you a solution. If you are unsure about how to use it in your project, feel free to ask for help.
Before that, you have to dig into Apple documentation, and that is no piece of cake sometimes 
And I wouldn’t say readability has improved since their layout change. I found many undocumented features (they are listed but not explained) and a lot of very suspicious implementation dates that indicate long-known properties would have been implemented very recently.
Besides I tried to build a small subclass based on Antonios declare but it does not work. The iOSView.Resized event fires only every second time (or less) in Simulator, so the canvas stays pretty much the same size. If someone could have a look and see if i made some mistake or there is a bug in the event: https://dl.dropboxusercontent.com/u/21200221/Xojo/ScrollContentResize.zip
Watch the debug log where the HandleViewResize method prints out the width and height of the ScrollableArea and the width of the canvas.