Mac Programming for Dummies

Mac Programming for Dummies

by Dan Parks Sydow, Dean Parks Sydow

Paperback(2ND BK&CD)

$25.16 $29.99 Save 16% Current price is $25.16, Original price is $29.99. You Save 16%. View All Available Formats & Editions


Mac Programming For Dummies, 2nd Edition, is for those who have never programmed before or for those who have tried programming but quit in frustration. This easy-to-use reference breaks down programming basics into small, manageable, individual topics and provides you with the information you need to start programming right away!

Inside, find helpful advice on how to:

  • Get the fundamentals you need to create a great Macintosh program
  • Use ResEdit to create graphical program elements, such as windows and menus, without any programming
  • Follow along on a guided tour of the development process for Macintosh programs
  • Get a thorough introduction to CodeWarrior, the tool that turns code into a full-fledged Mac program
  • Discover why you should use the C programming language and how it differs from other languages
  • Peruse special appendixes that provide helpful tips on problem solving and act as handy references for Toolbox calls and the C language
  • Plus Dan's Lists of Top Ten Mac Programming Tips:
    • Ten steps to creating a Mac program
    • Ten Toolbox functions you can't live without
    • Ten common Mac programming mistakes

Product Details

ISBN-13: 9780764500428
Publisher: Wiley, John & Sons, Incorporated
Publication date: 08/28/1996
Series: For Dummies Series
Edition description: 2ND BK&CD
Pages: 416
Product dimensions: 7.41(w) x 9.23(h) x 1.08(d)

Read an Excerpt

Chapter 2
What Makes Macintosh Programming So Different?

In This Chapter

  • Taking the Mac interface challenge
  • Seeing how source code makes Mac programming different
  • Picking out differences in the insides and exteriors of Mac programs
  • Finding out that easier (DOS programs) isn't always better (Mac programs)
  • Using windows and menus makes Mac programming more fun

The programming skills and techniques needed to write a Mac program are different from those necessary to write a program designed to run on other computers. In this chapter, I cover the basic differences between Mac programming and programming for other machines. This chapter may be especially useful if you've programmed before, but never a Mac. If you've never programmed before, this chapter helps you get acquainted with some issues you face when you program the Mac.

The Interface -- That's the Difference

Why are Mac programs easy to use? Because the programmer puts extra effort into the interface to make it that way. If you intend to construct a GUI rather than a text-based interface (such as DOS), you, the programmer, are responsible for more things. For example, programmers who write programs for DOS computers write lines of text to the screen. They don't have to worry about how to display a window, or create a pull-down menu, or any of that other fun typical Mac stuff.

So it's the interface that's the key difference between programming a Macintosh and programming other computers. With that said, should I wrap up this chapter right here and now? Sorry, you don't get off the hook quite that easily. The rest of this chapter elaborates on the differences between Mac programming and non-Macintosh programming. If you have any non-Macintosh programming experience, this information should help you make the transition to programming the Mac. If you've never programmed at all, the following pages are still of great use -- they're loaded with basic Mac programming concepts and terminology.

If you haven't done much programming, or any programming for that matter, you may actually have an advantage over programmers with years of experience on DOS computers. No, I'm not just saying that to make you feel better! It's true. Those programmers have to unlearn many of their old ways of doing things. You get to start with a fresh, clean slate. By the way, if you find a slate, let me know. I haven't seen one around for years!

Secret Agents Aren't the Only Ones Using Code!

Before delving into the differences between Macintosh programming and other types of programming, I've got one more digression. Programming -- any programming -- relies on source code. That's the stuff that lets you tell a computer just what to do. Because you read quite a bit about source code in the rest of this book, let me say a bit about source code right here and now.

A programmer creates a program; a user simply uses that program. The programmer writes source code to create the program; the user doesn't know or doesn't give a hoot about source code. Before this book is over, you, the programmer, will be on intimate terms with this thing called source code.

Like a relationship with a person, your relationship with source code may be both very satisfying and very frustrating. Just when you think you have things all figured out, along comes a new twist or turn that throws you completely off course.

I know many of the pitfalls that most new Mac programmers encounter, so I can help you bypass them. I've programmed the Mac for over a decade; I can aid you in your relationship with source code -- I'm an expert at relationships. Of course, my six ex-wives may not agree.

Learning the language

Computers, while exceedingly powerful, lack one important capability that people possess, which is the ability to interpret. For example, you and I know the difference between two uses of a word such as lead. If I were to say "You can lead a horse to water" or "Lead is a heavy, soft, malleable metal" you could recognize these two very different uses of the word. From the context in which a word is used, people can interpret its meaning. That's a skill that a computer doesn't have.

How do you then get a computer, which has no interpretive power, to understand and do what you want it to do? By issuing commands to it. But not just any old commands. You can use only commands that are defined by a rigid set of rules. By using only these established commands, the computer doesn't have to interpret anything, which is the way the computer likes it. That's what a computer language is all about.

Like a spoken language, such as English or German, a computer language has a limited vocabulary. Fortunately, the number of words a computer language allows you to use is very limited. That means learning a computer language is much easier than learning a spoken language. Thank goodness! Gott Sei Dank!

Different languages

Just as there are different spoken languages, there are different computer languages. Wouldn't just one be enough? Again, like spoken languages, one would be enough if you could get everyone in the world to agree to use the same one! Over time, different people, different universities, and different companies have all created what they felt was the best computer language. And over time, as computers changed, computer languages have changed.

BASIC, Pascal, C, and C++ are the names of four common computer languages. In this book, I use the C language for all of the programming examples. What criteria did I use to make this choice? I studied, experimented, and worked with each. Then I accepted the $100 bribe that Dennis Ritchie, the creator of the C language, offered me. Seriously, I selected the C language because it is currently the language of choice of Macintosh programmers.

Computer programmers battle ceaselessly about which language is the best one to use. Like debates about politics or religion, no one ever wins one of these arguments. Should you be in the vicinity of one of these discussions, my best advice is to head for cover!

I devote the five chapters of Part IV to the C language, so please look there for more detailed information on the C language.

All programs were once source code

The rough draft of this book, whether I write it in English, German, or Sanskrit, is called a manuscript. The same concept applies to computer languages. Regardless of which language you use, you get the same result: source code. Whether you use C, C++, or Pascal, the product of your work is a page, or perhaps tens or hundreds of pages, of commands (source code).

How does source code differ from the program itself, the Mac program in the icon that the user double-clicks to run? Source code is transformed into programs by something called a compiler. A compiler performs this amazing feat in just a couple of seconds. The CD-ROM that's bundled with this book includes a Lite version of the Metrowerks CodeWarrior compiler, a software program that turns source code into a Macintosh program. Lite means that some of the functionality of the full-featured version has been removed. Don't scowl as you read that -- what did you expect for practically free! The Lite compiler lets you compile the C language examples from this book. The full-featured version, available from Metrowerks, lets you write source code in your choice of three computer languages: C, C++, or Pascal. More on compilers in Part III.

If you've seen programs that run on a Macintosh and programs that run on other types of computers, you may have noticed that they don't resemble one another very closely. The exteriors of the two types of programs are very different. Does that mean that the source code from which the programs evolved also looks different? Clever you -- indeed it does! This is, of course, another one of the major reasons that Mac programming is so different from other types of programming.

I won't show you any source code now. I do, however, want to explain how the different look of two programs means that different programming efforts were put into each. In fact, I'll go into that right now.

Programs Inside and Outside

Source code, simply called code by most programmers, can be thought of as the interior of a program. It's something the user of a program doesn't see or work with. What the user does see -- menus, windows, graphics -- can be thought of as the exterior of a program.

Many people believe that a program that runs on a Macintosh computer is easier to use than a DOS program. (You probably think that, too, because you're reading this book.) A Mac program is easier to use because its exterior (what the user sees) contains useful features, such as windows and menus. But what about its interior -- its source code? Is the code for a Macintosh program easier to write than the code for a DOS program? The short answer is no; writing code for a Mac is harder than writing code for a DOS program. The long answer involves a story about cars. Sure, it's a bother not to settle for the quick answer, but I promise that this short story is helpful.

Imagine a car built in the 1970s. On a cold day, you start the car by pumping the gas pedal several times with your platform shoe, and perhaps then holding the pedal to the floor as you turn the ignition over, trying not to get the keys caught in your love beads. To stop the car on a wet or icy road, you pump the brake pedal.

Now imagine yourself in a car of the 1990s (and a better haircut). With fuel injection, you simply turn the key and start the car, regardless of the temperature outside. With anti-lock brakes you simply press down on the brake pedal, regardless of road conditions. The car of the 1990s is easier to use and works better than the car of the 1970s. But to simplify the parts of the car that the driver uses, the parts on the inside became more complicated. If you peek under the hood of the 1990s car, you see much more machinery than is under the hood of the 1970s car. That's true with many things that are affected by technology. A smooth, sleek, easy-to-use exterior masks a complex, highly refined interior.

But wait! This isn't Chilton's Auto Guide. This is a book on programming the Mac. So how does all of the above pertain to programming? A Macintosh program is like the car of the 1990s, while its DOS counterpart is like the car of the 1970s. While the user of the Mac program finds it is easier to use and more intuitive than a DOS program, the programmer who writes the Macintosh program deals with much more complex code than the programmer of the DOS program.

What about that other GUI, Windows? Is the Mac programmer responsible for more, or different, things than a Windows programmer? More, no. Different, yes. Although Mac programs and Windows programs may look alike in some ways, the programmers responsible for writing the source code for each do things in a different way. If you know someone in the unenviable role of having to learn programming for Windows, you should tell them about Windows 95 Programming For Dummies, by Stephen R. Davis, published by IDG Books Worldwide, Inc.

Easier Doesn't Mean Better

It's easier for a programmer to write a DOS program because the programmer is responsible for less. Just what is meant by responsible for? Read on to find out. As you read, refer to the following figure. It shows part of a screen displaying a DOS program that acts as a very simple calculator.

The person who programmed this calculator was responsible for a number of things: writing text to the screen, writing the on-screen menu that lets a user select an arithmetic operation, writing code so that the program reads numbers typed in by the user, and writing code that performs a calculation and then displays a number to the screen.

Data is a general computer-ese term for letters, words, or numbers. When a computer program displays words or numbers on the screen for the user to view, it is writing data to the screen. When a computer program receives words or numbers from the user, it is reading data. The most common means of entering data for the program to read is by typing on the keyboard. There is another means, but it's usually not available in DOS programs. Macintosh programs sometimes allow you to use the mouse to enter data.

The number of things that the DOS programmer is responsible for doesn't sound overwhelming, and it's not. Because a DOS program doesn't contain windows, icons, or menus, a DOS program is easier to write than a Macintosh program.

To someone who hasn't programmed before, or has programmed very little, easier surely sounds better than harder. But there is a price one pays to write a simple program -- you end up with a simple program! A simple program, like the DOS calculator program, doesn't look very interesting and doesn't do a whole heck of a lot.

Mac Programs -- Interesting, Fun, Exciting!

Why has the Macintosh become so popular over the last several years? You already know the answer: Mac programs are easy to use, fun to work with, and interesting to look at. Remember how the DOS calculator program looked? The figure that follows shows a Macintosh calculator program. It's a free program that Apple includes with all Macintosh computers.

In the previous section, you saw the job a DOS programmer has if he decides to write a calculator program. Now take a look at what a Macintosh programmer would be responsible for if she were to write a spiffy calculator program like the one just pictured.

Now you've seen the kinds of jobs the DOS and Mac programmers face when they want to complete the same task, which is building a calculator program. Comparison is inevitable -- plus I've got to tie this conversation to the chapter title at some point!

Giving information

The preceding example shows that the Mac programmer, like the DOS programmer, writes data and reads data. But the Mac programmer does both a little differently. Take a look at writing data first. Remember where the calculated result was written to in the DOS calculator? In a DOS program, data is written at the current location of the cursor.

In a Mac program, data can be written anywhere in a window. In the Macintosh calculator program, the user clicks the mouse on a number or symbol button, and the corresponding number or symbol is written in the white box at the top of the calculator. As a digit is entered, it always appears at the far right of the white box. Here the 3, ., and the 1 are entered one after another.

Not only can text and numbers be written anywhere in a Macintosh window, they can even be made to overlap other text. And the style -- the appearance -- of data can be altered.

The ability to control the appearance and placement of data is an important feature that separates the Macintosh from many other computers. Another difference is how the user of a program enters data into the Mac.

Getting information

Programs written for DOS computers read data by pausing and waiting for the user to type in words or numbers. Pressing the Enter or Return key signals the program to read the typed value and then continue. Once again, the calculator example.

Ready for one of the most central concepts of Macintosh psychology? Ready or not, here it is: The user is the boss. People like using the Macintosh because they feel that they are in control. A good Macintosh program seldom freezes the screen, forcing the user to do something before continuing. Where have you seen this type of unfriendly forceful behavior? In the preceding example of the DOS calculator program that won't continue until the user enters a number.

A Macintosh program can read data in a variety of ways. Like DOS programs, a Mac program can be designed so that a user types in a number.

Note in the preceding example the presence of both a Cancel button and an OK button in the dialog box. That gives the user the option of changing his or her mind, which is another excellent example of the Macintosh philosophy that the user is the boss.

If a Mac programmer wants the user to make use of the mouse rather than the keyboard, the programmer can use radio buttons or a scale with a slider to read in a value. Here are examples of each of these methods.

Writing text to the screen and reading data from the user are the two primary responsibilities of a non-Mac programmer. You, the challenge-loving individual that you are, have additional duties. Adding a window to your program is one of them.

Working with windows

Programs written for a DOS computer simply display text and numbers on the screen. On a Mac, everything is displayed in a window. A program that uses a window makes you, the programmer, responsible for the following:

  • Opening, or displaying, the window.

  • Drawing or writing to the window.

  • Making it possible to move the window on the screen.

  • Closing the window.

Macintosh provides the user with a myriad of options. Are you starting to get the impression that there's just too much for a Mac programmer to learn? Are you getting nervous about all of this talk about responsibility? You aren't? Good. Then skip the rest of this note. But for those of you considering giving up, I'll let the cat out of the bag and mention a topic that may provide a ray of hope -- the Toolbox. Apple has written a ton of code for you already, code that simplifies such things as creating and moving windows and creating and displaying menus. Because these functions are used by programmers as tools to build Mac programs, Apple got cute and named the entire collection of them the Toolbox. You learn more about the Toolbox in Chapter 14.

Opening a window and writing text to it is a simple process. I know, I know -- you've heard claims like this before. But in Chapter 4, I prove it. There you see the code for a Mac program that uses a window. And best of all, the code for the program fits on less than half a page! Better still, I've gone ahead and typed in all the code and put it on the CD-ROM that comes with this book. That way, as you follow along, you don't even have to type in any source code!

Menus mean choices

Another major difference between Macintosh programs and those written for other computers is the idea of pull-down menus. Mac users like to feel that they are in control of a program, rather than at the mercy of what a program allows or forces them to do. Macintosh menus enhance that feeling of control. A program that doesn't have pull-down menus may still offer some form of menu, but it's not the same. The menu choices are listed on the screen, and the user must choose one before the program continues, which isn't really much of a choice.

As you can see, this kind of menu is a stark contrast to the Macintosh way of doing things. With Macintosh menus, the user has a choice of making several, perhaps dozens, of choices. And if the user decides not to make a selection from one particular menu, she can still perform other actions. The screen doesn't freeze up and force the user to make a decision. A different menu can be selected, or a window can be moved.

When compared to the DOS brand of menus, Macintosh pull-down menus offer a seemingly infinite variety of choices to the user. With this vast improvement, you may think that the menus represent a comparable increase in work for the Mac programmer. Think again! Macintosh menus are easy to implement and involve only a minor amount of extra work for the programmer.

Menus and windows are two of the most distinguishing features of a Macintosh program. Because they are so important to Mac programs, they are also the two topics I spend the most time explaining in the remainder of this book. By the time you complete this book, you'll be able to include menus and windows in each and every Macintosh program you write. And you'll also be convinced that although Mac programming is very different (and sometimes harder) than any programming you may have done before, the resulting programs are well worth the effort.

Table of Contents

Why Program on the Mac?
Who Are You?
What You Need
What's on the CD
About This Book
How to Use This Book
It's Time to Establish Some Conventions
How This Book Is Organized
Part I: Introducing the Macintosh Basics
Part II: Resources: This Is Programming?
Part III: Using a Compiler
Part IV: Learning the C Language
Part V: The Moment of Truth: Writing a Program!
Part VI: The Part of Tens
Part VII: Glossary and Appendixes
Icons Used in This Book
What's Next?
Part I: Introducing the Macintosh Basics

Chapter 1: Windows, Menus, and a Mouse -- That's the Mac
The Graphical User Interface
The Interface Parts
Using the mouse
Working on your desk
Looking at itty-bitty pictures
Ordering from the menu
Peeking through windows
Speaking of dialogs
Wrapping up the interface
The Parts You Need
Menus and windows can do the job
So, you think you're getting shortchanged, huh?

Chapter 2: What Makes Macintosh Programming So Different?
The Interface -- That's the Difference
Secret Agents Aren't the Only Ones Using Code!
Learning the language
Different languages
All programs were once source code
Programs Inside and Outside
Easier Doesn't Mean Better
Mac Programs -- Interesting, Fun, Exciting!
Giving information
Getting information
Working with windows
Menus mean choices

Chapter 3: Removing the Fear, Part I: Don't Let Mac Programmers Scare You!
Demystifying Source Code
Playing by the rules of the game
Decoding some source code terminology
Getting a grip on source code organization
Eliminating Anxiety over Saving and Compiling Your Code
Source code is nothing but text
Completing the picture with compiling

Chapter 4: Removing the Fear, Part II: The One-Minute Program
Remembering Those Conventions
That's It? That's a Mac Program?
Unveiling the program
Naming the program
Examining the code, but not too closely
Getting it ready, 'cause here you come
Opening a window
Writing to a window
Ending the program
Ending at the beginning and the end
That's It . . . But Don't Forget the Toolbox!
Imagining the glory of the Toolbox
Calling the Toolbox
Feeling like you're not alone
Part II: Resources: This Is Programming?

Chapter 5: What Are Resources?
Defining What Resources Define
Look, Ma, No Programming!
Hypothetically speaking about resources
Realistically speaking about resources
The resource/source code connection
But How Do You Create a Resource?

Chapter 6: ResEdit, the Resource Editor
Editing -- It's Not Just for Text Anymore
Forget that text!
ResEdit: One mighty resource editor
What's in a Name?
Don't quote me on this
A 'MENU' is not a 'menu'
Resource IDs
Using ResEdit
Creating a resource file
Discerning the different ResEdit windows
Creating your very first resource
Adding to a resource
Previewing a 'MENU' resource
Editing an existing resource
Sorry, not now

Chapter 7: Two Types of Resources: 'MBAR' and 'WIND'
Discovering the 'MBAR' Resource
Creating an 'MBAR' resource
Adding an 'MBAR' to a resource file
Adding a 'MENU' to an 'MBAR'
Menus come to order!
Summing up the 'MENU' and 'MBAR' connection
Knowing that WIND is for Window
Opening a resource file . . . again
Breezing through a 'WIND' resource
Changing a window's size and location
Changing the look of a window
Moving on
Proving that Resources are Valuable to Source Code
Part III: Using a Compiler

Chapter 8: Getting to Know You: The CodeWarrior Compiler
Comparing CodeWarrior and CodeWarrior Lite
Choosing CodeWarrior for a Number of Reasons
CodeWarrior has everything you need
Apple isn't the best (for once)
You can join the CodeWarrior support club
Creating a Project
Installing CodeWarrior Lite
Creating a project folder
Creating a new project
Working Together: ResEdit and CodeWarrior
Launching ResEdit
Creating the new resource file
Adding a 'WIND' resource
Adding a File to a Project
Removing a File from a Project

Chapter 9: Creating Source Code Isn't Hard, Honest!
Opening an Existing Project
Working with a Source Code File
Creating a source code file
Saving the source code file
Adding the source code file to the project
Reviewing the Creation of a CodeWarrior Project
Entering the Source Code
Opening a source code file
Typing in the code

Chapter 10: Compiling and Running Your Source Code
Compiling Your Code
What happened?
Can you type? The compiler lets you know
Running and Building: Sounds Like Quite a Workout!
Running Code within CodeWarrior
Running the code
Running it again. And again, and again . . .
Checking Out the New Program
Part IV: Learning the C Language

Chapter 11: Choosing C over Other Languages
Why Use C on the Mac?
Everybody's using C
. . . Other reasons for using C
Those Other Languages

Chapter 12: Keeping Track of Things in C: Data Types and Variables
Data Types and Variables: Different, but Related
Predetermined C symbols: Data types
Do -- it -- yourself symbols: Variables
Every Variable Has a Type
Every Variable Has a Value
Order Is Everything
Common Data Types
Data types for whole numbers
A data type for fractional numbers
Common Variables
A Few Examples of Variables
Declaring variables
Assigning values to variables

Chapter 13: Learning the Language -- Just the Basics of C
Care to Comment on That?
Variable Names
Operating without a License
Minimal Math
The addition operator
The subtraction operator
The multiplication operator
The division operator
Operators work together
Operators work with floats, too
Repeating Yourself by Looping
The need to loop
The while loop
Changing Directions by Branching
The need to branch
The switch branch
The if branch
That's All There Is to C?

Chapter 14: To Build a Program, You Need a Toolbox
Why Have a Toolbox?
Miniprograms by Any Other Name
The Toolbox Gives and Receives
Function parameters
Functions return values
Sampling the Toolbox

Chapter 15: Drawing with C: Why Have a Mac If You Can't Draw?
Quick on the Draw
The Coordinate System
Let's Draw!
Drawing a line
Drawing a rectangle
Drawing to a Port
Why have ports?
WindowPtrs and Ports
Part V: The Moment of Truth: Writing a Program!

Chapter 16: Examining a Simple Mac Program
The MyProgram Program Source Code
Functions Aren't Just for the Toolbox
Initializing the Toolbox
Working with a Window
Opening a window
Writing to a window
Planning an addition to the window
More planning for the addition
Solving problems with your box
Making MyProgram More Eventful
Introducing events
Looking at the MyProgram event loop
Holding onto an event
Improving the MyProgram event loop
Examining an Even More Eventful Program
Looking directly into the source code
Extending a friendly reminder
Examining the basic stuff
Examining the Event loop

Chapter 17: Menus That Drop and Windows That Move
Bringing a Window to Life
Dissecting the parts of a window
Clicking different parts of a window
Working with windows can be a drag
Closing a window
Working windows and breaking out of the loop
Dropping that Menu
Running through the menu resources
Displaying the menu bar
Pulling down a menu
Making the menu usable
Handling a menu selection
Examining a program with a menu that drops

Chapter 18: Writing a Very Mac-like Program -- Part I
Regarding the Animator Program
Assembling the Folders Needed to Create Animator
Starting the CodeWarrior Project
Creating Animator's Resource File
Creating the resource file
Adding the Window resource
Adding the Menu resources
Adding the resource file to the project
Creating Animator's Source Code File
Is That It?

Chapter 19: Writing a Very Mac-like Program -- Part II
Introducing the Animator Source Code
Viewing the glory of the Animator code
Knowing What's Going On in the Code
Finding out about 128
Declaring variables
Initializing the Toolbox
Displaying windows and menus
Establishing the event loop
Handling a mouseDown event
Handling a click in the menu bar
Adding the Beep Me! item
Nurturing the Grow Square item
Dodging the Move Square item
Finishing up with the Quit item
Compiling and Running the Animator Program
Naming the Application
Stating your preference
Checking out the new name

Chapter 20: Where Do You Go From Here?
Changing the timing of an animation
Changing the loop
More ideas, please!
Adding the Apple
Understanding why you want to add the Apple to your menu
Understanding Apple menu resources
Changing the ID of a resource
Creating the Apple 'MENU' resource
Adding the Apple 'MENU' to the 'MBAR'
Dealing with Apple menu source code
Declaring new variables
New menu bar setup code
Recapping the handling of a selection from a menu
Handling a selection from the Apple menu
Handling update events
Viewing the AnimatorApple source code listing
Introducing a More Advanced Program: SightAndSound
Understanding what SightAndSound does
Pictures and sounds are resources
Workin' with the same ol' kind of project
Glancing at the SightAndSound source code listing
Picking out the new include files
Looking at function prototypes
Getting another dose of functions
That Wasn't Too Bad, How Do I Learn More?
And Now a Few Words about CodeWarrior Gold
Part VI: The Part of Tens

Chapter 21: Ten Steps to Creating a Mac Program
Creating a CodeWarrior Project File
Creating a Resource File
Adding the Resource File to Your Project
Removing the Resource File Placeholder
Creating a New Source Code File
Saving the Source Code File
Adding the Source Code File to the Project
Removing the Source Code File Placeholder
Writing the Source Code
Compiling the Source Code
Running the Code

Chapter 22: Ten Toolbox Functions You Can't Live Without
The Toolbox Initialization Functions
Displaying a Window
Activating a Window
Displaying a Menu Bar
Capturing Events
Locating a Mouse Click
Working with Windows
Managing Menus
Drawing Text
Drawing Shapes

Chapter 23: The Ten Most Common Mac Programming Mistakes
Having Trouble with the Resource File
Not Pairing Braces
Adding an Extra Semicolon
Using Incorrect Case
Forgetting the \p in DrawString
Forgetting the & with a Parameter
Forgetting to Increment a Loop Counter
Forgetting to Give a Variable an Initial Value
Forgetting a Break in a Switch Statement
Part VII: Glossary and Appendixes

Appendix A: C Language Reference
Declaring a variable
Giving a variable a name
Assigning a variable a value
Data Types
Number types
Window types
Menu types
Math operators
Comparative operators
Assignment operators
Looping Statements
The while statement
Branching Statements
The switch statement
The if statement
Toolbox Functions

Appendix B: Toolbox Reference
Opening and displaying a window
Closing a window
Moving a window
Responding to the Mouse Button
Displaying menus and the menu bar
Responding to a mouse click in the menu bar
Determining which menu item is selected
Setting up ports
Moving to a location
Drawing a line
Drawing a shape
Drawing text

Appendix C: If Something Should Go Wrong . . .
Errors While Trying to Compile Your Code
The Compile menu item is dim
Undefined identifier error
Expression syntax error
Function call does not match prototype error
Cannot convert error
Errors While Trying to Run Your Code
First off, are you in the right section?
Nothing seems to happen
A flickering alert and a frozen Mac
The program runs and then quits immediately
Link failed error
Errors While Running Your Code
Things aren't getting drawn in the window
A rectangle that should be there just ain't there
Errors Not Addressed in This Appendix

Appendix D: Glossary

Appendix E: What's on the CD-ROM?
CodeWarrior or CodeWarrior Lite?
Installing CodeWarrior Lite
Running the installer
Checking to see if your installation really works
Installing Other Files from the CD-ROM
Copying ResEdit to your hard drive
Copying the ...For Dummies Examples folder
Test Driving Your Compiler
Running CodeWarrior and opening the test project
Testing the project
When Things Go Wrong . . .
Can't open project error
CodeWarrior IDE could not be found error
A window with a stop sign appears


License Agreement

Installation Instructions

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews