How to clean up allocated memory from a usercontrol?

I’ve been playing around with Jason’s PickerView control (thanks a lot for it this way, Jason! – and all the other classes!)
I instantiated one on a new view, pushedto it and returned and found a slight memory leak – each time I was pushing to a new view of this kind 0.1 – 0.2 MB were added.
On closing the Picker, I added steps so the datasource is now freed

removehandler dataSource.SelectionChanged, AddressOf HandleSelectionChange dataSource.RemoveFromDict // a method doing exactly that iOSLibResponder.setDelegate (id, nil) dataSource = nil
which seems to help clean up the datasource.

Then I noticed the docs say a usercontrol view should be set up autoreleasing, so I added a call to autorelase too.
But still memory is leaking, and I wonder what happens to a usercontrol that gets out of scope? The Pickerview’s destructor never gets called, and a dealloc on the pickerview’s Id on the close event of the usercontrol is a certain way to crash the app.

Is there a way to release all the memory belonging to a usercontrol? Or will the autorelease block catch it but after a long delay eventually?

You should not need to use any release mechanism, iOS is supposed to be using ARC (Automatic Resource Counting)…

The release commands that ObjC had, are not even mentioned in 99.9% of the documentation for the new SWIFT, so I don’t see why XOJO would need them either

Xojo has automatic reference control and doesn’t use ARC as far as I know.
So Xojo framework does the release/retain and you just need objects to have a chance of going out of scope.
Especially if view has no longer a reference to sub view and sub view no longer a reference to parent view, it can go out of scope.

[quote=177346:@Dave S]

You should not need to use any release mechanism, iOS is supposed to be using ARC (Automatic Resource Counting)…[/quote]
Hi Dave, Christian,
The automatic reference counting of Xojo is ARC, or do I err?
When I don’t release a self-created iOS control in its destructor, memoryleaks appear. We had this topic in another thread here.

And the idea to autorelease stems from the iOSUsercontrol doc:

Maybe the engineers could clarify this issue: Should we cast an autorelease on usercontrol views? And do they every fully get out of scope?

ARC is a feature from Apple’s C compilers.
Xojo does it’s own reference counting.

And that’s why we need to release a declared object we have the ownership for in its destructor, if I understood correctly.
But how do you handle the autorelease on your iOS customcontrols? Is their memory released completely?

the destructor of your iOS control should release the handle with a release message.
If you setup a delegate it may need to be removed, too.
Just remove all references you installed, so you have no circular reference.

Thank you, Christian. So I’ve done everything as good as I could (and would advise the other iOS add-on builders to check for releasing allocated delegates/DataSource objects too). It’s still a mystery to me what happens to the UIView object of a usercontrol that sits on a closed iOSView. I find no hint of it being released, and Apple says “Views are no longer purged under low-memory conditions and so this method (viewDidUnload) is never called.” Does every view persist until the app quits?

But so far it’s not that much memory getting lost, although I ’d like to reduce it to 0.