NSControl is hardly a distant superclass. It's the immediate
superclass of NSTableView. Also, why do something more complicated
when there's an easy, built-in, and fully supported solution already
in place, namely, tags?
If it's not obvious or expected, it's only because not enough people
read the superclass documentation when they're looking for information
on a class and, thus, don't make use of what's already built-in and
supported. Besides, if expectations are the main issue, that's nothing
that some in-code comments wouldn't solve.
More importantly, perhaps, is the fact that adding property/ivars is
not a scalable solution in that it requires adding more code in
several places if more tables are added. The tags solution only
requires some fiddling with IB and updating a switch statement. That
sounds to me a much simpler maintenance problem than having to update
code in several places.
On the other hand, there's no single solution to most problems in this
business. If you don't like the tags solution, feel free to do it
differently.
Wagner
On Apr 27, 2009, at 12:36 AM, Jonathan Hess wrote:
Why not have a property/instance-variable that controls this
directly and then set that in awakeFromNib from one of the
controller classes that has an outlet to each of the table views?
If I maintained your project after you, the tag variable inherited
from a distant superclass would not be the bit of information that I
would expect to control the appearance of a table view.
Using the tag is certainly quick and easy, but probably isn't
obvious or expected.
Jon Hess
On Apr 25, 2009, at 11:54 AM, David Scheidt wrote:
On Apr 25, 2009, at 1:34 PM, WT wrote:
On Apr 25, 2009, at 7:26 PM, David Scheidt wrote:
On Apr 25, 2009, at 1:13 PM, WT wrote:
NSTableView inherits from NSControl, which has methods -tag and -
setTag. I would suggest assigning a different tag value to each
instance of your NSTableView subclass (you'd do that in your
subclass' initializer or -awakeFromNib method) and use the -tag
method to identify the instance when you need to do so.
That's perfect. Thanks!
You're welcome. It's my impression that tags are generally under-
utilized, though very useful.
Yes, certainly very useful: makes this problem a switch statement.
(And not fogetting to set them in IB, but I made tag == 0 and the
default: case different ugly colors, so I'll know that someone
forgot to set the right tag (default is zero), or set it to an
invalid value when I see them.) I've got a couple other places in
this project where they'll likely make sense to use, for much the
same reasons.
It's also possible to set the tag in IB (it's on the Attributes
Inspector palette, in the "control" tab). Since I'm not creating
any dynamically, I can do that.
It's funny... I fired up IB and created a fake app to check if it
was possible to set the tag through IB before I replied to your
first message but, in my haste, missed it so I thought you'd have
to do it in code.
Well, I'd never used them before. So I looked them up in the
NSControl class docs, which say " Tag values are not used
internally; they are only changed by external invocations of
setTag:. You typically set tag values in Interface Builder and use
them at runtime in your application", so I figured there had to be
a way to set them, and just looked until i found it.
_______________________________________________
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
