RE: Object from TableView cell
RE: Object from TableView cell
- Subject: RE: Object from TableView cell
- From: "Jonathan E. Jackel" <email@hidden>
- Date: Fri, 14 Jun 2002 11:58:28 -0400
>
The ideea is that I have popUpButtons in the table (the menus of these
>
buttons should be populated throught DoCreateMenu:), but I also have
>
popUpButtons elswere and these buttons have no need for DoCreateMenu:.
>
>
What I don't know is how to get the name of the object cell,
>
because the
>
cell is situated in a table and I do not have an instance of the cells.
>
You could check the tag (see NSCell, which is the
super-super-super-superclass of NSPopUpButtonCell) of the cell object
returned in the notification. That's probably a cleaner solution than
subclassing and testing for the class name.
>
>> and I was trying to avoid this. Also, using nil as object:
>
argument is an
>
>> example of bad programming.
>
>
> Why? I'm under the impression that passing nil as the object
>
argument is the
>
> defined mechanism for indicating that you want these
>
notifications regardless
>
> of
>
> the originating instance. I'm at a loss to understand how using
>
something in
>
> the
>
> way it's documented is "bad programming."
>
>
I never said anything about documentation. I should say "not good
>
programming style" instead of "bad programming".
>
If you put nill, there is an extra call for all
>
NSPopUpButtonCellWillPopUpNotification selector methods and if you have a
>
big, I mean really big application, the speed will be affected.
This rationale doesn't sound right to me. Given that the user can only
click in one place at a time, at most there will be one notification at a
time. It is blazingly fast for the cell to send the notification and for
the observer to test for whether the object is one it cares about. I don't
think a normal user could perceive a delay.
I agree that if you have the same notification from two different classes of
objects, you should take advantage of the object: argument in the
registration. But creating a virtually empty subclass just to make a
distinction in the notification handler is also ugly. So take your pick.
Jonathan
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.