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
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.