thank you for this graham! at present, i’m finding it difficult to find a point, prior to NSDocument initializing autosaved documents, to show a progress window. everything above readFromURL is off the main thread & there is nothing in the application delegate protocol that precedes—so far as i’m aware. any thoughts here?
best, edward On Apr 23, 2014, at 7:36 PM, Graham Cox <[email protected]> wrote: > > On 23 Apr 2014, at 10:31 pm, edward m taffel <[email protected]> wrote: > >> i’m attempting to show load progress for complex documents. my document >> class defines readFromURL & this seems the natural place to do this; >> however, for autosaved documents the progress window does not show until the >> document window shows (in the same instant, after the load is complete). i >> expect this is something to do w/ readFromURL being sent from a background >> thread; but, there must certainly be some way to flush the progress window. >> >> all/any suggestions greatly appreciated. > > I recently (re)implemented a comprehensive progress-reporting interface in my > app, and it is able to hook into document read/writes. > > The important thing I learned was NOT to attempt to "drive" the progress > indication from the worker code (i.e. the code that's doing the actual work - > file I/O for example, or archiving/dearchiving). Instead, get the progress UI > to poll for progress on the work that it's interested in from the main > thread. This flips the situation on its head, but it works out beautifully > (the idea came from Jens Alfke). The progress UI just sits on the main > thread, updating naturally, and it periodically asks the work how far it has > got, using a simple timer. You need a protocol or other API that the worker > code can adopt so that it is pollable by progress, and a way to set up and > tear down the progress at the start and end of the work itself. In my case I > can show any number of simultaneous progress views within a stack, since > multiple work units can be done on different threads, so I also need a way to > associate the work with the given progress controller. In my case this is > trivially a reference to the object that implements the progress-pollable > protocol. > > Note that in 10.9 there is also a 'NSProgress' object that defines an API for > progress-monitorable work, though don't be misled into thinking this provides > any sort of UI - it doesn't. But adopting it rather than rolling your own > might be an idea, though in my case I didn't because I need to support back > to 10.6. > > So for the case of saving a document, which in my case involves using > NSKeyedArchiver to archive an object graph, I assign a delegate to the > archiver which keeps track of how many objects it has archived out of the > total number it will archive (figuring that out in advance was the hardest > part, but it doesn't need to be more precise than a rough estimate for > reasonable progress accuracy). The delegate starts a progress on the first > call and stops it on the last, and then the progress polls it at intervals > displaying the result. A simple 'atomic' property is all I need to read the > amount of work value in a thread-safe manner. > > --Graham > > _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
