Re: ColorMatching Ex: communicating between 2 nib object
Re: ColorMatching Ex: communicating between 2 nib object
- Subject: Re: ColorMatching Ex: communicating between 2 nib object
- From: Charlton Wilbur <email@hidden>
- Date: Thu, 23 Dec 2004 03:38:50 -0500
First, some general advice. There are several good Cocoa books out
there, and you probably ought to be consulting one of them *before* you
make a post here. Novice programmers who ask a lot of basic questions
tend to burn out their welcome quickly in forums full of experienced
programmers, because the experienced programmers get tired of answering
basic questions. Books don't get tired. Working your way through
Hillegass's _Cocoa Programming for Mac OS X_, for instance, would
probably give you a good start, and by the time you were done you'd
understand Cocoa a lot better than you do now. Beyond that, one of the
best ways to *not* use up your welcome is to ask questions with
reference to documentation -- "In this book, on page 84 it says if I do
X it does Y, but I tried that and I got Z instead. What am I doing
wrong?"
That said:
I created a new window with a button assigned to new action called
"myButtonAction" in the
MainMenu.nib file of COLORMATCHING . I also a created a new window
"myWindow" connected to an outlet called "myWindowOutlet" in
MyDocument class. The
"myWindow" window is created in MyDocument.nib of the COLORMATCHING
application.
The action you defined in the MainMenu.nib file is a method that will
be called when that action is triggered, usually on the object that
owns the nib file once it is instantiated. In the case of
MainMenu.nib, the owner is an NSApplication object. You *could*
subclass it, but for reasons of complexity and maintainability it's
preferable to create an application delegate object. (What I'm about
to walk you through is not, strictly speaking, an application delegate
object, until the last several steps; however, it's convenient and
reasonable to put application-wide behavior in a single class.)
So step 1 is to create and instantiate an application delegate object.
You can do this in Interface Builder in the Classes pane; select
NSObject and choose "Subclass" from the Classes menu. Name it
something like "AppDelegate." Add the actions you want the class to
perform, using the same menu. Then, from the same menu, choose
"Instantiate." This will create a blue cube icon in the "Instances"
pane of Interface Builder.
Step 2 is to make the necessary connections for the menu item.
Control-drag from the menu item to the blue cube, and choose the action
you want that menu item to perform.
Step 3 is to implement the action. If you go back to the Classes tab
in IB, and then choose "Create Files" from the Classes menu, IB will
create a skeleton implementation for the class you just created.
That's where you put the code to be executed when the menu item is
selected.
Now, to make the AppDelegate object into a real application delegate
object, go back to IB. Control-drag from the "File's Owner" icon to
the blue cube, and choose "delegate" from the list of possible outlets.
Now that you've done that, it's a true application delegate, and you
can implement any of the delegate methods listed in the documentation
for NSApplication to override the default behavior. You could, in
theory, separate that functionality out into two objects, but it makes
sense to have all application-wide behavior in a single class.
There's an example of this in the Hillegass book, as it happens, which
walks you through the solution to the problem.
Charlton
--
Charlton Wilbur
email@hidden
email@hidden
_______________________________________________
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