Copy NSTableView row vs Bindings
Copy NSTableView row vs Bindings
- Subject: Copy NSTableView row vs Bindings
- From: glenn andreas <email@hidden>
- Date: Wed, 22 Mar 2006 09:19:30 -0600
So I've got some NSTableViews that display information via bindings,
and I'd like to be able to select a row in the table and copy the
information to the clipboard - seems simple enough.
I could add a "copy:" method to the document which checks to see
which table is currently the first responder, figure out which array
of information is displayed in that table, and get the info to copy
to the clipboard based on that, but having a big "if..else if" chain
to determine what to copy just seems wrong (not to mention that it
hard codes all this logic, and I'd like to later add another table
without having to revisit this code, and worse, these tables may be
dynamically loaded at runtime).
So I figured I'd just subclass the NSTableView to support "copy:" -
since these tables all display the same sort of thing, I could ask my
dataSource for value for the selected row for a given column (which
would give me the textual representation I want to put on the
clipboard). Except that with bindings, dataSource is NULL (as is
delegate). If I could find out the NSArrayController associated with
this table view, I could ask it for the item for the given row,
except there is no documented method to obtain that.
I could also subclass NSArrayController to add "copy" support, except
that it isn't an NSResponder so doesn't get copy: messages sent to it.
I could also add an ivar to my NSTableView subclass to point to the
NSArrayController and hook up everything in IB, but this seems
suboptimal (after all, the NSTableView somehow can get all the data
it needs to display the contents, why can't a subclass get ahold of
it as well?)
So what am I overlooking?
Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
quadrium | build, mutate, evolve | images, textures, backgrounds, art
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden