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
