Re: Creating NSTableView programmatically
Re: Creating NSTableView programmatically
- Subject: Re: Creating NSTableView programmatically
- From: Quincey Morris <email@hidden>
- Date: Tue, 12 Dec 2017 11:08:23 -0800
On Dec 12, 2017, at 02:12 , Eric Matecki <email@hidden> wrote:
>
> In the case of NSTableCellView, neither binding works... I don't get any
> exception or crash, but nothing is displayed inside my table view (although
> it's size suggests the four rows are there).
This was a conceptual failure on my part, since I’ve never actually created a
NSTableCellView manually. The cell view has “imageView" and “textField”
outlets, but they’re not connected to anything by default, and the cell view
has no subviews by default. (One or both subviews is present and connected when
you do this in IB, because IB uses a preconfigured cell view hierarchy.)
If you want to use a text view, you will have to subclass NSTableCellView to
add a “textView” outlet. or you can use a text field with the existing
“textField” outlet. Either way, you’ll need to create the text-displaying
subview, and set the corresponding outlet.
> [view bind: @"value" toObject: tableView withKeyPath:
> @"objectValue.name" options: 0]; // wrong, but works
I have no idea why that works, it makes no sense whatever.
You’re still missing some stuff, BTW:
— For proper table view behavior, you really should create the cells by
invoking "makeView(withIdentifier:owner:)”, so that the table view can manage
the lifetimes and reusability of the cell views. However, this mechanism is
intended to work with a NIB for the table cell view. This can either come from
the table view’s own NIB file (via a private mechanism that IB sets up for you)
or a freestanding NIB file (which you must register with the table view
manually). Since you have neither, you will (I guess) need to let the cell
creation portion of the "makeView(withIdentifier:owner:)” API fail, when a cell
view isn’t being reused, then create your cell view manually.
Technically, you don’t have to do this, I suppose, but you said you were trying
to learn what normally goes on, and cell view caching is what normally happens.
— You didn’t embed your table view in a scroll view.
If it can’t scroll, the table view isn’t much use.
> How do you "ignore" what you don't need in an NSTableCellView ?
As I said, I was confusing two things. Most standard cells created in IB are
just text, and have no image view.
> And when I add a subview to one, how do I arrange (layout) it's content
The usual ways, which is to say: add layout constraints, or set the frame
manually if you’re not using autolayout.
> It's still weird (to me) to bind an object's binding to one of it's own
> properties.
It’s just a special case of a “derived” property. It’s not so unusual for an
object to observe one of its own properties in order to provide a KVO compliant
value for another property. Anyway, in this case, it’s conceptually binding to
a different object (the one referenced by “objectValue”) to get its “name”
property. The indirection falls out of the division between standard behavior
and custom behavior that’s built into the table view design.
> Too bad that bindings are fading away
I don’t think bindings are fading away. They can’t, while they’re the only way
to connect UI elements without custom glue code. However, the design is ancient
(IIRC, bindings were introduced in macOS 10.3, and refined in 10.4, and really
nothing has changed since then).
What has fallen away (because it never really got off the ground) was the use
of *custom* bindings, in part because no one could understand what to do, and
because they really needed the IB customization features introduced in Xcode
3.0 (or was it earlier?) and killed off in Xcode 3.1 (or thereabouts).
In modern terms, bindings are a horrible hack, and that’s why (I assume) they
were never taken over to iOS.
_______________________________________________
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