Re: Cocoa app fails when using 10.4 Universal SDK [Solved]
Re: Cocoa app fails when using 10.4 Universal SDK [Solved]
- Subject: Re: Cocoa app fails when using 10.4 Universal SDK [Solved]
- From: Ricky Sharp <email@hidden>
- Date: Sun, 12 Jun 2005 12:19:32 -0500
On Jun 12, 2005, at 11:52 AM, Ricky Sharp wrote:
On Jun 7, 2005, at 9:33 PM, Ricky Sharp wrote:
While this thread may end up being better suited for the xcode
list, I thought I'd try hear since the following issue may be
unique to Cocoa apps:
Update...
While not completely fixed yet, I believe I've found the culprit.
My 'value field' widget (subclasses of NSActionCell and NSControl)
has three attributes: minimumValue, maximumValue and currentValue.
It's the currentValue attribute that would always show up as zero
in the debugger. However, the other two attributes are a-ok.
I've noticed that currentValue is an attribute of the new
NSAnimation class in Tiger. It's my thinking that currentValue
must be some new private attribute of control or action cell. That
would sort of explain why my currentValue ivar is sometimes zero
(perhaps I'm reading/writing to Apple's one on occasion).
I'm going to change the names of the attributes, accessors and
bindings to all be unique and see what happens.
I renamed all traces of 'currentValue' to 'valueFieldCurrentValue'
and now everything works as expected. It thus appears that using
'currentValue' collided with something in Apple's frameworks that
would have been introduced with Tiger.
This explains all the strange behavior I was seeing. The debugger
apparently was showing me the value of some other 'currentValue'
which happened to be set to 0. Now, the debugger displays the
correct value of my newly named attribute.
Furthermore, bindings to that attribute once again work.
Now then, to avoid repeating this nastiness in the future, I'm
wondering if I should completely rename all my widget attributes,
binding names and accessors. Currently, only the keys used for
NSCoding are prefixed with my unique signature (e.g. IIBaseColor).
So given an attribute that used to be named baseColor, the following
would be used:
iiBaseColor // ivar
// accessors
- (NSColor*)iiBaseColor;
- (void)setIIBaseColor:(NSColor*)aColor;
@"IIBaseColor" // binding name
@"IIBaseColor" // NSCoding key name
Has anyone else ever run into collisions like this? What has been
your strategy in naming?
Note that I will not be going nuts renaming things everywhere. I'm
guessing it will be the NSView, NSControl and NSCell subclasses of
mine that may be using names that Apple may use someday.
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden