Re: NSProgressIndicator movement inside a loop

[Frederico Muñoz]

Hello,


On 2005-03-03 11:19:25 +0000 Richard Frith-Macdonald <address@hidden> wrote:

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

Well,  back to the drawing board then...

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

I'm using  [[NSNotificationCenter defaultCenter] postNotificationName: 
@"ProgressShouldUpdate" object: file]. 

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

Ok, this was my previous way of doing things, check for the selector and call 
it in the installer thread. The only difference is that I'm not using 
milestones, I'm calling it inside a loop that copies files. The problem for me 
in setting milestones is that in the .pkg installation process 99% of what is 
done is "copy files listes in this enumerator to this destination". I could 
trigger it at intervals, say each time 10 files are copied or something, but 
wouldn't this work the same way as doing it each time a file is copied?

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

Well, I'm probably missing something but even using notifications from the 
installer thread the update of the progress bar is only done in the main 
thread, or at least that's the way it looks to me. The updateProgress method in 
the maint thread is the one registered to handle the  notification, and it is 
only there that any UI code is in any way touched. The installer thread doesn't 
even know about the UI instances being used.

I will revert to the previous way of doing things then, while beginning to 
think that writing "When it's Done It's Done" in a NSPanel will probably be the 
easiest way to deal with this.

Best Regards,

fsmunoz
-- 
Frederico Muñoz
address@hidden