On Apr 26, 2009, at 5:19 PM, Greg Guerin wrote:
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 you needed a fully scalable solution with support for arbitrary
properties, that would be the way to go. But the OP didn't need
that. All he needed was 3 color-scheme variations of an otherwise
standard NSTableView.
http://lists.apple.com/archives/cocoa-dev/2009/Apr/msg01800.html
Even supposing the designer can't decide which colors to use for
text and background, tags can still work. Simply reserve 8-bits of
the tag for the text-color, 8-bits for the bkgd-color, and index
into a table of the web-safe colors.
http://en.wikipedia.org/wiki/Web_colors
Or index into a table of arbitrarily defined colors. You can get as
much flexibility of colors as you care to program, and there are
still 16 bits unused in the tag.
Will this provide a fully scalable solution for arbitrary
properties? No. But it doesn't need to be. Some things will never
need to scalable. When the simpler solution no longer suffices,
that's the time to create a more complex and scalable one.
I don't think anyone is really debating that the tag cannot be
successfully used. It can. I'm just questioning whether it was good
advice for someone who's most likely new to the task they're trying to
accomplish. It would be unfortunate if David left this thread with the
impression that a switch statement combined with the tag variable of
NSControl was the defacto way to extend a view classes to contain more
capabilities.
I think that when someone comes to a list looking for advice, we
should give them future looking and maintainable advice. If the future
looking advice seems over-engineered, or too complicated, alternatives
are certainly appropriate. The OP can decide if they want the quick
fix or the maintainable one. The most maintainable solution is not the
tag solution, but it certainly is a workable alternative if the OP
accepts is lack of self explanation and extensibility.
Jon Hess
-- GG
_______________________________________________
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/jhess%40apple.com
This email sent to jh...@apple.com
_______________________________________________
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
