Learn Objective-C on the Mac - Mark Dalrymple [42]
Here’s the code, to be entered somewhere inside the @implementation block in VillainTrackerAppDelegate.m:
As you can see, this code sets up all the attributes for a default villain that most people are familiar with. The initWithObjectsAndKeys: method takes a nil-terminated list of paired values and keys to fill the dictionary with. For the sake of legibility, we’ve put each value/key pair on a line of its own. Note that the “mugshot” attribute is being set to a pre-existing NSImage instance, one of several that are included in Cocoa and are available for anyone to use in their applications. Now is a good time to once again compile the app in Xcode just to make sure we’ve got everything right so far, but there’s still no point in actually running the app just yet. The GUI has been created, but nothing’s actually working just yet.
Paying Attention to Detail
The previous code listing created a villain object, but if you were to build and run your app right now, you wouldn’t see any sign of the villain. All the controls on the window would be blank, because we haven’t populated any of them with values from our villain’s attributes. Now it’s time to change that. In our VillainTrackerAppDelegate class, we’re going to create a new private method called updateDetailViews, which sets up all the GUI objects to display the attributes of the current villain. We’re putting this functionality into a method of its own (as opposed to setting things up right inside of applicationDidFinishLaunching:) so that we can refresh our views whenever necessary, not just when the application launches. We’ll take you through the process of displaying the villain’s attributes, and you’ll gain some familiarity with the basics of interacting with the various classes in our GUI.
Let’s start off by creating a simple “stub” of the new method. We want this method to be accessible from anywhere in our class, but not from the outside. One way to do this is to declare the method as part of a category, with the interface declaration made “private” by virtue of its presence in VillainTrackerAppDelegate’s .m file, rather than its .h file. So, just above the existing @implementation VillainTrackerAppDelegate line in the .m file, insert the following code:
We’ve named our VillainTrackerAppDelegate category “privateMethods,” but we could have called it anything, as long as it makes sense for our purposes. Before we begin implementing the new method, make sure we’re already set up to call it by inserting the following line at the end of applicationDidFinishLaunching:
Do a quick compile to make sure that what we have so far compiles cleanly. Now it’s time to start implementing the updateDetailViews method, and finally see some villain data in our window!
Setting Simple Values
The first two controls we’re going to set up for display are the two NSTextFields containing the villain’s name and last known location. NSTextField can directly accept numbers and other sorts of input as well, but we’re just passing along a simple string for each of these, using setStringValue:. Place these lines at the start of updateDetailViews, which we defined with an empty set of brackets just a few paragraphs ago:
Note that we’re reusing the preprocessor macros we defined earlier, so we don’t have to worry about mistyping a string value. Now you should be able to compile your app, run it, and actually see some data in the window’s text fields!
Next we’ll set the NSDateView’s value. Add this to the end of updateDetailViews:
This is obviously quite similar to what we did for the NSTextFields: similar use of preprocessor macros, calling the relevant method for the target object (setDateValue: in this case), and so on. Once again you should compile and run after entering this code, to make sure that it works and that the