Thanks a lot, Christoph! Doesn’t surprise me there’s problems with the older projects. I think it makes much more sense to have them as a lib and I will rebuild the other projects (and add to them) in the next weeks. If something is disturbing, please tell me like with the picker 
Or I should examine the scope of some enumerations and functions. I guess it’s better to restrict it will have a look at it.
Have you try to build the project “UIImageView With iOSControlExtension.xojo_binary_project” ?
Result : Xojo crash !
Oh, that’s bad. What does the crashlog tell about it?
I encapsulated the classes a bit more by refining the scopes. But hearing that, I am afraid it still won’t do. Could you give it a try?
(I replaced the file, adding a few more view transformation features too.)
EDIT: I don’t own an iOS dev license yet. Can you others confirm the crash and add some information? Looks like a case for a bug report, but it would be good to have some data to report.
[quote=156232:@Ulrich Bogun]Oh, that’s bad. What does the crashlog tell about it?
I encapsulated the classes a bit more by refining the scopes. But hearing that, I am afraid it still won’t do. Could you give it a try?
(I replaced the file, adding a few more view transformation features too.)
EDIT: I don’t own an iOS dev license yet. Can you others confirm the crash and add some information? Looks like a case for a bug report, but it would be good to have some data to report.[/quote]
You do not need an Apple developer contract to build. Just to install the built app on a device or upload it to iTunes Connect.
I just tried to build UIImageView with iOSControlExtension, and it gets stuck on
Build “UITextfield” for iOS
UIImageView with iOSControlExtension,
BlockanimationView
I thought it was simply that the build is slow, but after several minutes letting it simmer in the back of my desktop, it really seems stuck.
I force quit and retarted, now it hangs again, now on View1
I got the crash report from the force quit. I can attach it to your bug report if you want. It does say the app was hung before the force quit.
If I remove “UIImageView” class and all reference. The project build perfectly.
Thanks, you too. I suspect a problem with some subclass properties, think I have to check for overrides that may cause a problem. There are some overrides which should work, but maybe they confuse LLVM currently. I am afraid I will have to ask you for assistance, coz the Evangelist iOS build license was not updated before the holiday break and I cannot build therefore.
It could be better to put the subclasses in different separate files again in most cases they will not be needed. You can address almost everything UIView offers from the extension modules, but not the block animations. I will try to set up the old animation classes for within the extension, so the difference would be you cannot receive animation finished events.
In the long run, though, both class and module should work together even in a build
After a bit of digging, the IDE crash on build results from having a property of type struct with a size > 4.
In the iOSControls module the struct is CGAffineTransform and the two properties of UIImageView are “Transformation As CGAffineTransform” and “TransformToTransformation As CGAffineTransform”.
If you delete those two properties (and all references) a blank iOS project with iOSControls Builds.
I’ve created a ticket, Feedback #37567 - Crash on Build for iOS Project with a Property Type Struct with size > 4
I’ve attached a sample project I built, it does not include iOSControl code.
Thanks a lot, Stephen!
It’s strange the struct works with methods using assign but not with properties. I could get rid of Transformation but not of TransformtoTransformation but I encapsulated it in the extension instead of the class. Maybe this helps?
The old style animations are just rotation now, the rest in the new subview is still the block animation method.
If nothing helps I would have to cut back a few block animation methods until the compiler can add such a structure. Or store the CGAffineTransformation values separately for the helper property.
New download under a shorter name: https://dl.dropboxusercontent.com/u/21200221/Xojo/iOSLib.zip
A good year to you and thanks again for your help!
As long as any property is of type Struct with size greater than 4 the IDE will crash when building but I found a workaround - change the type of the two CGAffineTransformation properties to single element arrays.
“Transformation As CGAffineTransform” becomes “Transformation(0) As CGAffineTransform”
“TransformToTransformation As CGAffineTransform” becomes “TransformToTransformation(0) As CGAffineTransform”
The compiler doesn’t explode on single element arrays of structs larger than size 4.
You need to do a compile and manualy fix to all the references but as long as you are careful to keep the difference between Transformation, Transform, and TransformToTransformation straight its not too bad.
[You can preserve your current code by creating a new class, sticking your single element array in there and using get/set/operator_convert/assigns ect) to hide it. I went for the straight forward fix because I was already working around a complier issue so I didn’t want to give it an opportunity for more havoc.]
I made this change in the the Dec 30th version of “UIImageView With iOSControlExtension” and was able to run it in the simulator as before.
However, there is another problem before we can get onto actual hardware , as @Michel Bujardet points out above, when you try to build the current “UIImageView With iOSControlExtension” (pre-iOSLib changes), the IDE will hang on building the “BlockanimationView”. I expected this to be a side effect of the struct problem and to be fixed but it is not, it still happens after the properties are converted to single element arrays. It may be that view is just too complex for Xojo to handle right now.
If I rip out the BlockanimationView and replace it with a very simple view (e.g. just UIImageView and enough buttons to rotate it) then I can build the project, deploy it onto my iPad 2.0 (iOS 7.1) and run it!
Unfortunately, instead of the nicely rotation Apple I get on the simulator I see my Apple disappearing into the distance and never returning. 
I suspect that in pulling parts off the more complex view I’ve left some initialization code out but it does run and the View Transitions stuff seems to work fine.
Thanks again, Stephen! That is extremely valuable help for me!
I reconfigured the TransformtoTransformation property to run via a method, thus it will be easy to forward it to an array. Great that’s working! Transformation was useless and is gone.
For the Block view, I wouldn’t care so much about it. All that project is meant to work as an example lib, not for compilation. I got rid of the UITextView subclass and configured it via an extension method too, maybe this will help in making it run in a build too. But maybe it can help the engineers track down compilation errors for rather complex projects.
The reason your apple vanishes is that you probably call the animation with a “Continuefromcurrent” option which Apple does not recommend. The frame property gets twisted too. Try to change the switch, this should help. It’s possible there is an error in the latest version. I have corrected things and will upload the project before I go to sleep.
And there’s another addition: NSNotification making it possible to catch system and control events. I set up a general example view catching every event and will try to attach a specialized one to a Textfield.
I understand about the block view as example. We have all built setups like that, just places to test different parameters to see what happens. I was more interested in finding out if the compiler was crashing behind the scenes or just taking a long time to compile a complex view. Turns out it was just taking a LONGGGGGG time. Based on CPU time from Activity Monitor, it took about 34 minutes but it did Build. (It was running the CPU at 100% whenever I checked in on it so I’m using total CPU time from Activity Monitor as a rough measure of compile time)
It finished and I was able to load it on my iPad and run it.
I wouldn’t submit someone else’s code but passing that project along to Team Xojo with a note that someone was reporting 30+ minutes to compile it on a mid-2010 iMac with 16 GB of RAM and that seems a bit much.
That’s interesting, thank you!
I have just updated the file (https://dl.dropboxusercontent.com/u/21200221/Xojo/iOSLib.zip) now with your workaround for the remaining property and a refined Textfield with extension and a Notification handler. I installed one in the old animation view (the color field) who sends his NSNotifications to the debuglog. Textchanged is of course a bit too much, but I wanted to see if it’s the end or the changed event that Xojo implemented. The notification documentation is missing or incomplete yet. And old style animations are still just rotation.
Could you check if this still needs long to compile (no need to wait, just check if it seems to hang) if you find the time. I would create a feedback report with the current files then.
Thanks again & good night!
[quote=156496:@Ulrich Bogun]I have just updated the file (https://dl.dropboxusercontent.com/u/21200221/Xojo/iOSLib.zip ) now with your workaround for the remaining property and a refined Textfield with extension and a Notification handler. I installed one in the old animation view (the color field) who sends his NSNotifications to the debuglog. Textchanged is of course a bit too much, but I wanted to see if it’s the end or the changed event that Xojo implemented. The notification documentation is missing or incomplete yet. And old style animations are still just rotation.
Could you check if this still needs long to compile (no need to wait, just check if it seems to hang) if you find the time. I would create a feedback report with the current files then.[/quote]
Still stuck on BlockAnimationView with the beachball. I have force quit and saved the crash log, so I will be able to attach it to your bug report as well.
A little over an hour on the new project.
It looks like the addition of OldAnimationView, which appears to be an (almost) duplicate of the BlockanimationView about doubled the Build time.
I’ve added to your feedback case and attached a copy of the system’s cpu_resource.spin report in cast that has useful info for them.
I attached the crash log subsequent to force quitting the stuck building process.