Hi all,

I have a NSOutlineView (view based), and I have a fairly complex drag and drop 
situation. In implementing the dataSource method 
-outlineView:validateDrop:proposedItem:proposedChildIndex:, I need to find out 
exactly which row the mouse is over. This is because in some cases I need to 
drop between rows, even thought the row the mouse is over is a parent row. 
Depending on this, I need to drop above or below according to whether the mouse 
is above or below the half-way point of the row.

This is slightly different from the standard drag/drop stuff built-in to the 
table, which appears to divide each row approximately into thirds (not halves) 
when deciding which row the drag is over. Depending on exactly which item the 
row represents, I need to look at halves or thirds.

Here’s where it’s weird. In my validator method, I need to figure out for 
myself what true row I’m over, rather than take as read the value in <item> 
passed by the table. Should be easy - get the dragging point, convert to table 
coordinates, and call -rowAtPoint:

BUT the value I get back from -rowtPoint: isn’t always the row the mouse is 
over. If the mouse is in the top or bottom third(ish) of the row, it returns 
row 0, being the top-level parent item. This matches the item I am already 
passed in my validator method, BUT IT’S NOT WHAT I WANT. This suggests to me 
that the implementation of -rowAtPoint: is being kludged during a drag and this 
is where the dragging code decides if it’s dragging between rows or on top of 
one. That’s not the right place for this determination - if, as I do, I need to 
know the real, true row the mouse is over in a drag, the apparently simple 
method -rowAtPoint: doesn’t give me a straight answer, but a bent one! When not 
in a dragging loop, -rowAtPoint: does give you the true row index.

This is bloody annoying. I means that I have to figure out another way to find 
the row the mouse is over without using -rowAtPoint: Given that this is now the 
sum of possibly varying row heights, this is not necessarily easy.

Has anyone else run into this problem? Can you confirm my suspicion that 
-rowAtPoint: is broken during row drags? Assuming I’m right, what’s the best 
way to figure out the true row containing a given point?

—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

Reply via email to