Re: Wring code without interface builder
Re: Wring code without interface builder
- Subject: Re: Wring code without interface builder
- From: Chris Hanson <email@hidden>
- Date: Sun, 4 Aug 2002 21:22:22 -0500
At 9:43 PM +0200 8/4/02, Albert Russel wrote:
But you are right,
probably everything can be found in the current docs and I should make a
bigger effort looking for answers there. I do hope though that eventually
there will be more documentation available, if necessary from others than
Apple.
Read "Cocoa Programming for Mac OS X" by Aaron Hillegas, "Building
Mac OS X Applications" by Simson Garfinkel & Michael Mahoney, and
"Vermont Recipes" by Bill Cheeseman. The last one is available
freely online at Stepwise.
These will give you *much* more understanding of Cocoa programming.
I am still puzzled how events from the different controls and views
are sent to each other if you do not use InterfaceBuilder but since you say
that everything I want to know is in the current docs I will look for
answers there.
All Interface Builder is doing is creating a file that describes
objects and their properties, as well as the connections between them.
When you send +loadNibNamed:owner: to NSBundle, it loads one of these
files. It decodes all the serialized objects in the file. Then it
goes through all of the objects and sets up the connections between
them by using key-value coding[1]. Specifically, outlets are set
using a mechanism like key-value coding, while targets and actions
are set by sending controls setTarget: and setAction:.
There's no actual magic involved, just some use of the Objective-C
runtime. Once you have a better understanding of it, you can start
using these kinds of features in your own code too.
(They're especially useful if you're doing any sort of database access.)
-- Chris
[1] I don't think it actually uses key-value coding (KVC); I think it
has its own implementation that does the same thing as KVC. Apple
could probably switch to KVC and nobody would be the wiser.[2]
[2] Someone will probably be confused because I didn't explain KVC.
KVC takes advantage of the dynamic nature of Objective-C to let you
manipulate objects in a very generic fashion. You can say
[someObject takeValue:foo forKey:@"bar"];
and KVC will see if someObject responds to setBar:. If it does,
it'll just send setBar: to someObject with the argument foo. If it
doesn't, it'll see if someObject responds to _setBar:. If it
doesn't, it'll also see if someObject has an instance variable named
bar or _bar and try to set that directly.
Similarly, KVC also lets you get values from arbitrary objects in a
generic fashion by sending them valueForKey:. And it also has
support for chaining various properties together in "key paths";
saying
id foo = [someObject valueForKey:@"bar.baz"];
will use KVC to get the value of the property bar from someObject,
and then use KVC to get the property baz from *that*. Setting
properties via key paths is also supported. And, as always, there
are all sorts of hooks for developers that need to customize KVC
behavior.
--
Chris Hanson | Email: email@hidden
bDistributed.com, Inc. | Phone: +1-847-372-3955
Making Business Distributed | Fax: +1-847-589-3738
http://bdistributed.com/ | Personal Email: email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.