In a StackOverflow question, Thomas Tempelmann asked: How to get all TableCellView prototypes from a TableView object? […] How do I get to that TableCellView in its prototype form when I only have a reference to its TableView object, so that I can alter its tooltip for all rows added later?
NSTableView comes with a couple of default shortcuts in an override of its keyDown(with:) method. These aren’t mentioned anywhere, so Xcode’s documentation quick help will repeat the NSView docstring to you, saying: The receiver can interpret event itself, or pass it to the system input manager using interpretKeyEvents(_:). The default implementation simply passes this message to the next responder. [Emphasis mine]
Variable row heights in your NSTableView might be broken in your apps on macOS Ventura 13.0 – it’s fixed with the upcoming 13.1, but that’s only available as a beta at the moment. When you replace table contents by calling aTableView.reloadData(), this will ingest the new data as usual, but the old row heights won’t be forgotten. This can affect scrolling. The row height cache, it seems, isn’t properly invalidated or cleared.
So a client of mine recently asked how he could customize his app’s printing. The app’s main window there mostly showed tabular data, so when you’re inside the NSTableView and hit ⌘P to print, the table view will redirect its draw(_:) output to the print dialog. That’s how you get printing for free.
Nate Thompson compiled a tutorial on how to implement drag & drop in NSTableView. It’s a good read.
I remember how weird it felt to implement this the first time. Drag & drop is actually realized via the pasteboard. So it’s more like cut and paste with a visual representation. From this you get the ability to put multiple content representations into the pasteboard at once, so the drop container can decide how to handle whatever it receives.
I discovered my own idiocy and found that I overlooked which initializer of NSSplitViewItem was called. Apparently, the sidebar-related one adds vibrancy by default. Dealing with un-vibrancifying a table view might still be interesting, so I leave this up.
This is an old hat in Cocoa: when you change the appearance of NSTableRowViews, they will indeed look different – but the enclosing table view itself will still draw the system default background to fill the space below the last row. Similarly, when you have scrolling elasticity enabled and scroll above the topmost row, whatever is being drawn there won’t match your custom styled rows, either.
An NSTableView is usually embedded in a NSScrollView. If you set the columns not to span the full width, the two of them will take care of drawing an empty table header cell to the right so that the interface doesn’t look weird. But I want to have a weird interface. Because TableFlip’s tables are different than the usual NTableView use cases.
Editing NSTableView cells with a double-click is the default behavior. I wrote about how to make the column header cells editable already. But in order to figure out how to end an active editing session when the user hits ⌘S to save the document, I grew more and more disappointed by the day.
When you work with view-based NSTableViews, cells by default contain a NSTextField. You can edit cell contents with them. The headers are not designed to be edited, though. You don’t have much control over the column headings from Interface Builder. So you have to build this yourself.