Can I use bindings to magically select the type of NSTableCellView that I want?
I've successfully transitioned from cell-based to view-based NSTableViews. Now I want to transition from using delegate methods to bindings.
Using delegate I implement tableView:viewForTableColumn:row in order to return one of three NSTableCellViews that I want to use (depending on the type of data). I set objectValue and the NSTableCellViews use that for displaying data.
Even now, with bindings, I can use the same delegate method to return one of the views; I simply don't set objectValue, and the I get objectValue from bindings. It works.
I switched to bindings as a learning experience, but also to get rid of this code. Maybe tableView:viewForTableColumn:row is specifically a delegate method instead of datasource method because this is still the expected way to select the correct view?
Is there a better (or rather, bindings-only) way to accomplish this?
One possible approach is to make one compound view that combines your three separate ones. You can basically embed your existing views into a tab view that doesn't show its tabs. Then, you can bind the tab view's selectedIndex or selectedIdentifier binding to a key path going through objectValue to pick which one to display.
Related
I'm trying to implement outline view in my app using NSOutlineView, but in my app the outer layer (parent) should have only one column (Brand) and inner layer (children) should have 5-6 columns (Size,Type,Image, etc.).
Is it possible to achieve, and how to do so if it is?!
Yes, you can have “full-width” cells for “group rows” in a NSOutlineView (or NSTableView).
If you’re using a cell-based outline view, implement outlineView:dataCellForTableColumn:item:
in your NSOutlineViewDelegate. Before this method is invoked with any of the existing columns, it will be invoked with a column of nil. For the corresponding rows, return a prototype NSCell, and in your other data source/delegate methods likewise return the corresponding information for a nil “column”. You just need to create a generic NSTextFieldCell for this; no need to style it yourself unless you want to. More information in the documentation or take a look at some Apple sample code.
If you’re using a view-based outline view, implement the equivalent outlineView:viewForTableColumn:item:. Unfortunately the documentation is currently pretty nonexistent, but the corresponding NSTableViewDelegate method is documented, and you can look at this code sample.
The appearance of the full-width item will vary based on the highlight style (selectionHighlightStyle) configured for your outline view; from your description, it sounds like you would want “regular” rather than “source list” behavior.
I want to implement custom search and have one trouble. I need to combine UIButton, SearchBar in one control in order I can refer it by pointer.Then i will dynamically add more UIbuttons to that combined control.And the most important I want to manipulate this combined control as one program entity. For instance,CombinedControl* control;
So what the common way to implement this? Or may be I can emulate this?Thanks in advance!
If you're looking to combine multiple controls into a single unit, the simplest thing to do is just to add them as subviews of a single UIView. You can do this either in Interface Builder (by creating a blank UIView and dropping the other controls on it) or in code (using addSubview:). Then you just have a variable that points to the UIView that you added everything to.
If you want to add behavior to the "combined control", then you should create a subclass of UIView (as H2CO3 suggested above) and add the controls to that view subclass.
I have a grouped UITableView in class A and if you select a row in section 0, I want it to open up to another UITableView. In the first view, I have a lot of other methods and buttons and custom designed stuff, so I don't want to create another XIB for the other table view since I'll have to copy over all the methods and custom designed stuff. I was thinking creating another XIB, but subclassing the class under the original class A this way I can use the methods of class A without having to redefine them again in the new class. But I'm having problems with this. Is there a better way? Can I have two table views in one XIB, and just hide one till the other is called up? But that seems a little messy..
If you simply try subclassing the existing viewcontroller it will have the same info for the selected row, hence it would have to grow exponentially in order to make display the right UITableView.
If your concern is redefining methods, then simply create a class that will hold those particular methods and include it in the UITableViewControllers that will be using them, that way you will only define it once. This way you can simply create a new UITableViewController and push it into a navigation controller everytime you select a given cell.
As an alternative of showing all options within one UITableView you can try the following: you can probably try adding a UIScrollView inside the UITableViewCell. I would make it scroll horizontally while keeping the UITableView scroll vertically.
How would I make an NSCell with more than one UI element in it and display it in an NSTableView? For NSCells with a single value I could implement tableView:objectValueForTableColumn:row: but I don't know how to do this for NSCells with more than one. At the moment I have an NSView in an NSCollectionView and all the elements are bound to an NSArrayController. But I'd rather have an NSTableView or similar.
I've switched to JAListView for table and outline views in my Mac apps: https://github.com/joshaber/JAListView
It has the advantage of using NSViews for table items instead of NSCells, allowing for greater freedom in implementing your design.
There's a few other alternatives out there too trying to solve similar gaps in NSTableView and its subclasses:
http://groups.google.com/group/cocoa-unbound/browse_thread/thread/87b2a1b5725eac05
You return the primary value in the tableView:objectValueForTableColumn:row: method, and then set up the cell further in tableView:willDisplayCell:forTableColumn:row:.
Either that, or you create a custom NSCell subclass that can customize itself based on the objectValue that you give it.
I've got an NSTableView that displays (via bindings) data from an NSTreeController. The application frequently appends/changes data to/in the bound array.
The problem is that if the user has selected a row in the table, but has scrolled so that the selected data is no longer visible, when the application updates the array it causes the display to auto-scroll so that the selected line is once again on screen. This is pretty
frustrating to users, especially since new data can arrive at any time.
Is there any way of disabling this feature?
You may have to subclass NSTableView and override -scrollRowToVisible:, temporarily bracketing the call to super. This may also require a custom BOOL ivar in your subclass to keep track of whether you want to scroll.
I would start by setting a breakpoint there to see when exactly the autoscroll is triggered. This should help to find the proper moments to toggle the ivar.
Are you using an NSTreeController with an NSOutlineView or an NSArrayController with an NSTableView? Using an NSTreeController with an NSTableView doesn't make a lot of sense to me?
If you're using an NSTableView you should probably be using an NSArrayController to manage its data and this rearranging of the rows is a feature of the NSArrayController. Try turning off the Auto Rearrange Content option on your controller within IB.
When it's on, the array controller will rearrange its objects on addition, removal and changes to objects that would affect the sort ordering (if any) and cause any table views or outline views to reload their data.
I don't know of a similar feature for NSTreeController mainly because I don't use it since it's never worked well for me. I, sadly, recommend to just use the datasource methods for the NSOutlineView and supply your data the old-fashioned way. In my experience, NSTreeController is only well suited for the most trivial tasks.