6/17/08 11:16 AM, also sprach [EMAIL PROTECTED]: > 0) my app has an AppController object that is instantiated in the > main Nib > 1) on the main Nib's window is an NSTextField that is connected (via > Nib loading) to an outlet of the AppController (named "valueTextField") > 2) my app has a Person class with a single property "age" which is > KVC compliant (also: the underlying age ivar is initialized to 0 in > Person's -init) > 3) the Person class has an -increaseAge instance method (which uses > the accessors to get then set the age, so it is KVO compliant) > 4) the AppController instantiates a single person object (in its init > method) and holds on to this with an ivar > 5) also on the main window is an NSButton that is connected to an > action handler in the AppController -- which in turn invokes [person > increaseAge]; > 6) in the AppController's awakeFromNib, I bind the person object's > age property (key?) to the NSTextField thusly: > [valueTextField bind:@"value" > toObject:person > withKeyPath:@"age" > options:nil]; > The app works -- when I press the button, the displayed age > increases. Wonderful... but here's my questions: > > (btw: context: Tiger 10.4.11 using Xcode 2.4.1) > > 1) from what (or where) does the property "value" of the NSTextField > arise? Neither the class reference for NSTextField or NSControl have > such an instance method (at least not that I've yet found).
It doesn't have to be a "real" property or ivar, nor does it need to have public accessors. Why NSTextField doesn't have accessors for the keypath, is up to Apple. In your own code, you would probably have public accessors. Bottom line is that according to OOP rules, how NSTextField handles the "value" keypath is none of your business; better known as "encapsulation". It is also not relevant to a thorough understanding of bindings. > 2) I used "value" for the binding because that is how I saw some > sample code. Given that I don't quite know what "value" is, I changed > to bind to "intValue" (presuming that setIntValue would be invoked on > the textField). This works, but changed the behavior of the app in > one small way: This is probably bad idea, and is really getting away from the core of bindings. Just because you can, doesn't mean you should. > In the Nib, the valueTextField has a string value "hello" in place > because I wanted to see if the initial value of the Person's object > would be displayed when the binding is established. When I bind to > "value" the textField is immediately set to 0 (that is, I never see > the word "hello"), but NOT when I bind to "intValue" the textField > shows "hello" until I click the button to increase the age property > -- why the difference? Because your binding is probably broken. This is not a proper binding set up. Don't do it. If the binding is proper, the field will always display the current value of the "bind-to" property (i.e. "age"). Or, more precisely, the last retrieved value. > 3) Then I got curious about what ensures compliance of data types, > and wondered if II'd cause runtime errors if I passed the wrong data > type, so I tried changing the bind invocation to bind to > "stringValue" -- that worked just fine. As did binding to > "floatValue". I'm presuming something must be coercing the person > object's age (which is int data) but what? Is this an artifact of the > control, the textField, or the binding mechanism? The "coercion", if you want to look at it that way, is a function of KVC (Key Value Coding). This is evident in the docs. Understanding KVC is essential to understanding bindings. Many of the question you are asking here imply a weak understanding of KVC. > 4) Further, using "floatValue" does not cause the initial value of > age (0) to be displayed (same result as with intValue), but using > stringValue does (which matches use of "value"). Why? See above. HTH, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" _______________________________________________ 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 [EMAIL PROTECTED]
