Re: Child threads and the UI
Re: Child threads and the UI
- Subject: Re: Child threads and the UI
- From: Peter Ammon <email@hidden>
- Date: Tue, 23 Oct 2001 18:03:29 -0400
On Monday, October 22, 2001, at 04:09 PM, Chris Gehlker wrote:
I'm working on a program that does cel animation. Building a Movie can
take
awhile and I want to show a progress bar while the program is looping
through frames. Looking through the archives of this list, I found that
the
canonical approach is to launch a thread to do the animation and to use
DO
to report progress back to the main thread which runs the progress bar.
The
canonical way works.
But it also seems to work if I just let the daughter thread own the
NSProgressIndicator and the NSPanel that it's displayed in. This also
seems
like cleaner code because none of the methods in the main thread need to
know anything about the progress bar.
I'm just worried that I may be setting myself up for a fall by going
down
this path. Am I missing something?
What happens if you attempt to update the status of the
NSProgressIndicator while it is in its display: method? Bad stuff could
happen.
To make this safe, I would subclass the NSProgressIndicator, add an
NSRecursiveLock instance variable, alloc and init it, and then override
methods like so:
- (void)drawRect:(NSRect)rect {
[myLock lock];
[super drawRect:rect];
[myLock unlock];
}
- (void)incrementBy:(double)delta {
[myLock lock];
[super incrementBy:delta];
[myLock unlock];
}
- (void)setDoubleValue:(double)doubleValue {
[myLock lock];
[super setDoubleValue:doubleValue];
[myLock unlock];
}
(I suggest an NSRecursiveLock rather than simply an NSLock because it's
likely that one of setDoubleValue or incrementBy calls the other.)
Hope this helps.
-Peter