Mac OS X Programming phần 1 pps

Copyright About the Author About the Technical Reviewers Organization of This Book Conventions Used in This Book Apple Project Builder and Interface Builder HelloWor

Copyright

About the Author

About the Technical Reviewers

Organization of This Book

Conventions Used in This Book

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

Text Input Fields

For More Information

Chapter 8 Text and Localization

Localized Resource Files

Localizing Window Content Text

For More Information

Chapter 10 Bundles and Icons

Applications, Bundles, and Packages

Registering a Creator Code

For More Information

programs that may accompany it.

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

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

created the Carbon API, which is an enhanced subset 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

Carbon API includes about 70 percent of the functions of 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 FrameOval function exists by the same name in the Carbon API, and it is invoked by a programmer in the same way now as in the past In both cases, the result of making a call to FrameOval is-you guessed it-the drawing of a framed oval Exactly what does the code that comprises the FrameOval function look like? A

programmer didn't know that information when using the Macintosh Toolbox API, and he or she doesn't know that information now when using the Carbon API To make use of a Carbon API

function, a programmer need only know how to invoke the function The "internals" of the function are unimportant

There are some features of Mac OS X that aren't present in Mac OS 9 These features are not

addressed by any function in the original Macintosh Toolbox To address this issue, Apple has added a number of new routines to the Carbon API These routines didn't exist in the original Macintosh Toolbox API (which is another reason for saying that Carbon is an enhanced version of the Toolbox)

When you develop a Carbon application, you're creating a program that runs native in Mac OS X Building this application under certain conditions in certain development environments (namely including the CarbonLib library in a Metrowerks CodeWarrior project) enables this same program to run on a computer that's running Mac OS 8 or 9 Such a program won't, however, have the Aqua look when running under Mac OS 8 or 9 For a programmer with an existing body of Mac code, Carbon is the way to go The effort to port code from Mac OS 8/9 to Mac OS X through the Carbon API is minimal For a programmer new to Mac programming, Carbon again might be the best bet Cocoa is a good programming environment, but it is an object-oriented framework that must be programmed in Objective-C or Java If you aren't experienced in the techniques of object-oriented programming, the Cocoa learning curve might be too steep for you

Cocoa

The Cocoa environment is an 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 not run at all on a

Macintosh running Mac OS 8 or OS 9

Carbon or Cocoa?

Cocoa and Carbon are the two primary environments for creating native Mac OS X applications, and a programmer who sets out to develop a program capable of running native on a Mac OS X computer needs to choose between environments The choice is based on a combination of factors, including the programming background of the programmer and the version of the Mac OS that is expected to

represent the majority of the target customers

One key issue in choosing a programming environment is the learning curve associated with the chosen environment A programmer with a procedural programming background (namely the C language) should consider Carbon A programmer with a strong object-oriented programming

background might consider Cocoa Here's why:

● A Carbon application can be written in an object-oriented language such as C++, but it is typically written in C Most Macintosh programming books (including this one) use the C language in explanations and example source code listings Almost all of Apple's thousands of pages of online Carbon documentation use C, as do the Apple-supplied Carbon header files

● A Cocoa application, on the other hand, is created using an object-oriented framework, and is written in an object-oriented language: either Objective-C or Java If a programmer has little

or no object-oriented experience, it might make the sense to choose Carbon over Cocoa If a programmer has previous Macintosh programming experience, it again makes sense to

consider Carbon The Carbon API looks familiar to a programmer who's worked with the Macintosh Toolbox API, which serves as the foundation of the Carbon API If a programmer

is strong in object-oriented programming, making use of the power of an object-oriented framework makes Cocoa a likely choice

Another factor 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 same is not true of a Cocoa-built application It can run only 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 won't immediately [or ever] upgrade to Mac OS X)

Application Services

Directly beneath the Application Environments layer is the Application Services layer, as shown in

and QuickTime-are primarily graphics-related These system services are available to, and crucial to, all application environments except BSD As you'll see later in this chapter and in Chapter 2, BSD is

an environment used to write UNIX programs that run in a Terminal window As such, these

applications don't require access to the graphics-related services