Re: Newbie questions (I'm SO confused)
Re: Newbie questions (I'm SO confused)
- Subject: Re: Newbie questions (I'm SO confused)
- From: Brent Gulanowski <email@hidden>
- Date: Mon, 28 Oct 2002 21:53:04 -0500
On Monday, October 28, 2002, at 08:38 PM, Tamara L. Cravit wrote:
Hi all,
I'm working on my first Cocoa application (I'm a longtime PC developer,
doing my first Mac app for a client), and I'm really confused. I've
gone
through the currency converter tutorial, but making the next leap from
there
to the app I need to write is proving challenging. Specifically where
I'm
having trouble at the moment is that my app has two NSComboBox
controls and
the values in the second are dependant on the values in the first. I'm
not
quite understanding where/how to populate the first NSComboBox, nor
where/how to change the list values of the second box when the
selected item
in the first one changes.
In Interface Builder, clicking on things usually causes things to
happen. If not, then Open the IB Inspector panel ( Command-Shift I).
With a combo box, the inspector has a little attributes thing which
lets to add new items, and there's other self-explanatory buttons and
text fields.
More generally, I'm not sure I have a really good idea of where things
live
in a Cocoa application -- what gets called when the app initializes,
how
exactly to connect the UI to my code, and how to do things at various
points
in the application's lifetime (such as doing initial setup stuff when
the
app first starts). Can someone help point me in the right direction
for my
specific question and/or point me to something that explains in
slightly
more general terms than the Currency Converter tutorial how a Cocoa
app goes
together and how the UI and code are connected to one another?
If you poke around the developer documents, in places like NSApp,
NSResponder, and the programming topics like Views, Event Handling, and
such, you'll probably find lots of good stuff.
Essentially, main calls a function called NSApplicationMain, which does
a half dozen or so standardized setup chores, like creating an
autorelease pool (which provides a form of memory management) and
creating an instance of the NSApplication class. This critter runs the
show -- it's the top of the object graph. You can always send a message
to this singleton by referring to the NSApp global variable from
anywhere in your application. The class reference will show you a large
number of useful methods.
NSApp and its helpers are responsible for unpacking the objects in the
nib, managing the responder chain, tracking windows, sending
notifications and that sort of thing. You can pack a lot of
functionality into a nib file, and these are fully-featured objects,
not just dumb ui layouts. Furthermore, *any* object can be placed in a
nib (as long as Interface Builder knows about it). The main nib is
owned by NSApp; every nib has an owner -- the buck has to stop
somewhere. The objects in the nib are connect by outlets--this are
pointer ivars. However you can often send messages to objects without
having an explicit pointer -- you can send messages to the first
responder, which is tracked by NSApp. The Responder Chain mechanism
will run through relevant recipients (generally views of some sort or
another) looking for an object which responds to the message. Outlets
are one kind of ivar -- action targets are a similar sort. Controls
have targets which get sent a sort of "hey" message. The target then
sends a message back asking for relevant info about what triggered the
action message. "Which menu item are you?" "What text are you
displaying?" "What is your item number?" etc.
Views are more elaborate than controls (although controls are a kind of
view), in that you often provide explicit event handling methods by
overriding methods of NSResponder. These get called automatically when
matching events occur within the purview of the object in question.
NSResponder is an important class to know well if you are building Aqua
applications.
AppKit provides you with most of the standards components you need, but
you will still have to provide manager objects (i.e.: the controllers)
to see that application-unique functionality actually gets taken care
of. But anything that you think would be generally useful to have in a
modern GUI-driven application will probably exist in AppKit somewhere.
Foundation provides non-GUI utility classes.
There are tons of resources on the web for Cocoa programmers. Download
some Apple sample code from the developer site (accessible from a few
different contents pages, including the main docs page -- top right).
Also check out www.cocoadevcentral.com, a newbie starting point, and
www.cocoadev.com, a user-edited smorgasbord of information.
Welcome to the world of Cocoa programming.
--
Brent Gulanowski email@hidden
http://inkubator.idevgames.com/
Working together to make great software.
_______________________________________________
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.