Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

mdeh

macrumors 6502
Original poster
Jan 3, 2009
345
2
May I ask 2 simple questions please ( it's gone up! :) ...well, I am sure it is simple for the gurus :)
I have set up the simple to-do list, which is working as expected.
(Basically, an NSTextField, an "add" button and a tableview.
Some very basic connections ie tableView has it's datasource in class AppController, which implements the NSTableDataSource Protocol.) But, the puzzle for me is that even though I have implemented **no** delegate methods for tableview, the app will **only** work as expected if the delegate outlet of tableview is connected to the AppController.
I am sure there is an easy explanation, but it has evaded my search so far. The documentation probably has the answer, but it is not there for me to see, so far.

2nd question.
In order to edit each cell of the table-view, I have implemented
Code:
- (void)tableView:(NSTableView *)aTableView setObjectValue:(id)anObject forTableColumn:(NSTableColumn *)aTableColumn row:(NSInteger)rowIndex
and use this to update an array which holds the data. This seems to work. What is not obvious to me is **when** and **what** triggers this method to be called. Any insight will be most welcome.


update: Well, I think I must have had something awry, as I now **can** implement the nstableview and **not** set the delegate outlet of the tableview. Make sense?

Thank you in advance.
 

eddietr

macrumors 6502a
Oct 29, 2006
807
0
Virginia
So I see no one has responded to this one yet.

So on the delegate issue, what do you mean by "works as expected"? (I'm not sure what your expectation is/was)

Basically, the framework objects are not going to crash if you don't give them delegates, data sources, etc. But generally speaking, things like table views won't do anything very useful without data.

Maybe I'm not understanding the question?
 

mdeh

macrumors 6502
Original poster
Jan 3, 2009
345
2
Maybe I'm not understanding the question?

Most probably because I am not exactly sure if I am asking it correctly.:)




So on the delegate issue, what do you mean by "works as expected"? (I'm not sure what your expectation is/was)

I had expected the list **not** to update etc **unless** the delegate outlet of the tableview was *also* connected, but it turns out, that all the work of manipulating the data *in* the table seems to be done **only** through the datasource outlet and implementation of the NSTableDataSource Protocol.

Basically, the framework objects are not going to crash if you don't give them delegates, data sources, etc. But generally speaking, things like table views won't do anything very useful without data.
I guess I am simple not utilizing the delegate methods of tableview with this very simple implementation of the exercise.

But, I am still curious as to **when** or **why** the implementation of this particular method of the protocol is called. (ie)
Code:
Code:
- (void)tableView:(NSTableView *)aTableView setObjectValue:(id)anObject forTableColumn:(NSTableColumn *)aTableColumn row:(NSInteger)rowIndex

Firstly, may I just clarify that this method is called when an object **in the table** has been changed/edited and allows the programmer the opportunity to update the datasource, (in this case using the method)
Code:
[array replaceObjectAtIndex:rowIndex withObject:anObject];
It's almost as if tableview **knows** that it must update it's datasource and thus invokes this method. And, as a small side-note. The argument *aTableView* is not used by me. Is this simply because this is a very simple example and this argument will one day be useful to me, or there is something going on in the background that requires this argument to be passed and **is** used by the system, but not visible to me.
thanks for replying, eddie, appreciated.
 

eddietr

macrumors 6502a
Oct 29, 2006
807
0
Virginia
I had expected the list **not** to update etc **unless** the delegate outlet of the tableview was *also* connected, but it turns out, that all the work of manipulating the data *in* the table seems to be done **only** through the datasource outlet and implementation of the NSTableDataSource Protocol.

Yeah, so the delegate methods and the data source methods are two different sets. And you don't have to have a delegate in order to have a data source.

I guess I am simple not utilizing the delegate methods of tableview with this very simple implementation of the exercise.

Right.

Firstly, may I just clarify that this method is called when an object **in the table** has been changed/edited and allows the programmer the opportunity to update the datasource, (in this case using the method)
Code:
[array replaceObjectAtIndex:rowIndex withObject:anObject];
It's almost as if tableview **knows** that it must update it's datasource and thus invokes this method.

Yep, that's right. NSTableView is written such that it calls this method when the user changes a cell.

Is this simply because this is a very simple example and this argument will one day be useful to me, or there is something going on in the background that requires this argument to be passed and **is** used by the system, but not visible to me.

Yeah, so your datasource (and/or delegate) may be a datasource (and/or delegate) to more than one NSTableView. So that parameter is there in case you need to know which tableview was just changed.

It's just like the sender parameter that you get from a control (say NSButton). If you have just one control that can call that particular method, then you generally ignore the 'sender'. But if you have more than one button (or menu item or whatever), then you might want to know the sender.

Hope that helps.
 

mdeh

macrumors 6502
Original poster
Jan 3, 2009
345
2
Yeah, so your datasource (and/or delegate) may be a datasource (and/or delegate) to more than one NSTableView. So that parameter is there in case you need to know which tableview was just changed.

It's just like the sender parameter that you get from a control (say NSButton). If you have just one control that can call that particular method, then you generally ignore the 'sender'. But if you have more than one button (or menu item or whatever), then you might want to know the sender.

Hope that helps.


Yes it does....thank you so much.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.