Trying to understand weird NSOutlineVew behaviour
Trying to understand weird NSOutlineVew behaviour
- Subject: Trying to understand weird NSOutlineVew behaviour
- From: Graham Cox <email@hidden>
- Date: Thu, 17 Mar 2016 14:53:37 +1100
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 (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