Re: figuring out which TableView I am?
Re: figuring out which TableView I am?
- Subject: Re: figuring out which TableView I am?
- From: Jonathan Hess <email@hidden>
- Date: Mon, 27 Apr 2009 04:19:07 -0700
On Apr 27, 2009, at 2:10 AM, WT wrote:
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.
Hey Wagner -
That cleared things up and sounds much more reasonable.
To take this a step further, if you're going to take the time to
define constants like kTable1Tag, and then use them in IB, why not
just use an outlet instead? It takes the same amount of typing, but is
much more difficult to inadvertently break while at the same time,
self document. If you really want to identify an object by its
identity there's no better way than a pointer, and that's what you get
with an outlet.
Tags certainly have their place. An example of where they can be used
successfully and clearly is to hold integer constant values for menu
items in a pop up button's menu where the pop up menu is used to
manipulate an attribute, and the menu items' tags hold the legal values.
Jon Hess
Wagner
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden