Re: Accepting drops on a tableview's tableheader
Re: Accepting drops on a tableview's tableheader
- Subject: Re: Accepting drops on a tableview's tableheader
- From: Corbin Dunn <email@hidden>
- Date: Fri, 20 Feb 2009 10:13:58 -0800
On Feb 20, 2009, at 9:10 AM, Sean McBride wrote:
On 2/20/09 8:45 AM, Corbin Dunn said:
Yes; the *only* way to do this is with subclassing the header and
implementing the drag and drop methods.
Phooey. :) I'm guessing you've done this Corbin... anything to watch
out for? Is it sufficient to change the class name of the header in
my
nib, and write my code?
FWIW, that Finder behavior is very subtle.
I'm not a big fan of the behaviour really, but neither do I have a
better idea on how to drag a deeper item to the root...
I understand it is a dilemma; another way it is disambiguated in
Finder is by accepting a drop "on" a row (instead of "on" the entire
table) if you hover over "content" or not. You could use the -
hitTestForEvent: API on NSCell to determine if the hovered area in the
drag update is on "content" or not. Again, I'm not sure if this is
truly a recommended Human Interface design to use; I'm just pointing
it out. Many people don't realize that Finder behaves differently for
drags/drops (including starting drags) depending on what you click on
or where your mouse is over (content vs non-content areas).
-corbin
_______________________________________________
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