Re: NSProgressIndicator movement inside a loop

[Nicola Pero]

Yes -- I didn't follow the discussion, but I remember this being a
frequent question, and it's clumsy to try explain it via email, so some
years ago I wrote a full example of how to use threads with a
NSProgressIndicator ... it's on CVS under -

gnustep/usr-apps/examples/gui/Classes/NSProgressIndicator/Threads

I suggest you have a look at that.  As Richard explains, the drawing is
done in the main thread, while the "other work" is done in an auxiliary
thread which then regularly communicates to the main thread via a shared
area protected by locks.

You can check the example and even copy the code verbatim if your stuff
has got a compatible license. :-)

Thanks!

> > 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.
> 
> 
> 
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>