Learn Objective-C on the Mac - Mark Dalrymple [21]
If you look back at Figure 3-1, you’ll notice that there are three buttons and one text field. When the user presses one of the buttons, the value of the text field is updated. Because we need to change the text displayed by the text field, we’ll need an outlet to it. We’ll also need an action method for the buttons to trigger. Because action methods receive a pointer to the object that triggered them, we can use a single action method for all three buttons. Let’s declare our outlet and action now.
In the editing pane, add the following code (for brevity, the comments at the top of the file are excluded):TIP: When we want you to add code to an existing file, we will make the new code bold, and leave the existing code in the normal code font.
This is pretty straightforward. First, we declare an instance variable (label) that is a pointer to an NSTextField. This pointer is what will actually hold the address of the text field object use for the label in Interface Builder. Then we declare a property based on that instance variable. This property uses the same name as the underlying instance variable, and includes the IBOutlet keyword, which will allow Interface Builder to find our outlet and make it available to us in Interface Builder. We also declare a single action method called buttonPressed:, which is the action method that will be triggered by the application’s three buttons.
Back to Interface Builder
Expand the Resources folder in the Groups & Files pane and double-click MainMenu.xib to launch Interface Builder. Because Interface Builder parses outlets and actions only from the header file, we do not need to write the implementation of buttonPressed: before we can begin designing our interface in Interface Builder.
TIP: Once Interface Builder opens, feel free to change the menu so that the items labeled NewApplication have the correct name. If you don’t remember how to do it, refer to Chapter 2. We won’t be walking you through updating the menu items in future chapters.
The very first order of business is to create an instance of the controller class we just created. Defining a class in Xcode, as we just did, creates the class, but it doesn’t create any objects. In order for our class to do its job, there has to be an instance of that class when the application launches. Without an instance of the class, none of the code we write can ever get called.
You’re probably familiar with creating object instances in Objective-C. Typically, you do something like this:
And that’s a perfectly valid way of creating an instance of an object. It’s not the only way, however. If you look at the window labeled MainMenu.xib in Interface Builder (Figure 3-4), you’ll notice that there are several icons in it. With the exception of the first three icons, each represents an instance of an object that will get created automatically when this nib file is loaded into memory. Because MainMenu.xib gets loaded when the application launches, adding an icon to this window here automatically results in an object instance getting created when the application launches. Let’s use that feature to add an instance of ButtonsAppDelegate to this nib now, which will ensure that there is an instance of our controller class when our application is launched.
Figure 3-4. The MainMenu.xib
Proxy Objects
Before we do that, though, let’s take a moment to look at the first three objects in the nib. These icons will always exist in Cocoa nib files. You can’t delete them and, unlike the other icons, they don’t cause object instances to get created when the nib is loaded. These three are called proxy objects, and they are here to allow connections from objects in this nib to certain objects that already exist.
The first icon in any nib file is called File’s Owner. This icon is a proxy that points to the object instance that loaded the nib from disk or, in other words, the object instance that “owns” the nib. In an application’s MainMenu.xib file, such as we