> From: Gilles Celli <gilles.ce...@ecgs.lu> > Subject: Re: How to cancel a loading document in NSDocument's > readFromURL:ofType:error method ? > To: "Kyle Sluder" <kyle.slu...@gmail.com>, "Mike Abdullah" > <cocoa...@mikeabdullah.net> > Cc: cocoa-dev@lists.apple.com > Date: Thursday, 2012 February 9, 14:23 > > Thanks for the quick answers! > > Yes I'm targeting Mac OS X 10.6 and later so > canConcurrentlyReadDocumentsOfType: is a welcome addition, I > completely forgot that. > > Strangely if I put the method > canConcurrentlyReadDocumentsOfType: inside my NSDocument I > get a warning when trying to open a document (It seems to be > a QuickLook error ?) on Mac OS X 10.7.3: > > [QL] QLError(): +[QLSeamlessDocumentOpener > seamlessDocumentOpenerForURL:] should only be called in the > main thread > > Now for the cancel question: If I take the more traditional > approach to cancel the operation inside readFromURL, should > I fire up a new thread to check the flag's status ? > > Gilles > > >> On 2012 Feb 9, at 19:32, Kyle Sluder wrote: >>> On Thu, 2012 Feb 9 at 08:01, Gilles Celli <gilles.ce...@ecgs.lu> wrote: > >> I searched the mailing-list but didn't find an > answer….so sorry if this was posted before: > >> > >> I've setup a document based application which can > read large ASCII data files (>150MB). > >> > >> When opening the document the method > readFromURL:ofType:error is used which then opens a small > feedback window > >> showing the file name and an animated > progress bar with a "Cancel" NSButton. > > > > If you're targeting Snow Leopard or later, you should > override > > +canConcurrentlyReadDocumentsOfType: to return YES. > That will cause > > -initWithContentsOfURL:ofType:error: (and therefore > > -readFromURL:ofType:error:) to execute on a background > thread. > > > > Then you get to the canceling part. The traditional > approach would be > > to set a flag when the user clicks Cancel, and > periodically check this > > flag from within your -readFromURL:… implementation, > returning an > > NSUserCancelledError if you detect it has been set. > > > > A more modern approach might be to use > NSOperationQueue. Instead of a > > loop, -readFromURL:… would divide its work into > operations and enqueue > > those on a queue. Clicking the Cancel button would > enqueue an > > operation that would shut down the -readFromURL:'s > operation queue and > > cause it to return an NSUserCancelledError.
I don't get it. I though with OS X one of the great benefits was finally having pre-emptive multi-processing instead of co-operative multi-processing. Sure, when the user clicks "Cancel" it's an "event", it gets stuffed on an event queue, the wheels grind round and round and eventually that event gets popped off of the queue and paid attention to. But then... then the event processor, the action, should see that it needs to interrupt the file transfer cold, as close to immediately as possible, the buffers that were being used for the transfer freed, and control returned to the regularly scheduled programming. Neat. Sweet. And at least somewhat close to immediate in user terms. Not, Eyeore style... "ohhh, maybe... some... day..., maybe after it gets done filling the next buffer or 10... we may think about getting around to doing something about it." The master, the user, wants it done now! (Stuff like this gets sooo frustrating when Apple has the best there is... We love their systems so much...and yet...) _______________________________________________ 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
