On Dec 12, 2017, at 02:12 , Eric Matecki <eml...@wanadoo.fr> 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 (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
