Re: Dragging NSManagedObject subclass within app
Re: Dragging NSManagedObject subclass within app
- Subject: Re: Dragging NSManagedObject subclass within app
- From: Graham Cox <email@hidden>
- Date: Mon, 11 Mar 2013 15:01:19 +1100
On 11/03/2013, at 2:24 PM, Rick Mann <email@hidden> wrote:
> That's just so ugly, though. The pasteboard should just accept keyed objects, like NSDictionary, precisely for this purpose, especially if you have to put *something* on it.
>
> I tried everything I could think of to do this "right," including putting the NSManagedObject's URL onto the pasteboard, and creating a "Source" protocol that the source implements to allow the destination to get at the MOC for that URL. But then Core Data makes it egregiously difficult to get the NSManagedObject back from the URI.
Classic overthinking ;)
>> Well, if you over-think the problem, then it can. But intra-app dragging is FAR simpler than extra-app dragging, since the pasteboard doesn't need to come into it.
>
> Except you have to put *something* there, right?
I assume so, but I just use an empty string to clear the contents so that if anything remained from some other drag, it's gone. However, the pasteboard is never used at any point other than setting the string, and (more importantly) setting its data type to something private and internal which basically tells my destination code 'ignore this and go look for the data pointer in the shared location we agreed on earlier'. A type is necessary since at some level your view has to register for certain dragged types.
> And it seems like there's at least some intent to allow referencing data: NSDragOperationLink.
I believe these codes mainly tell the drag manager what kind of cursor to show during the drag. The NSDragOperationLink shows an arrow with a curly 'alias' arrow badge so the intention is to use this for drags where what you're dragging is an object that represents some other object in the source, e.g. an alias. I typically use NSDragOperationPrivate when implementing an internal scheme like the one I'm describing, as I think this prevents any other app receiving the drag, but the more important thing is the data type URI on the pasteboard - that's what tells your destination to use the shared pointer instead of the pasteboard data.
> In the end, I just created an NSData* straight from my object's pointer. I'm about to ARC-ify my code (it was GC), so I'll add bridging retain/release to that, but really, the pboard should allow me to just put retained references onto it.
You could just declare a class method somewhere that stores the pointer to the original object. The source puts the pointer there, the destination reads the pointer there and copies it or whatever. Being a class method it's effectively global. Since a drag from a to b is a self-contained mode, you never have to worry about this pointer being out of date when the drag is received. If you serialize the object and put it on the pasteboard, you are doing a lot of unnecessary work, both in the conversion and in sending it out of your process and reading it back in again (conceptually - I'm not sure if it really does that unless necessary). Usually performance issues aren't that important for this kind of drag, but why do work that is not needed?
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden