Learn Objective-C on the Mac - Mark Dalrymple [26]
Figure 3-17. Connecting actions is very similar to connecting outlets. Ctrl-dragging to the controller class brings up a popup menu with all available actions.
That is all we need to do in Interface Builder, so save the nib by pressing ⌘S and then close it and go back to Xcode.
NOTE: When linking outlets, you always Ctrl-drag from your controller class instance icon to the interface item to which you wish to link it. Each outlet can be linked to only a single interface item. When linking actions, on the other hand, you Ctrl-drag to your controller class instance icon from the user interface item, and multiple interface items can be connected to the same action method.
Implementing the Action Method
The only task remaining before we can try out our program is to actually write the code that will get called when a button is clicked. This code will look at the sender argument to determine the title of the button that was called, use that title to create a string, and then use our label outlet to display that string. Single-click on ButtonsAppDelegate.m and add the following code.
First we synthesize the accessors and mutators for our one property. Synthesizing these methods means that we don’t have to provide implementations for them. They’re created for us! We’ll discuss this issue a bit more in Chapter 4. Then we implement the buttonPressed: action method. This method first grabs the title of the button that called it. It then uses that button to create a new string, and then uses that string to update the label.
Press ⌘R or select Build & Run from the Build menu to compile this source code into an application and launch it. If you press the center button, your application should look exactly like Figure 3-1.
NESTING MESSAGES
Some Objective-C developers nest their message calls pretty deeply. You may come across code like this in your travels:
This one line of code will function exactly the same as the three lines of code that make up our buttonPressed: method. For the sake of clarity, we won’t generally nest Objective- C messages so deeply in the code examples in this book, with the exception of calls to alloc and init, which, by longstanding convention, are almost always nested.
Click all three buttons, and notice how our one action method handles all three buttons appropriately. Move the window to a new location and quit out of the application. Press ⌘R to launch the program again, and the window should come up in exactly the same position it was in when you quit the program. If you click the yellow minimize button in the title, the window will shrink down into your dock (click it in the Dock to maximize it), and if you click ⌘W or click the red close button in the window, the window closes. Unfortunately, the application is still running, but there’s no way to get the window back open. Let’s address that now by configuring our application to quit when the window is closed. To do that, we’ll have to use something called the application delegate.
The Application Delegate
Every Cocoa application has one and only one instance of a class called NSApplication. You don’t need to interact with NSApplication directly very much. It’s created for you and handles the event loop (the part of your application that notices user input from the mouse and keyboard, and handles the input by sending messages to the appropriate objects) and most of the lower-level stuff without you having to give it much thought.
Expand the Other Sources folder in the Groups & Files pane, and single-click on main.m. In that file is our application’s main() function, which is the function that gets called when our application is launched. This function contains only one line of code, which calls a function named NSApplicationMain(). That function, which is part of Cocoa, automatically creates an instance of NSApplication