On Dec 11, 2017, at 10:19 , Alastair Houghton <alast...@alastairs-place.net>
wrote:
>
> NSTableViewCell is the old way to do it, before view-based tables were the
> norm
In this case, I think “NSTableViewCell” is a typo in the documentation. In the
following tables, it refers to the binding target as “Table Cell View”, not
“Table View Cell”. NSCell-based tables did use cell class names with the
pattern “NS…Cell”, but NSTableViewCell wasn’t one of them AFAIK. (In iOS, of
course, the equivalent cell view is UITableViewCell, just to keep us on our
toes.)
On Dec 11, 2017, at 05:53 , Eric Matecki <eml...@wanadoo.fr> wrote:
>
> I made my own text field class according to this (in NSTableCellView's doc) :
I think you’re still kinda Doing It Wrong™. The standard (and, I believe,
recommended) way to do this is to create an instance of NSTableCellView, which
has the “objectValue” property, along with other potentially useful behaviors
for cell views (such as identifiers that allow the NSTableView to cache and
manage cell views).
In a very unusual or complex case, you might subclass NSTableCellView to add
properties or behaviors to it, but it’s normally not necessary. Custom
properties, for example, can be carried around by the object referred to by
“objectValue”, and custom behaviors can sometimes be implemented as part of the
delegate.
Instead of using a cell view other than a NSTableCellView or subclass, it’s
usual to *add subviews* for things like text fields and buttons. That separates
the behavior of the cell *as a cell* (such as being cached for the table view)
from the view hierarchy represented by the cell. However, if your cell just
needs to contain a text field, you don’t need to add one yourself, because
NSTableCellView already contains a NSTextField subview that you can just *use*.
It also contains NSImageView subview that you can use or ignore.
> Now I can see all the names :)
One reason to use a NSTableCellView instead of a control sum as a text field is
that the cell view’s size is *forced* to the dimensions required by the table
view row. That means you have no control of the placement of the contents
relative to the row. For a text field, for example, you have no direct way of
controlling the margins surrounding the text. This approach also limits the use
of autolayout, which may or may not be an issue in your project.
> - (NSView *)tableView:(NSTableView *)tableView
> viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row {
> NSTextView* view = [[NSTextView alloc] init];
> …
You say “text field” everywhere, but you actually create a text view. I don’t
get a sense of which one you really want to use, but using a separate
NSTextView for each row of the table could end badly, and subclassing
NSTextView is probably a code smell.
_______________________________________________
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
