On Apr 27, 2009, at 6:44 AM, Michael Ash wrote:
The correct approach here is to define a property, or a set of
properties, on your table view subclass to control its appearance,
then set up those properties in your controller in awakeFromNib.
It is entirely baffling to me that people are so reluctant to follow
this approach.
The tag approach offers only one advantage: the ability to set the
value in IB. And this is an extremely limited advantage when the
information available in IB is "3". Give me descriptive code over a
"3" any day of the week.
Meanwhile it offers enormous disadvantages, including but not limited
to extremely opaque code, lack of extensibility, and just general code
smell.
Define properties for your visual differences, set them up in your
controller, and be happy.
Mike
With all due respect, I think people have blown the tags solution out
of proportion, out of a misunderstanding of the OP's needs. The OP
simply wanted to be able to tell which instance of his subclass of
NSTableView he was dealing with at any given moment. I suggested the
tags solution as a means to do so, which I still maintain is a simple
and effective solution.
I forget now who it was, but someone interpreted the tags solution as
if I was suggesting to overload the tag property as a container for
other properties. Then, other people built upon that idea by
suggesting to use the tag as a bit field (which baffled Mike above,
and me as well).
In the spirit of giving the OP the best advice possible, I suggest we
all take a step back and look once more at his original needs. Here's
a quote from the OP's original message:
On Apr 25, 2009, at 6:47 PM, David Scheidt wrote:
I've got a sub-class of NSTableView. I have windows that have more
than one instance of this TableView in them, which need to behave
slightly differently, based on which one they are.
The way I understood his question, this is a problem of *identifying*
instances. At some point or points in his code, he's got a pointer to
an instance of his subclass of NSTableView and needs to be able to
determine which of several instances that is. I still maintain that if
these instances have different tag values then
switch ([table tag])
{
case kTable1Tag:
/* table points to table1, so do what needs to be done to table1 */
break;
case kTable2Tag:
/* table points to table2, so do what needs to be done to table2 */
break;
etc.
}
is a simple, effective, and scalable way to solve his problem. Note
that there is only one table view pointer, table, not several, though
there are several instances that pointer could be pointing to (ie,
this part of the code is in some class that does not have pointers
pointing specifically to table1, table2, etc). Otherwise, simple
pointer comparison would have solved his problem and he wouldn't have
posted the question in the first place.
Note also that nowhere am I suggesting that the tags should be used
for anything other than as object identifiers. In particular, I am not
addressing, nor am I concerned with, which attributes his subclass
needs to have in order for his subclass instances to "behave slightly
differently." It seems obvious to me that the best way to handle those
attributes is to define them as properties in his NSTableView
subclass, and NOT as some contrived mapping of sets of bits from the
instances' tags (as others have suggested).
As I pointed out before, there are often many ways to solve a
particular programming problem, but I do think this is the simplest
way to address the OP's problem. If I misunderstood his question or if
there are better solutions to his problem, by all means, please weigh
in.
Wagner
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
