The managed objects exist in a MOC whether you have a reference to that MOC or not. You can get a reference to the MOC that an MO “belongs to" from the -[NSManagedObject managedObjectContext] instance method. Since the properties you need are so few and simple, why don’t you just pass these in to the NSOperation when you create it on the main thread instead of giving it the managed object? Then the MO will never be accessed off the main queue.
> On Oct 28, 2016, at 12:02 AM, Steve Mills <sjmi...@mac.com> wrote: > > On Oct 27, 2016, at 22:49:15, Dave Fernandes <dave.fernan...@utoronto.ca> > wrote: >> >> But what managed object are you dealing with? Is the Asset a managed object? >> If so, you can only access its properties from the queue of its managed >> object context. So if it is a main queue context, you can only access the >> MO’s properties from the main queue. If it is a private queue context, you >> use performBlock on the MO’s context to execute a block of code in the >> context’s queue and you must access the MO’s properties from inside that >> block. If I’m stating something you already know, forgive me. It is not >> clear from your post. Example code would help. > > Yes, the Asset is an NSManagedObject. In this call chain, there is no > NSManagedObjectContext in sight. The NSCollectionView is simply creating item > views to display for each Asset. It asks the Asset to create an image > thumbnail. The Asset does so in via the steps I outlined before. > > Now way back in the document's init method, I set up an > NSManagedObjectContext with type NSMainQueueConcurrencyType. So yes, there is > a main queue type context, but the code that is requesting the thumbnails > knows nothing about it or even cares. > >>> On Oct 27, 2016, at 11:24 PM, Steve Mills <sjmi...@mac.com> wrote: >>> >>> I'll explain what's going on. Each NSCollectionViewItem in the >>> NSCollectionView is being assigned its representedObject (the Asset, which >>> is a reference to an image file). At that point, I ask the Asset to >>> requestPreviewImageAtSize:, which creates an NSBlockOperation (and adds it >>> to an NSOperationQueue), whose block creates a CGImageSourceRef. Before it >>> can create the CGImageSourceRef, it needs to get the url. It does this by >>> asking for its .folder and .name properties. Those are nonatomic properties >>> of the Asset. Once it has the url and the CGImageSourceRef, it creates the >>> CGImageRef, converts that to an NSImage, and finally assigns that to the >>> Asset's atomic .thumb property. >>> >>> The folder and name properties were generated by mogenerator, a tool for >>> creating document model classes for CoreData .xcdatamodeld files. The thumb >>> property is something I added manually to cache the thumbnail, and the >>> AssetItemView's NSImageView's Value binds to it as well. >>> >>> So I'm not directly dealing with any NSManagedObjectContext here. That's >>> all taken care of when the items are added to it or when a document is >>> opened. All I'm doing is generating a preview for each managed object. > > -- > Steve Mills > Drummer, Mac geek > > > _______________________________________________ > > 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/dave.fernandes%40utoronto.ca > > This email sent to dave.fernan...@utoronto.ca _______________________________________________ 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
