• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSTableView drag and drop too smart for its own good
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSTableView drag and drop too smart for its own good


  • Subject: Re: NSTableView drag and drop too smart for its own good
  • From: Paul Kim <email@hidden>
  • Date: Thu, 14 Sep 2006 22:28:46 -0400

Thanks for the response.

I tried having a second table view and swapping but it doesn't quite work. It's possible I'm doing something wrong but depending on how I do it I get the following different types of symptoms:

- An extra blank row at the beginning and/or end.
- Not accepting the drag.

The closest I got was when I created the clone table and added it to the view hierarchy before the drag (but ordered below the primary table) but when I tried to take the source out of the view hierarchy during the drag, I would get odd side-effects. I get the feeling that the source of the drag doesn't like getting taken out during a drag and the potential destination needs to be registered for the pasteboard before the drag starts.

I think for now I'm going to shelve this feature until I can revisit it and maybe override NSTableView's dragging mechanism outright.

Thanks,
paul


On Sep 13, 2006, at 3:49 PM, Corbin Dunn wrote:


The problem is that it seems like NSTableView sees itself as the source of the drag, so it won't allow drops at the position of the original dragged row (thinking it's just a move of a row within itself). It doesn't even seem to call -tableView: validateDrop: proposedRow: proposedDropOperation: on my data source when the drag is over the original row position (even though in my case, the table has different data so it would make sense to drop it there).



This is a bug which will be fixed.

Is there an easy way to work around this or am I stuck re- implementing NSTableView's drag and drop in a subclass to get this to work?

An easy, cool, workaround: use two tableviews (they can have the same datasource/delegate). When switching sources, use NSViewAnimation to fade one table out and the other table in. Cool! (and avoids your issue). For abstraction, you can keep a pointer to the "active tableview" or something like that and switch back and forth.


-corbin

_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >NSTableView drag and drop too smart for its own good (From: Paul Kim <email@hidden>)
 >Re: NSTableView drag and drop too smart for its own good (From: Corbin Dunn <email@hidden>)

  • Prev by Date: Help! Can I change paperSize/tray in the middle of a print operation?
  • Next by Date: RE: How to know user clicks [print] button in cocoa PDE
  • Previous by thread: Re: NSTableView drag and drop too smart for its own good
  • Next by thread: Re: NSTableView drag and drop too smart for its own good
  • Index(es):
    • Date
    • Thread