The documentation for Thread.Current says
While this property is currently Nil when accessed from the main thread, do NOT rely on this behavior as it may not be the case in future releases.
So uh… what should we rely on instead? I can’t seem to find the replacement technique.
maybe you get the main thread then … instead of nil.
Returns the thread that was executing at the moment this property was read.
Really seems like we might need a Thread.Main.
what i need is that not every event method block the UI thread …
There’s a number of ways this could be solved. If an object is returned for the main thread, we’d need a way to identify it. Or as you suggest, a method that tells us if we’re on the main thread. Whatever the solution is, it’s kind of besides the point. The point is right now Xojo tells us not to do something in order to future proof, but hasn’t given us a way to heed their advice. At least unless I’m missing something.
Which version of the docs do you use? I read the sentence, too, and at some point this was gone.
I use the online version.
I agree. We need some method of determining this now with some authority. I know I’ve implemented this in places that, thinking back, I’d rather have a dependable response.
Returning a Thread object representing the main thread could work as you could either compare Thread.Main as Thread to Thread.Current as Thread or Thread.CurrentThread.IsMain as Boolean, or Thread.MainID could be a value we compare to Thread.Current.ThreadID.
If you’ve opened a Feedback Case, I’d like to watch it.
I have not.
I have done a Feedback case: 65607 - Docs say not to relay on Thread.current = nil but they don’t say what to use instead.