On 17 Jul 2014, at 11:34 pm, edward taffel <etaf...@me.com> wrote: > (have you actually gotten similar to work?) >
Yes, the scheme I've outlined is exactly how it works in my own app. I would share the code with you, but it's not my IP to give away unfortunately. But here's its description: I have two controller classes, one of which handles the "whole thing", i.e. the window and its stack of progress views, and another controller for each progress view. The app only interacts with the second class, (ProgressViewController - PVC) which operates on the first class implicitly. In my document's -readFromURL: method, I call a class method of ProgressViewController which creates a new PVC instance, which in turn loads the associated view UI from a nib (it's a subclass of NSViewController) and installs it into the window using methods of the first class, which is instantiated lazily, as a singleton. This is all done synchronously on the thread that is opening the document, because it's only setting up the UI, not actually doing anything visual yet. The design of the code that manages the stack of progress views is thread-safe so that PVCs being instantiated and added from several simultaneous threads is possible. The PVC is given an object to monitor, which conforms to a simple formal protocol. In my case this is a NSKeyedUnarchiver delegate, since my files are archives and I wish to show progress during the dearchiving. The PVC retains this object so it can't disappear out from under it, even after the document has finished opening. That's the end of NSDocument's involvement - progress monitoring and display is autonomous from then on. The main thread is asked to show the window, and does so (this is triggered by the PVC adding its view to the stack, and the window controller shows the window when the stack count is >0, and hides it when it = =0). A simple repeating timer - I use one that runs about 10 times per second - is used which iterates through the stack of PVCs. Each time the PVC receives the timer callback, it invokes the 'request for progress' method on the object it is monitoring, which returns its current value - I use a float so it's always normalized to a range from 0..1. The progress bar is updated. Once the progress reaches 1.0, or gets a cancel signal, the view is removed from the stack and the PVC releases itself, which also releases the monitor object, so it's all self managing. There are a couple of other things that need to be taken into account. If the document can't complete the file opening, and throws an exception, there is a mechanism that will get rid of the associated PVC, otherwise that would be just left 'stuck' waiting for more progress from its monitored object, which will never happen. There is a way for the user clicking a cancel button to abort the file opening and cause the document to abort as well. There are some other bells and whistles such as calculating and optionally displaying the estimated time to finish, and also deferring displaying the progress view such that it won't appear if the time to open is only going to be a few seconds or less - no point flashing progress up on screen if it then disappears immediately - so only truly lengthy documents end up showing a progress view. So you might do something along these lines. I'm sure it's not the only way to crack this nut, but it works well. One of my aims was to minimise the point of contact between my document subclass and the progress view stuff, and I do that by only having the document create the PVC instance, handing it something to monitor (which could be self). After that the document takes no further part in terms of driving the progress views. --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
