Odd Thread Accessing UI Exception Error

Yep, that works too, and is even better if you set it up as a computed property, then you can write nice code like

  if myControl<> nil then  // myControl is a computed property which uses a WeakRef internally
     myControl.FooBar() 
  endIf 

[quote=7646:@Michael Diehr]Generally if you are in a thread, you know precisely(*) when the thread can or can not yield back to the other threads (which is a major benefit of cooperative, as opposed to Pre-emptive threading):

So in code like this:

 if myControlWeakRef <> nil and myControlWeakRef isa Control then
   dim r as RectControl(myControlWeakRef)
   r.foo()
   r.bar()
 end if

you are guaranteed that the control will not disappear between Foo() and Bar() as long as neither Foo() nor Bar() yields.
[/quote]

I get it. As long as there are operations being done on it, it won’t disappear as long as I don’t yield back to the main thread.

But wait, if I have a loop in one of my methods, then I’m yielding at the loop boundaries - right? So then you have to keep of wether or not your control is NIL in every loop bascially…

Oops, typos, that code should be:

if myControlWeakRef <> nil and myControlWeakRef.value isa RectControl then
   dim r as RectControl = RectControl(myControlWeakRef.value)
   r.foo()
   r.bar()
end if

Yes, however, you can prevent yields at loop boundaries. I’m a liberal user of

#pragma DisablebackgroundEvents

and

  App.SleepCurrentThread(xxx)

so that I know exactly when it’s going to yield, and for how long. Often, yielding at every loop boundary is wasteful, but conversely, never yielding can be a problem too. Judicious use of these can easily give 5x to 10x speedups.