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
Read an Excerpt
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!
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!
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.
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 ContentsIntroduction
Part I: Introducing the Macintosh Basics
- 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 II: Resources: This Is Programming?
- 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 III: Using a Compiler
- 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 IV: Learning the C Language
- 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 V: The Moment of Truth: Writing a Program!
- 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 VI: The Part of Tens
- 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 VII: Glossary and Appendixes
- 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
- 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