Feedback 16504 (<https://xojo.com/issue/16504>) is a weird one:
[quote]»» Status changed from ‘Implemented & Verified’ to ‘Closed (Won’t Implement)’.
This case has been closed because it has been decided that this feature will not be implemented.[/quote]
Why did Xojo pull the already implemented method?
Now Christian has implemented it himself:
If I read this right then you could now update a progressbar from a thread, for example from a loop
for i as integer = 0 to 100
CallDelegateOnMainThreadMBS AddressOf progressbar.update, i
Anyone from Xojo can shed any light on this?
I would love to see them doing it. I have to provide a method for each possible parameter combination, while Xojo team can write code in the code generator to add such an invoke method to the generated code for the delegate.
Christian is this method available in the Version 4.0 pr1?
You can’t just magically invoke a method on a different thread. Under the hood, you have to do one of two things.
(1) Queue up events and execute them later.
(2) Stop one thread, start the other, execute the call, back to first thread.
There are just no shortcuts with this when your underlying frameworks aren’t thread-safe. The convenience you think you gain is quickly dwarfed by the performance hit you take.
Internally we use Grand Central Dispatch or a timer. The thing with the feature request was to have Xojo generate the required code automatically. This makes coding much easier. Similar to Cocoa’s peformOnMainThread.
The performance was horrible.
And there was a risk of deadlocking the application.
of course, but only if you do the call synchronously.
Do you mean GCD on OS X and then Timers on Windows and Linux?