Permanently hide rows in NSTableView / NSOutlineView

1
votes

I have some rows in my NSOutlineView that I would like to be permanently hidden (for reasons to do with my data structure).

On 10.13, using automatic row heights and auto layout, I was able to simply have no view for some rows of data, and so they were hidden to the user.

Now I am making my app available on 10.11, so I am having to manually calculate row heights. The NSOutlineViewDelegate function 'heightOfRowByItem' insists on a non-zero row height, so I can no longer have completely hidden rows in the same way.

The NSTableView 'hideRows' method would seem to be an alternative. It can hide a specific row without hiding its children (perfect in my case). The only issue is that everything seems to 'unhide' the moment I drag rows.

Does anyone know either: - How to stop rows being unhidden on drag (I can't see any documentation) - Some other approach to having invisible rows in an NSTableView/NSOutlineView.

Thank you

1
cocoanstableviewappkitnsoutlineview
An observation: When hiding a row, "didRemove rowView" is called on the NSOutlineViewDelegate, immediately followed by "didAdd rowView". The hiddenRowIndexes is then correctly set. When calling unhide, neither didAdd or didRemove is called before the hiddenIndexes are correctly set. This is not in line with the documentation - didRemove should be called on hide, didAdd should be called on unhide. When dragging, the hiddenIndexes are reset and the hidden rows animate back to height. unHide is not called. – Giles
NSTableView is a mess and the documentation is getting worse. Is it possible for the datasource to filter the data? – Willeke
That's good to keep in mind, thank you @Willeke! Unfortunately I don't think I can go down the filtering root - I am trying to show a view of a graph in the outline hierarchy, and my approach involves hiding some parents whilst still displaying the children. – Giles

1 Answers

0
votes

Make a new class to serve as our NSOutlineView item, and update those items to reflect the state of your underlying model. It may seem like more work, but it'll be far more pleasant than trying to be clever in your NSOutlineViewDataSource/Delegate methods. For me, working with NSOutlineView has been hardest when I tried to use my existing model to drive it, and easiest when I create a class to be the item.

This also has the advantage of not cluttering your model with functionality and state that pertains only to the outline view presentation.