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.