Re: figuring out which TableView I am?
Re: figuring out which TableView I am?
- Subject: Re: figuring out which TableView I am?
- From: WT <email@hidden>
- Date: Mon, 27 Apr 2009 03:27:00 +0200
On Apr 27, 2009, at 1:31 AM, Jim Correia wrote:
On Sun, Apr 26, 2009 at 7:05 PM, WT <email@hidden> wrote:
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.
I guess I'm not following your logic.
I want table 1 to have a blue background, so I set its tag to 3.
I want table 2 to also have a blue background, so I set its tag to 3.
I want table 1 to have red text. Switch off tag, 3 == red text.
I want table 2 to have green text. Oops - tag 3 already means blue
background + red text.
(Substitute any 2 actual properties for my background color + text
color - they are meant for illustration purposes only.)
Overloading tags for other properties is not scalable, because you
only have one property (the tag) which you are overloading to mean N
other properties and/or behaviors.
The only scalable solution to this problem is explicity
iVars/properties for each property/behavior you want to control in
your subclass. (Yes, this means configuring things by hand after
unarchiving your nib, or writing an IB plug-in so you can specify them
in IB.)
- Jim
If you go back to my original reply to David, you'll notice that I
suggested tags as a means of *identification*, not as a "property
container". Thus, using your example, table 1 is an instance of his
subclass of NSTableView having a blue background and red text. Table 2
is another instance of his subclass of NSTableView, also having a blue
background but having green text. Assigning to table 1 a tag of, say,
1 and to table 2 a tag of, say, 2, then a simple switch statement
allows David to find out which table he's dealing with at any
particular moment and, thus, set or read any of that table's
properties (background color, text color, and what-not).
This seems scalable enough and does not involve overloading tags to
mean anything other an object identifier.
I hope my logic is now clear enough now.
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