[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSProgressIndicator movement inside a loop
From: |
Richard Frith-Macdonald |
Subject: |
Re: NSProgressIndicator movement inside a loop |
Date: |
Thu, 3 Mar 2005 11:19:25 +0000 |
On 3 Mar 2005, at 10:02, Frederico Muñoz wrote:
However, and while I, as said, agree with the probable issues that can
result, what I'm doing now, and without any side effect for now, is to
call the installPackage on a NSThread and then make the installPackage
method send a notification each time it does something with a file.
Then, in the main object, I register it for the notification with the
updateProgress method. Since I'm not directly dealing with variables
between them (what I need is simply to be notified, and everything
else like the filename can go into a NSDirectory and passed inside the
notification) I think I'm pretty safe, at least while this is the only
thing I need to do. The updateProgress then deals with the
progressIndicator. I've tested this approach many times and it works
perfectly everytime. Since I'm using a notification and not calling an
object directly maybe this will help to keep the side effects down.
I don't think this is the right way to do it ... because I don't think
notifications are guaranteed to be delivered in a particular thread.
If you post them for immediate delivery, they are generally delivered
to the same thread that posts them, and if they are posted in a queue,
they are generally delivered in the first thread to execute a run loop
... which may be what is happening in your current code, and why it's
working.
The correct way (as I understand it) is to perform the slow install
operation in a second thread,
and at intervals when milestones in the install operation are
completed, call
-performSelectorOnMainThread:withObject:waitUntilDone:
with the 'waitUntilDone' flag set to NO.
This lets the main thread run normally during the install, and update
the progress bar at intervals when the installer thread tells it to.
Using this method guarantees that the update
of the progress bar is done in the main thread ... which is the only
thread that it's safe to
perform gui updates in.