That’s not true. You can get Block callbacks with ObjCBlock.
https://documentation.xojo.com/api/macos/objcblock.html
As for the asynchronous ones, it is possible, but you need to make sure you stay away from the Xojo framework (because it’s not thread-safe). The easiest way to do this is to only do intrinsic type assignments in the callback method, using a timer or a thread that you started before the call to wait for the callback to finish. It’s not fun but it does work.
That’s exactly what I meant. It’s not fun currently, and having a basic threadsafe framework would alleviate this tediousness quite a bit.
You do not even need all the framework thread safe.
You just need few basic things.
If we take .NET C# then not all objects are thread safe. Arrays are not thread safe and other such. (It does though offer special types of Concurrent Arrays also) but over all not all objects are thread safe.
That does not mean you cannot use it in a thread. You can use object that is not thread safe in a thread as long as it is the only thread accessing the given object.
So for example if we take file io, it would not necessarily need to be thread safe, as long as just one thread accesses the same file. (Other thread still could access some other file at same time).
This goes for most programming languages that most things are not “thread safe” its just up to the user to not let two threads access same non thread safe object from two threads at same time. If user really needs to access non thread safe objects from two threads at same time then the user needs to protect them with mutexes, again same as in other programming languages.
Which is why I have stated that its almost a sin that the memory manager is not fixed up. Since its basically the New, Reference and De-reference you need to fix and then you have most basic things (and also a lot of advanced things working in a native thread).
Xojo even could keep their non native threads if they wanted also, and just create new object “NativeThread” or some other suitable name. Only thing stopping this from being possible currently is the memory management. Which is relatively simple to fix.
(I gave them just about the c++ code for it in this issue here https://tracker.xojo.com/xojoinc/xojo/-/issues/68072 )
And lastly the argument that someone posted far above…“But that will not allow you to access UI from thread”…that is same as in all other programming languages. And same with the current non native Xojo threads, so I do not even understand why this argument is on the table.
In the feature request, I made the argument that simple documentation would be sufficient. “If you misuse this, your app will crash hard. Good luck.” Classes can be make thread-safe as required over time.
Then please make them available with the warning that it’s up to us to handle thread safety.
This would be disastrous for the reputation of the language and the company. The support burden would be enormous: they’d have to carefully investigate and document every corner of the framework that isn’t thread safe, and then prepare for the onslaught of feature requests to make this or that compatible with threads.
Xojo would get a reputation for “that language that makes apps that are always crashing” and “good language, half-baked thread implementation”.
Do it right or don’t do it, I say.
When has the first iteration of any new Xojo feature been “right” or complete?
-Karen
I’d say that might be close to the present reputation, since Xojo “threads” aren’t real threads. They call it “cooperative threading”, but all that means is that the threads aren’t real threads.
Just because the threading model isn’t what you would like it to be doesn’t invalidate it. Xojo’s cooperative threads behave as designed, and the design, while limited by its cooperative nature, is sound.
Xojo features have definitely had issues, I’m not denying that. But they haven’t felt the need to include caveats that “using this feature with the vast majority of the language is guaranteed to cause crashes.”
We don’t know that that’s true. We do know that it would be possible to crash if used incorrectly, but that may require “quick” (relatively speaking) changes to avoid. I’d leave that to the engineers. The rest can be covered by a warning as mentioned in my request.
But if we wait until it’s done “right”, it won’t be done at all and Xojo will be relegated to a niche language forever. I hope it can be introduced as a beta or experimental feature, perhaps just at the Pro level, then updated over time.
lol that is ridiculous. Not everyone is going to use threads… those who will, are not going to use them in every app and certainly not using it for every single method to have a situation where the apps is crashing just because the framework has the feature.
That’s not fair. You’re failing to mention the fact that the majority of applications don’t “need” or won’t benefit from preemptive threads. Image processing, probably. Crypto processing, also probably. Compiling applications, maybe… Xojo itself works just fine using a spawned console process for that.
I’ve been programming for close to 30 years and I can only thing of two instances when I’ve even thought that something like preemptive threads would be helpful and eventually settled on separate console apps because they get their own resources.
Also in data processing where we use them all the time to handle multi-GB files.
Just not in Xojo.
Also in electronics such as raspberry Pi. Getting real world data on one preemptive thread, showing the data on another preemptive thread, processing the data on another preemptive thread.
Perhaps this thread is the most relevant thing in the corporate world, especially when they involve transaction handling.
Do not forget to mention science, where it is common to handle millions of data.
I agree with you.
But, I have observed that some systems have gained a position in the market for being faster.
In the 80s, it was common to see competition to be the fastest. You can see that when the first versions of Windows sucked.
If your measure for Xojo remaining niche is a lack of “advanced” features then so much more needs to be done before this is even contemplated, xojo will remain a niche language if core bugs aren’t addressed, I can’t believe that time is being put in to things like WinUI before these, its embarrassing:
Obtaining a handle via a pictures graphic object stops future access - 4 years old
Structure alignment issues in Windows - 5 years old
Invalid access to memory location when trying to use a pointer to a structure in 2018r1 64bit - 4 years old
Passing structures as parameters are corrupting data - 3 months old
You make a valid point, but please don’t hijack the thread.
I’m not hijacking the thread, I’m saying that other things are more important than implementing this, its perfectly on topic.