NSTableView drag and drop too smart for its own good

  • Hi,

    I have two table views, one is a source list and the other is a
    detail (list of items for that source). Selecting an item in the
    source list reloads the data in the detail.

    Now I want to be able to drag one detail item into the detail item
    for another source. I implemented a spring loaded folders type thing
    where if you hover the dragged detail item over a source, it switches
    to that source so you can drag the detail item back into the detail
    table (which now has different data than when the drag started). The
    reason for this is that ordering matters so this would give the user
    an opportunity to put it in the exact spot they want. Also note that
    they could just drop it on the source and it will add it to the end
    of the detail list.

    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).

    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?

    Thanks,
    Paul Kim
  • >
    > 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
  • on 06/09/13 9:57, Paul Kim at <mr_pickles...> wrote:

    > I have two table views, one is a source list and....

    If all of what you say is true, I'd say this is unfortunate.  I would have
    expected it to call -validateDrop

    > 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?

    Oooooo, I'd suspect there is some other trick that would be much easier than
    re-implementing drag and drop in a subclass.  How about this:

      newTableView = [originalTableView copy] ;
        // Make sure the above is a deep copy that
        // copies all instance variables
      [originalTableView retain] ;
      [originalTableView removeFromSuperview] ;
      [newTableView reloadData] ; // (gets new data)
      [windowContentView addSubview:newTableView] ;

    Then, after you've completed the drop,

      [originalTableView release] ;
  • 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
previous month september 2006 next month
MTWTFSS
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
Go to today