Mac OS X Programming phần 1 pps

Mac® OS X Programming By Dan Parks Sydow Publisher: New Riders Publishing Pub Date: November 09, 2001 ISBN: 0-7357-1168-2 Pages: 400 Copyright About the Author About the Technical Reviewers Acknowledgments Tell Us What You Think Introduction Target Audience Necessary Software Organization of This Book Conventions Used in This Book Chapter 1. System Components and Programming Technologies System Software Layers Application Environments and Programming Languages For More Information Chapter 2. Overview of Mac OS X Programming Development Environments Apple Project Builder and Interface Builder HelloWorld: Walking Through a Simple Example Program Handling Program Errors Adding an Alert to the HelloWorldDebug Program Adding a Picture to the HelloWorld Program For More Information Chapter 3. Events and the Carbon Event Manager Events and Event Handlers Example Programs For More Information Chapter 4. Windows Opening and Closing Windows Updating Window Content Associating Information with Windows For More Information Chapter 5. Controls Command Signatures and Control IDs Buttons Radio Buttons Checkboxes Text Input Fields For More Information Chapter 6. Menus Menu Basics Altering Menus Characteristics Pop-Up Menus For More Information Chapter 7. QuickDraw Graphics QuickDraw Basics Defining and Drawing Shapes Patterns For More Information Chapter 8. Text and Localization Localized Resource Files Localizing Window Content Text For More Information Chapter 9. QuickTime Movies and File Handling Files and Navigation Services QuickTime Movies For More Information Chapter 10. Bundles and Icons Applications, Bundles, and Packages Registering a Creator Code Application Icons For More Information Chapter 11. Porting Mac OS 8/9 Code to Mac OS X Carbon Dater: Getting Ready for Carbon Tips for Handling Major Porting Issues For More Information Appendix A. Carbon API Summary Include Files Common Data Types and Functions Core Foundation Interface Builder Manager (Nib Files) Event Manager Window Manager Control Manager Menu Manager QuickDraw Appendix B. UNIX and the Terminal UNIX and the UNIX Shell UNIX Commands Moving About UNIX Programming programs that may accompany it. Credits Publisher David Dwyer Associate Publisher Stephanie Wall Production Manager Gina Kanouse Managing Editor Kristy Knoop Development Editor Jill Batistick Product Marketing Manager Stephanie Layton Publicity Manager Susan Nixon Project Editor Todd Zellers Indexer Cheryl Lenser Manufacturing Coordinator Jim Conway Book Designer Louisa Klucznik Cover Designer Brainstorm Design, Inc. Cover Production Aren Howell Proofreader Sossity Smith Composition Barb Kordesh Media Developer Michael Hughes control and add special behavior to the handling of these tasks. Chapter 5, "Controls," shows how your program's windows include controls. The subject of controls, including push buttons, radio buttons, checkboxes, and text input fields, is an important one because it is one of the two primary means by which a user interacts with your program. The other user-input system is the subject of the next chapter. Chapter 6, "Menus," shows you how your program fully supports menus and menu items. Here you see how to add and remove menus and menu items, implement hierarchical menus (submenus) and pop-up menus, and change the characteristic of menus and menu items (by enabling, disabling, or altering the font of menus or items). Chapter 7, "QuickDraw Graphics," demonstrates how your program draws text and graphics to windows. QuickDraw is simply a set (albeit a large set) of drawing routines that make it easy to draw stylized text (words that appear in a font, typeface, and size of your choosing) and to draw a variety of 2-D shapes including lines, ovals, and rectangles. Here you'll also see how to add patterns and colors to any shape you draw. Chapter 8, "Text and Localization," explains how your program can be properly set up so that translation of its text to another language becomes an easy task. Don't think your program will ever ship to foreign markets? Don't be so sure! If it happens, you want to have the language translation require minimal effort. Even if your application is suited only for customers of one language, you'll want to read this chapter. It explains how you can store all your program's text in one easy-to-edit file and how your program can make use of that text on demand. Chapter 9, "QuickTime Movies and File Handling," covers the details of how your program can open a window and play any QuickTime movie within that window. Where does that movie come from? It comes from a file on the user's disk. Thus, this chapter also covers the details of Navigation Services, which is the set of routines that make it easy for your application to display the standard Open window that let's a user navigate through folders and select a file. Chapter 10, "Bundles and Icons," exposes the details of how your program is packaged and how your program can display its own icon on the desktop. When you build an application, you're actually bundling several files together in a directory. Although hidden from the user, they're all there on the user's desktop. Here you see how your application's files are organized. You also get tips and information on creating an icon and the low-down on associating that icon with your application. Chapter 11, "Porting Mac OS 8/9 Code to Mac OS X," deals with the process of moving an existing code base from Mac OS 8 or 9 to Mac OS X. Here you see how to determine which routines need to be replaced or modified, and you read about techniques and caveats for porting an application so that it runs native under Mac OS X. Appendix A, "Carbon API Summary," lists and describes the calling convention for many commonly used Carbon API routines. Developing a Mac OS X program means knowing, and making use of, many of the thousands of Apple-written routines that comprise the Carbon API. This book discusses well over a hundred of these routines. This appendix serves as a handy reference to many of those functions. Appendix B, "UNIX and the Terminal," explains the basics of UNIX. Yes, the underpinnings of the Macintosh operating system are now really, truly Unix. This book does not rely on your knowing how to be a UNIX end user or a UNIX programmer, but if you're neither, your curiosity may get to you! Here you see how to navigate through directories and write and compile a very simple program, all from the command line through the Terminal application. On the left side of Figure 1.2, a user clicks a Draw button in a window. The code that's responsible for the display of the button that is a part of the Aqua interface is in the User Interface layer. A click on the button results in the application invoking a function in the Carbon API (which is code in the Application Environments layer). That function in turn accesses QuickDraw code (which exists in the Application Services layer) to perform the drawing of a shape (refer to the right side of Figure 1.2). The representation shown in Figure 1.1 is a simplification of the enormous complexity of the code that makes up the Macintosh OS-but this figure does provide a means of understanding the roles different components play and how these various components interact with one another. The next several pages describe the five layers. As you read these pages, you'll want to frequently refer back to Figure 1.1. User Interface In Mac OS X, the GUI has been given the name Aqua. To the average end-user, Aqua is Mac OS X. Figure 1.1 reveals just how much more there is to Mac OS X, but that information can be kept among us programmers! If an application you develop has the Aqua look, a user of your application is satisfied, he or she won't be the least bit interested in technologies such as Carbon and QuickDraw. Fortunately, and of course, by no accident, Apple has made the Aqua interface easy to integrate into any Mac OS X application that a programmer develops. A program's interface elements, such as windows and menus, can be visually designed using one software tool, while the program's source code can be written in another software tool. When it comes time to build the application, the source code file gets compiled and the resulting compiled code gets linked with the interface elements. Figure 1.3 shows a window being constructed using Apple's Interface Builder program (a free application included with every copy of Mac OS X and an application discussed throughout this book). In Interface Builder, a programmer simply uses drag-and-drop to copy interface elements such as buttons, sliders, and text boxes from a palette to a window. After saving the Interface Builder file, its contents can easily be used in a program. Note in Figure 1.3 that the elements that are displayed in Interface Builder all have the look of Aqua. When it comes time to write the code that displays the window, there's no need to write any special Aqua code. Figure 1.3. Using Interface Builder to define an Aqua interface for a program. When a Mac OS X program runs, it automatically displays the Aqua interface. This is true even if you use an older interface-designing tool that hasn't been updated for Mac OS X. Apple's resource editor ResEdit is one such tool. Before Interface Builder arrived, ResEdit was the interface design software most commonly used by Macintosh programmers. A programmer still can use ResEdit to design a program's interface, even though ResEdit runs in the Classic (Mac OS 9) environment. At the top of Figure 1.4, an alert is being laid out in ResEdit where it will be saved to a file (note the non-Aqua look of the title bar of the window holding the alert, as well as the non-Aqua look of the OK button in that window). When a Mac OS X program is built using the contents of this file, the running of the program results in the alert taking on the Aqua look-as shown in the bottom of Figure 1.4. Figure 1.4. Using ResEdit to define an Aqua interface for a program. Chapter 2 includes a walk-through of the process of creating a simple Mac OS X application. There you'll see a detailed example of how interface elements are created and made use of by source code. Application Environments Just under the User Interface layer are the Application Environments (see Figure 1.1). In other Mac OS X documentation, you might have seen a more abbreviated version of Figure 1.1 that displayed only three application environments: Classic, Carbon, and Cocoa. This is done because Apple's emphasis has been on those three. The following is a brief introduction to these environments. Later in this chapter, we cover them- and two additional environments-in greater detail. Classic The Classic environment exists for one specific reason: backward compatibility. A Mac user with a computer running Mac OS X most likely owns at least one application that hasn't been upgraded to become a native Mac OS X application. Such a program isn't capable of displaying the Aqua look and it won't support Mac OS X enhancements such as protected memory. To enable Mac users to preserve their investment in Mac OS 8 and OS 9 applications, Apple has included the Classic environment as a part of Mac OS X. When the user runs an older Mac program, that program runs in the Classic environment, where it displays the look and feel of a program running in Mac OS 9. You might have heard the Classic environment referred to as a "Mac OS 9 emulator." That's not quite right. For a Mac user running Mac OS X to launch an older program, that user's Mac must have a copy of Mac OS 9.1 installed. Mac OS 9.1 can be installed either on the same drive as Mac OS X, though on a different partition, or on a different drive altogether. In any case, for Classic to work, the user's Macintosh must have two complete, separate OSs installed: Mac OS 9.1 and Mac OS X. When a program runs (on any computer), it is a process. The OS sets aside a block of memory devoted to that one process. If you double-click the TextEdit program icon on your Mac, for example, Mac OS X considers it a process and loads the TextEdit code into a block of memory. If you then run Internet Explorer, Mac OS X considers that another process, and it loads the Internet Explorer code into a separate block of memory. To make use of the Classic environment, Mac OS X runs Mac OS 9.1 as if the OS itself were a process. It's as if one OS (Mac OS 9.1) is functioning within another (Mac OS X). The Classic environment is a wonderful bit of technology and trickery that makes Mac OS X all the more useful. Because of Classic, just about any Mac program written within the last few years-and some older applications as well-can be run on a Macintosh sporting Mac OS X. As nifty as Classic is, though, Apple strongly discourages programmers from writing applications specifically designed to run in Classic. In other words, don't get an older copy of an integrated development environment (IDE), sit down at a Mac running Mac OS 8 or OS 9, and set about developing a program that runs on that machine. Rather than expending effort developing a program that is immediately dated (won't run native on Mac OS X), you should devote the same effort to developing a Macintosh program that runs native on Mac OS X. In certain circumstances, you can create such a program that also can execute on a computer running Mac OS 8 or OS 9. To do that, you'll make use of the Carbon environment. Carbon For years programmers wrote Mac programs using the Macintosh Toolbox. The Macintosh Toolbox is an application programming interface (API), which is a set of thousands of functions that relieves a programmer of much of the busy work of writing the code most programs need. The Macintosh Toolbox still exists, and it's still possible for a programmer to use it to write what is now called a Classic program. However, there's no reason for a programmer to do this. With Mac OS X, Apple has [...]... the Macintosh Toolbox, which is an API that has existed (and has been continually upgraded) since the inception of the Macintosh computer If an application is developed using the Macintosh Toolbox API, and that application is launched on a Macintosh running Mac OS X, the application runs in the Classic environment Classic is a compatibility environment only It is Mac OS 9 running within Mac OS X Classic... to Mac OS X in that it enables users to preserve their investments in older software However, because an application developed using the Macintosh Toolbox API can't run native in Mac OS X, no programmer developing a new application should use the Macintosh Toolbox API If the desired result of a new programming project is a native Mac OS X application that is capable also of executing on a Macintosh... support Mach Any OS requires core software that handles the system's most basic and most critical functions For Mac OS X, this core software is named Mach Mach technology is new to the Macintosh OS, but the code itself isn't entirely new-Mach itself has been around for well over a decade The version of Mach that is at the core of Mac OS X is based on code from a combination of the original Mach, Apple's... environment that exists specifically to run native Mac OS X applications When Apple bought NeXT, Apple used much of the NeXT OS in Mac OS X Apple also used much of the NeXTSTEP object-oriented framework as the basis for Cocoa A programmer uses the Cocoa object-oriented programming framework to create programs that run native on Mac OS X A program designed as a Cocoa application runs native in Mac OS X, but does... on a Mac OS X computer A Cocoa-built application does not launch if it's installed on a computer without a running Mac OS X At this writing, Mac OS X is just being introduced Although Mac OS X now is being included on all new Macintosh computers, the phase-in period might still take some time (considering that new Macs will also ship with a version of Mac OS 9, and because many owners of older Macs... of the Macintosh Toolbox API The term enhanced subset is one that I've just coined, and it requires a little explanation! Why Carbon API is an Enhanced Subset As Apple was developing Mac OS X, it was modifying the Macintosh Toolbox The result was the Carbon API Apple examined each of the thousands of Macintosh Toolbox functions and eliminated the ones that could not be adapted to work in Mac OS X The... the Macintosh Toolbox will be able to keep most of their existing code and be able to make use of much of their existing knowledge of the Macintosh Toolbox Although Apple was able to port thousands of the Macintosh Toolbox routines to run under Mac OS X, many routines had to go To regain the functionality of these lost routines, and to add programmer support for the new functionalities accompanying Mac. .. in choosing a programming environment is the projected OS makeup of the target audience If a programmer expects a hefty percentage of intended users to be running Macs that aren't running Mac OS X, Carbon becomes the environment to use It's the one to use because it's possible to build a Carbon application that can run native on a Mac OS X computer and on a computer equipped with Mac OS 8 or Mac OS 9... the Macintosh Toolbox; this is the reasoning for calling it a subset of the Toolbox Of the thousands of functions that were salvaged, many had to have some of their code rewritten to work properly in Mac OS X; this is why Carbon is an enhancement Fortunately for Mac programmers, most of the code changes Apple made to Macintosh Toolbox functions are kept hidden For instance, the Macintosh Toolbox API... finding good documentation on programming the Macintosh using object-oriented techniques Cocoa Carbon and Cocoa are the major programming resources for Mac OS X developers Cocoa is an object-oriented framework Using Cocoa, a developer creates an application that runs native on Mac OS X, but will not run at all on Mac OS 8 or 9 Because most Mac programmers use a procedural programming language rather . your application. Chapter 11 , "Porting Mac OS 8/9 Code to Mac OS X, " deals with the process of moving an existing code base from Mac OS 8 or 9 to Mac OS X. Here you see how to determine. Internet Explorer code into a separate block of memory. To make use of the Classic environment, Mac OS X runs Mac OS 9 .1 as if the OS itself were a process. It's as if one OS (Mac OS 9 .1) is. system's most basic and most critical functions. For Mac OS X, this core software is named Mach. Mach technology is new to the Macintosh OS, but the code itself isn't entirely new-Mach