I need to create/use a NSTableView programmatically. From the documentation, it seems that I would implement the NSTableViewDataSource protocol. But the function tableView:objectValueForTableColumn:row: suggest (because of the row index) that I would have to manually take care of the sorting. Is that right? Also, as this is called on every redisplay, that might be slow because I am using Python and it would mean a Python call for every row/column.
I wonder wether it make sense to use Cocoa binding and wether that would be more simple. In any case, I would have to do that programmatically and I am a bit stumbled about how to that. From other examples, I guess I would create a NSArrayController and bind it all together somehow.
Also, I want to have it working on older MacOSX, so I guess I have to use the cell-based NSTableView, whatever that means.
The data source will be static and is not editable, i.e. I can just provide a NSArray with the data.
There are three ways to use NSTableViews: 1) delegate methods; 2) NSArrayController; or 3) Bindings. My best advice to you is to learn all three of these in Xcode on a Cocoa ObjC project first before attempting to do this in python. Note: I'd also recommend that you first learn how to do these via nibs and then figure out how to do it programmatically (again in Xcode on a Cococa ObjC project before attempting it in python).
If you understand how Interface Builder (view in Xcode 4, app pre-Xcode4) bindings work then for the following code "Bind To" corresponds to myController, "Controller Key" would be "selection", and the Model Key Path would be "fullPath".
[myView bind: #"valuePath"
toObject: myController
withKeyPath: #"selection.fullPath"
options: nil];
You just need to sort your array once, then when the delegate method is called access the appropriate index in the array.
You really should have a good read of the Table View Programming Guide.
Related
I've been developing on iOS for some time, but am very new to Cocoa development, and something seemingly very simple is stumping me.
I have an NSTableView, hooked up to a subclass of NSWindowController as both datasource and delegate. I have an array of "File" objects (my model class) and want to populate one column of my tableview with file types, and another with timestamps.
The dataSource methods are definitely being called, as verified by setting breakpoints. In fact, I end up with an appropriate number of rows that are selectable...but none of them display anything. I even tried returning an arbitrary string literal in objectValueForTableColumn, for all rows and columns, and still nothing.
I think I'm probably stuck on how tableViews work in iOS, but obviously they are very different here...I am used to configuring and returning a cell myself, but here we just pass AnyObject??? How exactly does the tableView know how to display AnyObject? I'm really struggling with the conceptual understanding here. Appreciate any help.
Although I have searched for many information about Cocoa Bindings, I still remain relatively unsatisfied with information I have and got. It seems that topic is somewhat troublesome for many and many are just avoiding this pattern, which I believe should not be.
Of course, it may seem that bindings are sometimes too complicated or perhaps designed with too much overhead...
However, I have one very direct and specific question: Why is NSObjectController needed if I can establish bindings directly?
For example, the code:
[controller bind:#"contentObject" toObject:self withKeyPath:#"numberOfPieSlices" options:nil];
[slicesTextField bind:#"value" toObject:controller withKeyPath:#"content" options:nil];
[stepperControl bind:#"value" toObject:controller withKeyPath:#"content" options:nil];
Does exactly the same as:
[slicesTextField bind:#"value" toObject:self withKeyPath:#"numberOfPieSlices" options:nil];
[stepperControl bind:#"value" toObject:self withKeyPath:#"numberOfPieSlices" options:nil];
In my case here, we are talking about property of the class inside which everything is happening, so I am guessing the need for NSObjectController is when:
key path for controller is object and binding of other controls is needed to its properties, not to its value as with primitives and wrappers around them is the case (numberOfPiesSlices in my case is NSInteger)
or when binding is needed from other outside objects, not only between objects within one
Can anybody confirm or reject this?
One of the benefits/points of bindings is to eliminate code. To that end, NSObjectController etc. have the benefit that they can be used directly in interface builder and set up with bindings to various UI elements.
Bindings only represent part of the functionality on offer. The *ObjectController classes can also automatically take care of a lot of the other more repetitive controller (as in Model, View, Controller) code that an application usually needs. For example they can:
connect to your core data store and perform the necessary fetches, inserts and deletes
manage the undo / redo stack
Pick up edited but not committed changes to your UI and save them (e.g. if a window is closed while focus is still on an edited text field - this was a new one to me, I found it from mmalc's answer in the thread below).
If you're doing none of this, then it probably isn't worth using NSObjectController. Its subclasses (NSArrayController etc) are more useful.
Also see here for a discussion of your exact question!
Why is NSObjectController needed if I can establish bindings directly?
I read this question a few days ago while looking for some information about NSObjectController, and today while continuing my search, I found the following passage which seemed relevant to the question:
There are benefits if the object being bound to implements
NSEditorRegistration. This is one reason why it’s a good idea to bind
to controller objects rather than binding directly to the model.
NSEditorRegistration lets the binding tell the controller that its
content is in the process of being edited. The controller keeps track
of which views are currently editing the controller’s content. If the
user closes the window, for example, every controller associated with
that window can tell all such views to immediately commit their
pending edits, and thus the user will not lose any data. Apple supply some generic controller objects (NSObjectController,
NSArrayController, NSTreeController) that can be used to wrap your
model objects, providing the editor registration functionality.
Using
a controller also has the advantage that the bindings system isn’t
directly observing your model object — so if you replace your model
object with a new one (such as in a detail view where the user has
changed the record that is being inspected), you can just replace the
model object inside the controller, KVO notices and the binding
updates.
I am creating a Cocoa application wherein one view will contain the "hex dump" of the currently loaded document. Up until this point, I have been using a bog-standard (and very unappealing) NSTextField, but I am now looking for something more powerful.
I am a great fan of 0xED.app and would love to replicate its main "hex dump" view. How would I go about doing this?
I'm not necessarily after the eye-candy, but the ability to select a range of bytes without also selecting the offset or text columns. I am a loss as to where I would even begin to implement this effectively. Surely this is not drawn upon a blank canvas?
To get started and see how things basically work:
Subclass NSView.
Add an instance variable to hold your NSData.
Override drawRect:
Iterate your NSData
Use methods from NSString drawing AppKit additions to draw the bytes.
This approach will be slow for a large amount of data, but will give you a good handle on implementing a NSView subclass. After that, you'll want to improve the drawing performance by implementing something better than repeated calls to draw strings one at a time. You'll also want to implement overrides of methods like mouseDown: and keyDown: to handle input from the user to allow things like selecting a range of bytes.
That should get you started, once you have that going, I'd suggest asking follow up questions.
My guess is that it's probably accomplished using a NSTableView or subclass of it.
It might be a little tricky to get the correct text selection accomplished this way, but it's probably possible.
If you want to take a look at how a Cocoa interface is built you can use NibToXibConverter.
Download 0xED, right click on 0xED.app and select "Show Package Contents". Extract the Contents/Resources/English.lproj folder.
Run NibToXibConverter, browse to the folder extracted above, and put a tick next to "Decompile NIBs".
Select the "Convert" button and it will convert the NIBs to XIBs
Double click a XIB to open it in XCode and you can see how they are constructed
You will note that in the case of 0xED he is using a custom class (most likely a subclass of UIView with custom drawing as Jon Hess suggests).
I have an NSTableView with a single column, which gets its data through an NSArrayController bound to a Core Data entity. The data feed works great, and I have been able to get drag and drop working by implementing the methods
– numberOfRowsInTableView:
– tableView:objectValueForTableColumn:row:
as well as the specific drag and drop methods
– tableView:acceptDrop:row:dropOperation:
– tableView:writeRowsWithIndexes:toPasteboard:
But do I really have to implement the first two methods even though the tableview is fed data through the array controller? I tried commenting out my implementations, but then I get errors in the console saying "Illegal NSTableView data source". The documentation for the NSTableViewDataSource protocol says that the methods are optional if the application is using Cocoa bindings, so obviously, I'm doing something wrong.
The question: How do I make the tableview use its existing binding and still support drag and drop?
I believe you do need to implement them to silence the complaint. I believe when used with Bindings the values returned by these data source methods are ignored. So for -numberOfRowsInTableView: you can return zero; for -tableView:objectValueForTableColumn:row: you can return nil.
You do not need to implement these methods. It seems pretty shaky, but I silenced them by re-establishing the datasource connection in Interface Builder. I think perhaps if you add the datasource after you add bindings, it silences the warning.
What is considered the best way of handling multiple NSTableViews without using Cocoa Bindings?
In my app, I have two NSTableViews that are sufficiently closely related that I'm using the same object as the delegate and dataSource for both. The problem is both tableViews invoke the same methods. I currently discriminate between the two tableViews on the basis of NSControl -tag.
The deeper I get into this code, the uglier the use of -tag looks. I end up creating largely duplicate code to distinguish between the tableViews in each delegate/dataSource method. The code ends up being distinctly non-object oriented.
I could create a separate object to handle one or the other tableView, but the creation of said object would be a largely artificial construct just to provide a distinct delegate/dataSource.
Is everyone just using Cocoa Bindings now? I'm avoiding Bindings as I would like to hone my Cocoa skills on techniques that are transferrable between Mac OS and iPhone.
Every delegate/dataSource method for NSTableView passes the instance of NSTableView that's calling it as the first parameter (except for the ones that pass NSNotification objects, in which case the NSNotification's object is the table view instance). Some examples include:
- (int)numberOfRowsForTableView:(NSTableView*)aTableView;
- (id)tableView:(NSTableView *)aTableView objectValueForTableColumn:(NSTableColumn*)aTableColumn row:(NSInteger)rowIndex
- (void)tableViewSelectionDidChange:(NSNotification *)aNotification
If you're using one controller object as a delegate/data source for multiple tables, you can just use that parameter to differentiate between them.
for the method :
- (void)tableViewSelectionDidChange:(NSNotification *)aNotification
you can use :
NSTableView *theTable = (NSTableView *)[aNotification object];
if(theTable==listeDesMots)
...
It sounds like you should be using a different delegate object for each view, but the same data source. In other words a single model for distinct view and controller objects.
I don't think this is an artificial distinction because the objects have sufficiently different purposes, but you want to use the same data. The bigger rule you are violating now is that each object should have a single purpose. Each objects' purpose could be to retreive and display the data in a specific way.
Good Luck!