Re: reordering table cells with 10.5 sdk
Re: reordering table cells with 10.5 sdk
- Subject: Re: reordering table cells with 10.5 sdk
- From: Corbin Dunn <email@hidden>
- Date: Wed, 31 Oct 2007 11:34:21 -0700
Yes, definitely; if mmalc hasn't already logged a documentation bug,
I'll do so.
Having this new hit test method allows us to do cool things in
NSTableView. For instance, it doesn't make sense to start a drag from
a button, and now we can differentiate cells that want to track the
mouse vs. ones that don't.
What was your NSCell subclass's superclass? If it was NSTextFieldCell,
things may have a worked better. NSCell itself is more generic.
-corbin
On Oct 31, 2007, at 10:21 AM, Mitchell Livingston wrote:
Thank you! Overriding hitTestForEvent:inRect:ofView did the trick
for me. The example linked with 10.5 sdk did work, so things were
getting really frustrating. Apple should probably document this in
the table dragging programming guide.
Thanks again,
Mitch
On Wednesday, October 31, 2007, at 01:07PM, "Corbin Dunn" <email@hidden
> wrote:
Have you tried mmalc's suggestion? Does his demo app work for you
when
targeting 10.5?
When linking against 10.5, we need you to do more things in custom
NSCell's to help provide a better experience with NSTableView. From
the AppKit release notes:
http://developer.apple.com/releasenotes/Cocoa/AppKit.html
NSTableView/NSOutlineView - Cell Hit Testing, Drag and Drop, and
Cell EditingNSTableView now uses the new NSCell hit testing API to
perform certain actions. Custom NSCell subclasses in applications
that link on or after Leopard should properly implement -
hitTestForEvent:inRect:ofView:; see NSCell.h for more information.
NSTableView performs hit testing in the cells to do the following
actions:
- Drag and Drop: NSTableView calls hitTestForEvent:inRect:ofView in
canDragRowsWithIndexes:atPoint. If the hit cell returns
NSCellHitTrackableArea, the particular row will be tracked instead
of dragged.
- Cell Editing: When NSTableView recieves a mouse down, single-click
editing of text (like Finder) will happen if there is only one row
selected, and the cell returns NSCellHitEditableTextArea.
See the DragNDropOutlineView demo application for an example of how
to properly implement the NSCell methods.
So, you probably have a custom cell, and need to not return
NSCellHitTrackableArea. See NSCell.h for more information.
More than likely, this is your problem.
corbin
On Oct 31, 2007, at 9:49 AM, Mitchell Livingston wrote:
I implement all the datasource methods, register for the drag types,
and commented out the custom tableview's mouseUp/Down methods, but
still nothing when compiled for 10.5. writeRowsWithIndexes:... isn't
being called. Any other info I could give that could be helpful?
Thanks,
Mitch
On Oct 30, 2007, at 9:35 PM, mmalc crawford wrote:
On Oct 30, 2007, at 6:00 PM, Mitchell Livingston wrote:
I have set my project to use the 10.5 sdk, and now the rows cannot
be reordered. If I set it to 10.4 sdk they can be again. It
appears that - (BOOL)tableView:(NSTableView *)aTableView
writeRowsWithIndexes:(NSIndexSet *)rowIndexes toPasteboard:
(NSPasteboard*)pboard is not being called with the 10.5 sdk.
Should I be using something else instead, or could anything else
be wrong?
There's probably some other problem. See <http://homepage.mac.com/mmalc/CocoaExamples/Bookmarks.zip
for an example that works correctly on 10.4 and 10.5 (currently
comment out the NSIndexSet category for 10.5).
mmalc
_______________________________________________
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