I'm trying to use an NSTableView inside an NSTableViewCell and have problems disabling scrolling. The outer tableview visualises a list of objects - in my case a 3D material definition - and inside each cell I use (among other controls) another tableview to represent the properties of the material (which is a dynamic list that can change in size).
material A
property 1
property 2
property 3
material B
property 1
material C
...
This works fine except for one thing:
Both tableview's use dynamic row height and this causes the outer table view cell to collapse the inner tableview to a 0px height. Is there a way to disable scrolling for the inner table view and cause it to use enough height to show all elements? What makes it even more complicated is that the properties map to different cell definitions (based on the type of property) and all those cells are setup in Interface Builder. So using an NSView and setting its type to NSTableView to avoid the NSScrollView or doing a programmatic construction of all the controls is not really an option.
Any tips are highly appreciated!
Update: Using TableViews
You can also use NSTableView for what you want do achieve. Unlike UITableView, NSTableView does not do the scrolling itself. It is wrapped inside an NSClipView, which itself is wrapped in an NSScrollView. So you simply extract the tableView out of that and add some constraints.
Interface builder does not support that currently very well. You can't drag the tableView out of its enclosing clipView. But you can open the interface file as source code and remove everything beginning from the scrollView (except the table itself).
The tableView should display fine in the Interface Builder (tested on Xcode 9 and 10)
You have to add the constraints in code, but then the tableView should grow by itself.
Since the inner table view does not have to scroll, you can use just NSStackView to layout your views. Then you don’t have to fight the behaviors of NSTableView.
If you need an example, feel free to ask!
Related
I am puzzled and could swear I set my NSSplitView holding priorities in IB some days ago, but now they don't seem to be visible in IB at all. Does anyone else see holding priorities in the top left of Xcode's IB when the splitView is selected ?
Does your split view have subviews? I can reproduce what you're seeing if I delete all subviews from a split view. That section shows one slider for each subview.
Update:
You are using the new NSSplitViewController and NSSplitViewItem classes introduced with Yosemite. Because of that, your split view does not, in fact, have subviews in the NIB. (There's no triangle toggle to disclose subviews under the split view.) The split view items will provide views on demand via their view controllers.
The holding priority is a property of the split view item. I can't verify at the moment, but I expect that Xcode will provide a means to set it if you select the individual items.
I'm basically asking how do you correctly add a Combo Box to a Table View with correct layout i.e. so that appears as if you were adding a ComboBox cell to a cell-based Table View. Currently when I add it to the Table Cell View it doesn't fit (bottom half chopped off) and doesn't behave as its supposed i.e. focus ring is messed up, arrows messed up, not aligned correctly.
I have searched the net couple of times over and funny enough I haven't found an answer to this question. If I don't find a solution I might have return to good old cell-based table views.
If the combo box doesn't fit, you need to increase the height of the NSTableCellView. This is done in Interface Builder or, if implemented, in the NSTableViewDelegate method tableView:heightOfRow:.
I'm using Xcode 6 beta 5 at the moment, eager to try out the cool self-sizing collection view cells functionality introduced in iOS 8. It was introduced in the WWDC 2014 session 226: "What's New In Table Views and Collection Views". Links:
https://developer.apple.com/videos/wwdc/2014/
http://asciiwwdc.com/2014/sessions/226
http://blog.indragie.com/
All you gotta do, they said, is that you have to set auto-layout constraints on the contentView of your collection view cell or implement sizeThatFits:. The former sounds easier, so I definitely want to use auto-layout.
When got into Storyboard editor (or IB) though, it appears that you you cannot access the contentView property of a prototype collection view cell. Is this true?
I did set a few constraints between a label (direct subview of the prototype cell) — I pinned its four edges to the cell's bounds itself, hoping that the label's intrinsicSize would provide the needed width for the cell. No avail: I verified that none of these pinning constraints were applied onto the contentView:
- (void)awakeFromNib
NSLog(#"%s... contentView.constrants == %#", sel_getName(_cmd), self.contentView.constraints);
}
... prints out...
awakeFromNib... contentView.constrants == (
)
... no matter what constraints I set in Storyboard.
Am I missing something or must I do this auto-layout in code?
I have an NSCollectionView that I want to accept items dragged from elsewhere in my application.
I implement collectionView:validateDrop:proposedIndex:dropOperation: and collectionView:acceptDrop:index:dropOperation: in the collectionview's delegate and register for the appropriate dragged types. Both methods get called fine when I drag the appropriate types, but I don't get a blue focus ring over the collectionview indicating a valid drag.
Have tried both the collection view and its containing scroll view on Default and External settings for the focus ring. Both are just the standard non-derived Cocoa classes. Wondered if there was anything else I should try. Surely it isn't necessary to subclass NSCollectionView for this?
Thanks
Chris
Focus rings are not typically the correct way to provide feedback about drag destinations. Every view does it slightly differently. NSTextView shows the insertion bar. NSTableView shows a blue line in between rows for Before drop operations, and shows a bezel around the row for On drop operations. (See NSTableViewDropOperation)
NSCollectionView shows a "gap" between existing subviews to show where the items will be dropped for Before drop operations, and it will set the selected property on NSCollectionViewItem to YES for On drop operations. (Note: NSCollectionViewItem doesn't do anything by default to visibly represent the selected property. You must implement that yourself.)
Since NSCollectionView's feedback uses existing subviews only, it appears there isn't any feedback at all for empty NSCollectionView's. You would need to subclass to provide this behavior yourself. You could also file a bug to request that NSCollectionView do this itself.
I am learning Cocoa and trying to create an application for Mac that displays a simple book list. Each book is an NSView with its cover image, title and author. I want to present this list as a NSTableView with a single column and a book view in each cell. However i can't yet figure out how to display a custom view inside a table cell in interface builder or programmatically. Any tips would be very appreciated :)
Inso.
If all of your "book views" are the same size, why not use NSCollectionView / NSCollectionViewItem? It's a much cleaner solution (provided they're all sized the same).
Assuming a collection view wouldn't be a better solution, what you need to do is to write a custom cell. The column owns exactly one such cell, which the table view will use to draw the column's value for each row.
(If you came from the iPhone, yes, this is completely different from UITableView. Each NSTableColumn has exactly one cell, which it uses for every row.)
If you're using your NSView class somewhere else, then you could make it into a subclass of NSControl and have it use another instance of the same cell class. Like most controls, all the real work would be done by the cell, which enables you to reuse that behavior in multiple controls (your single control and your table view).
See Control and Cell Programming Topics for more info.
Apple added view-based table views in Lion, so you should be able do this natively with NSTableView, now.
(You still can't put an NSView in an NSCell—that wouldn't make sense. But you can have views instead of cells in a table view.)