On 2013/07/12, at 10:49, Graham Cox <graham....@bigpond.com> wrote:
> > On 12/07/2013, at 10:35 AM, dangerwillrobinsondan...@gmail.com wrote: > >> However, based on the way I have simply put the row selection indexes >> NSIndexSet into NSData and into the pasteboard, the API as I see it at the >> moment (using NSDraggingSession property draggingFormation ) may not work >> for me without some additional work. >> >> I wasn't really wanting to put the represented objects of my rows on to the >> pasteboard, since NSView and NSTableView do a lot of the dragging API work >> already, it may have to be a feature I handle later, it looks like a lot of >> work for now, and the API seems spread out amongst a lot of different >> classes I am not familiar with… :( > > > Is the drag expected to work between different apps or simply within your own > app? Both. Internal for reordering rows for now. But will be adding drag to move and drag to copy between collections, as well as drag to external for copying a text or image representation. > > If the latter, there is no reason to put anything on the pasteboard other > than enough dummy data to identify the drag (usually your private drag type > and an empty string are enough). When you start the drag, put the real data > somewhere accessible, such as a class method. When you receive the drag and > identify it as this private type, use the class method to get the data. That > data can be the original index set for example (though as far as I can see > there's nothing to stop you putting the index set on the pasteboard directly, > not sure why you need to convert to NSData). Hadn't thought of it that way. Examples of drag to reorder that I saw all used NSData IIRC. ... > > The point is that the drag APIs standardise the visual side of the process, > but do not force you to use the data side of the process unless the objective > is to pass data between apps. Particularly for table reordering or dragging > in and out of tables, it's often much easier to bypass the data side of the > drag manager. Putting your actual objects on the pasteboard is a waste of > time, since they're only going to be converted back again in a different > place within the same app. Good perspective! This makes it really like the drag op destination is a manually initiated notification in my mind. I will give this a try as it promises to clean up some unnecessary code. But to support the other kinds of drag ops, I may need to go with a heavier weight pasteboard entry? ( since there's no way to preemptively know the destination) I still want to control the drag image in any drag op and have a bit of learning and experimenting to do in that space. But I will start with one. ;) Last for polish I need to figure out the animation of row reordering when drag is internal. But that's not the highest priority at the moment. > > --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
