Learn Objective-C on the Mac - Mark Dalrymple [98]
In Chapters 7 through 9, we’ve covered the main concepts you need to get up and running with Core Data, and now it’s time to move on to other topics. We won’t be leaving Core Data behind, however, as it will still play a role in some further exercises, though not to the same extent. We don’t have enough space in this book to turn every example into a fully fledged application. Even in cases where we’re not using Core Data, however, you might want to think about where it could fit into what we’re demonstrating in the coming chapters. Now that you’ve got Core Data at your fingertips, you’ll probably have a whole new view on some aspects of application development that you would have solved in a different way before. Speaking of views, that’s where we’re headed in Chapter 10, with a look at some of the most prominent and widely used view components in Cocoa and elsewhere: windows, menus, and sheets.
Chapter10
Windows and Menus and Sheets
For the past several chapters, we’ve been focusing on what could be considered the “back end” of Cocoa programming, the model and controller classes that provide functionality to help take care of your application’s infrastructure. Now it’s time to turn our attention to the “front end” of Cocoa, and pay more attention to the view part of the MVC architecture.
In this chapter, we’re going to focus on windows (not the Microsoft kind), menus (not the restaurant kind), and sheets (not the bed kind), all of which are high-level GUI objects that practically no Cocoa application can do without. Windows provide the foundation for view objects to do their drawing. In Cocoa, these are represented by NSWindow, its direct subclass NSPanel, and several specialized subclasses. Menus provide the familiar top-of-the-screen access to system-wide and application-specific user actions that most Mac applications have, and are represented by a hierarchy of NSMenu and NSMenuItem objects. Sheets provide an alternative to the classic free-floating modal window by letting you attach a modal window as an overlay on an existing window, giving the user a more coherent interface.
We’re going to explore each of these three areas in a “lab,” a toy application that has no real use, and is only created for demonstrating some functionality and letting you see how these things work.
NSWindow and NSPanel
Start by creating a new Xcode project using the Cocoa Application template, and name it WindowLab. We’ll use this project as a testbed for demonstrating a variety of window features.
In Mac OS X, nearly everything you see on-screen is presented using windows. Many windows are easily recognizable, having the standard controls along the top, drop-shadow behind it, perhaps a resizing control at the lower right.
But some windows aren’t so obvious. For example, if you launch a game that takes over the whole screen for its display, even if it’s presenting custom controls of its own that have nothing to do with Cocoa, that’s all occurring in a window. The Dock at the bottom of the screen is surely a window. And if you drag a file icon from one Finder window to another, the icon you’re dragging is actually being “carried” inside a small, transparent window!
In all of these cases, you’re seeing and interacting with instances of NSWindow and its subclasses. NSWindow is a very versatile class that lets you configure several behaviors right out of the box, and lets you do even more by subclassing. In general, if you want to change the appearance of the window itself, either its “chrome” (the title bar and upper-left corner controls), its transparency, or its shape, you’ll probably need to subclass NSWindow, but otherwise, you almost never will. In this book, we’re going to stick to the kinds of windows that are ready to use directly and conform to Apple’s Human Interface Guidelines, and won’t be subclassing NSWindow to change its