Some questions about threads

I haven’t worked much with Xojo threads, most of my code is happy to run on the main thread. This time I needed a thread in iOS and have stumbled over a few questions:

– Why is there no thread object in iOS library? I can define one, but it will carry the object icon. To use the thread icon, I copied the thread from one of the iOS examples.

– Autocomplete shows a kill method, but it is not available. Shouldn’t autocomplete be aware that a thread in iOS is a xojo.threading.thread and only show the availaible properties/methods?

And most of all:
– In this thread, I do some conversions on a Xojo array of UIViews and attach the result to another Xojo array of iOSImages. Nothing else. When I do this in a normal method, of course the UI isn’t responding for the few seconds this conversion takes. Afterwards everything works as expected.
When I call the conversion on a thread (shortly after I pushed the view to the one that’s connected to the conversion), the UI is unresponsive ever after the thread loop completed. My buttons do not fire their action events anymore.
I am unsure what is happening in this case. Do I have to do anything special at the end of this thread to return to normal function?

Don’t use UIViews out of the main thread

They are just objects in this case, not attached to any other view. That doesn’t seem to be the problem; I can add them to my array. Or do you think somehow the frameworks (Xojo/UIKit) get confused when handling them?

in other other words: should work, but is not guaranteed the absence of unpredictable side effect

Thanks a lot, Antonio!
It looks like pushing a view over the current has a certain effect on the underlying iOSView – when the thread starts, the parent ViewController flashes once (though I switched to another one), after that everything doesn’t respond anymore.

Anyway: There’s nothing I missed and a completed thread should be completed, right? If the iOSView doesn’t respond anymore I have to search for another solution – or stay in main thread and keep the user waiting without much feedback in between (or create the classes necessary for a live update of a progressbar). Not really satisfying, but at least a definitive answer.

(Note: I still don’t know why there’s not thread object in iOS library. Do you?)

EDIT: Another remarkable thing is I wasn’t able to update a progressbar. I did make the thread wait a bit just like the iOS example, and I had a timer trying to refresh the bar in between. It was updated after the thread finished – all invalidate calls where processed then, making it move swiftly to a full bar –. So yes, something is not working when you push to another iOSView, or when you handle iOSObjects in a thread – not sure which one is the reason.

I was surprised to see a slowdown while I append iOSImages to the array. When I write to debuglog after each append, the last of about 100 images take visibly longer than the first, although I instantiated the array for that size.

I’m working on it
I will let you now my test results as soon I can obtain something doable, predictable and stable

Meanwhile, I found the stupid answer to why many of my custom controls didn’t work: I accidentally included the LayoutSubviews event, so they didn’t draw their content anymore – and I messed up the control state which is a bitmask instead of an enumeration. Good to go through all that code again with a bit more understanding …

If you can’t kill a thread in iOS doesn’t that represent a memory leak since all you can do is suspend it?