Back in the 1960s, when I first started working with computers, a program was simply the instructions necessary to accomplish a single task, usually a calculation of some sort. The program had a completely fixed idea of what this task was going to be; to run the program meant to perform the task uninterrupted, and no more. For example, suppose I had some pairs of numbers representing points in the Cartesian plane and I wanted to integrate the area under these points. I would write a program to carry out this task, and run it; the program would read in the numbers, perform the calculation, spit out the answer, and stop.
In the late 1970s, I got hold of a personal computer. This made a big difference to how I interacted with the computer. Up until then, I had clumsily created my program on paper and transcribed it onto punch cards, which I handed to the computer’s guardians, who ran it at their convenience, usually some time during the night when CPU time was cheap; I’d come in the next day and receive a printout of the results, usually showing that there was a bug in the program, whereupon the whole cycle would begin again, with me tweaking the program and running it again, and so on over a period of weeks until I finally got it to work. But now, suddenly, there were no computer guardians: the computer was mine ! I worked interactively with the computer, entering the program, running it, fixing a bug, running it again, for as long as I liked and whenever I liked. Nonetheless, the concept of what a program was remained essentially unchanged.
In 1984 came the Macintosh, and everything got stood on its head. This computer had a graphical user interface—a GUI. Instead of programs, there were applications. An application, when you started it up, didn’t crunch away at some set task and then stop. In fact, it didn’t do anything at all. It just sat there and waited for the user to do something, such as type some text, or click a button with the mouse. An application was all about interacting with the user. It all sounded very novel and intriguing, until it came to programming the Macintosh. As soon as I looked into this, one thing became very clear to me: I wasn’t going to be able to do it. The management of the GUI was far too daunting a task, requiring programming techniques and detailed knowledge of the computer’s inner workings—its Toolbox—that were much too complicated and elaborate for me. As far as I was concerned, therefore, the Macintosh wasn’t a computer at all; it was just a very expensive toy. It had a lot of GUI bells and whistles, but I couldn’t program it. And a computer is to program.
That changed in 1990, with the release of HyperCard 2.0. HyperCard, which Apple at that time bundled for free with every Macintosh, was a customizable GUI framework wrapped around a programming language (except that Apple called it “scripting,” because they were afraid that the word “programming” would scare people). If you wanted to be able to enter text in a field, you dragged a text field into the window. If you wanted something to happen when a button was clicked, you dragged a button into the window, and wrote some code saying how it should respond to being clicked. It was easy, and it was powerful, and it caused me to take the Macintosh seriously for the first time, because now, in effect, I could program it. In short order, I was using HyperCard and the Macintosh to let my students drill themselves on Ancient Greek forms and exercises; I went on to apply HyperCard to lots of other purposes, and I still use it all the time.
HyperCard had some shortcomings, to be sure. It didn’t generate true applications, but rather made “stacks” that could run only in the presence of HyperCard; still, this was okay, because every Macintosh included HyperCard. The stacks ran rather slowly; still, they ran a lot faster as Macintoshes got faster. The stacks lacked certain Macintosh features, such as color; still, there were workarounds. The fact remained that for certain sorts of tasks, such as storage and retrieval of loosely structured text, HyperCard was absolutely superb; and in general its shortcomings were greatly outweighed by the sheer pleasure and power of being at last able in some sense to program the Macintosh.
What bothered me was that the world of HyperCard was not the world of true Macintosh programming, which had notably failed to rise to HyperCard’s level. In 1996, I was editing a magazine devoted to Macintosh programming, and was astonished at how difficult it still was to write even a simple Macintosh application. There were development environments and application frameworks, but even the most basic tasks required of any application, such as putting up a window and responding to the user’s mouseclicks, were very complicated and distracting to program.
It appeared that this was due to historical causes dating back to the Macintosh’s beginnings. In those days, the Macintosh’s designers had wanted programmers, who were coming ultimately, after all, from the pre-Macintosh non-GUI world, to feel that the application was in full charge of the computer; but at the same time they wanted Macintosh programs to conform to certain standards of appearance and behavior. So the Toolbox consisted of lots of little utility routines, while the onus of stringing these routines into standard patterns was left upon the program’s shoulders. The result was that the Macintosh programmer was being forced to juggle every niggling rise and fall of the mouse button. For example, a programmer could not be concerned simply with a high-level notion such as what the program should do when the user closed a certain window. The program itself had also to do the busywork of interacting with the user, as well as making the window actually close; and it was the programmer’s job to make sure it did this. If the user clicked in the window’s go-away box, the program’s event loop, which was supposed to be asking repeatedly to be notified of any user actions, would receive a MouseDown event; the program was then expected to notice that the mouse was in the go-away box, and to ask the Toolbox to watch the mouse button and, when it was released, to report whether the cursor was still in the go-away box, and if it was, then the program must give the necessary commands to close the window. This song and dance was an invariable pattern—that is, every mouseclick in any window’s go-away box in any program would always cause the window to be closed; yet the sequence was not in any sense automatic from the programmer’s point of view. Multiply this instance by many hundreds, and you’ll have an idea of what programming the Macintosh was like. Macintosh programs had come to consist mostly of material that was more or less boilerplate, merely to initiate all the right Toolbox actions at all the right moments, so as to manage the standard interface elements and behaviors. The irony was that, despite the standardization of these universal conventional features of the interface, it was still up to all individual programs—and therefore all individual programmers—to handle the details, even though they were all doing it in just the same way as one another;[1] so far from being in charge of the computer, therefore, the programmer had become its slave.
I found this situation frustrating, daunting, and ridiculous. In HyperCard, remember, I could drag a button into a window, write some easy code to give it functionality, and presto, I had a working button in a HyperCard stack. Why couldn’t I do the very same thing to get a working button in a standalone application? This, it seemed to me, was the Holy Grail of Macintosh programming.
Then along came REALbasic, and suddenly, the Grail appeared.[2] REALbasic was easy to learn and easy to use; like HyperCard, it took care of the interface and permitted me to create a working application quickly and with very little programming, but unlike HyperCard, it created genuine standalone applications with a truly standard and Mac-like interface. From almost the moment I started working with REALbasic, there was a sort of meeting of the minds between me and it. I soon found that I had become something of a REALbasic disciple. Watching users writing to the REALbasic mailing list, posing questions and describing difficulties they were having—often the same questions and the same difficulties—I realized that what was playing them false wasn’t some failure on REALbasic’s part, but the lack of a reasoned and instructive explanation of the concepts, and of a compendious guide to the techniques, that the user needed in order to work with REALbasic with satisfaction and facility. This book is my attempt to supply that lack. I have written the book that I myself wished to read—and indeed I do read it. I keep it by me whenever I’m using REALbasic. I have studied it in cafés, in bed, and in places you’re not supposed to mention in introductions to computer books. I’ve enjoyed it, I’ve learned from it, and I’ve found that it contains the answers to just about all my REALbasic questions. And, from what they’ve told me, so have many others. I hope you will too.
Traditionally, programming means writing code; and writing code is a form of mental activity, somewhat akin (resorting to some analogies with which I’m personally familiar) to solving a British crossword puzzle or translating a passage of Ancient Greek—to reach the solution, you have to juggle a lot of material and make it fit together sensibly. Now, code is text; and a lot of code is a lot of text. The result is that a program of any complexity can be hard to write, hard to read, and hard to understand, because it’s hard to keep all that text organized in a way that makes sense—in a way that reflects and reveals what all the parts of the program do and how they fit together. The program is too big for you to hold in your head all at once and to grasp how its parts interact; yet, as with the crossword puzzle or the Greek sentence, it is just this simultaneous interaction of its parts that you need to have in mind in order to solve the problem of writing or understanding the program. Then too, writing a full-fledged application for a modern personal computer with a graphical user interface, such as the Macintosh, requires some particularly complex and even cumbersome programming, because, as explained in the previous section, quite apart from whatever its useful purpose may be, the application must also present and manage all its windows and buttons and menus and other interface features, and must respond correctly to the unpredictable actions of a user wielding a mouse and keyboard.
REALbasic makes it easy to create a working application in a matter of minutes, and helps you, the programmer, keep even large amounts of code well organized, lucid, and easy to modify. The reasons for this may be summarized under three heads, describing three aspects of REALbasic.
First, REALbasic is an application framework. REALbasic already knows how to make a working application, as well as how to construct and manage the interface elements, such as windows and buttons and menus, that applications typically need, before you do any programming at all. All you have to do, metaphorically speaking, is to hang the desired pieces on the framework that REALbasic has already provided.
Second, REALbasic is object-oriented. The notion of an object, in programming, is a powerful and interesting one, which enables a style of programming called object-oriented programming, or OOP; we’ll have much more to say about this later on. For now, think of OOP as a way of keeping code organized by segmenting it into parts, with each part having a clear, independent functionality. REALbasic enforces OOP, because it is object-oriented from the ground up; it actually makes you keep your code well organized. And REALbasic enforces a particularly natural and easy form of OOP, because it adopts as its primary objects the very elements of your application’s interface that you would naturally think of as being objects—windows and buttons and other “physical” items the user will encounter while running your application.[3]
Third, REALbasic is an integrated development environment, or IDE. What does this mean? REALbasic is an environment because, figuratively speaking, it’s a place where you work as you’re programming. It’s a development environment because what you’re doing in that place is writing (developing) an application. It’s integrated because it incorporates the mental aspect of programming, the writing of code, with the physical aspect, the representation of your program’s objects. REALbasic shows you your objects as physical entities; for instance, you actually see your application’s buttons and windows, and can physically arrange them. And then, because it’s object-oriented, REALbasic compels you, and helps you, to associate whatever code you write with some particular object. Your code ends up in neat compartments, because REALbasic’s environment consists of compartments. And your code’s functionality is organized in a natural way, because those compartments are, in the first instance, the physical items of your application’s interface.
You can thus expect your programming activity, as you develop an application with REALbasic, to be of two sorts: mental and physical. And these two aspects will be integrated with each other, thanks to REALbasic’s object-oriented programming language and its IDE.
Some of the time, you’ll be dictating to REALbasic how you want your application to look. For instance, you might want to say that in a certain window there should be a button of a certain size, with a certain caption, in a certain font. These are physical features of your application, and by and large you’ll work with them physically—in essence, you’ll “draw” what you want your application to look like. Drag an interface element into a window, and now that window contains that interface element; it’s as simple as that. Indeed, in most cases it is possible to design and create a program’s entire interface, “drawing” its windows and buttons and text fields and so forth, without writing a single line of code. (The creation of an application can thus easily be shared between a designer who doesn’t know how to program and a programmer who has no sense of design.) What’s remarkable is that the result is already in some sense a working application: when the application runs, its window appears, and a user can move the window, click its buttons, type and copy and paste text in its text fields, close the window, and even quit the application. That’s because REALbasic is an application framework; from the outset, it is already handling all the petty conventional details of getting the interface to interact properly with the user and with the computer.
At other times, you’ll be dictating the behaviors and calculations that your application is to perform in response to user actions. This is the mental side of working with REALbasic—you’re coding. The user has pressed this button—so what would you like to happen? The user is closing this window—so what would you like to happen? Perhaps, when the user chooses the File → Save menu item, the contents of the frontmost window should be saved as a textfile. Perhaps, when the user clicks a Help button, a Help window should appear. All things of this sort you specify by writing code; and at the same time, you’ll associate that code physically with the appropriate object, so your code will remain well structured and clear. The code for what happens when a button is pressed is associated with the button; the code for what happens when a window is closed is associated with the window; the code for what happens when a menu item is chosen is associated with the menu item. You write your code in an easy, Basic-like language, which is compiled, not merely interpreted, so it runs quickly. Commonly needed facilities such as display of graphics, file handling, and network communications are built right in, so it’s easy to obtain the functionality you’re after; additional functionality can be provided through language extensions.
When you’re done, you’ve a remarkably small, remarkably efficient standalone application—not, to be sure, as small or as efficient as if you’d written it in C and explicitly managed the various Toolbox utility routines yourself, but then this was the very thing you were trying to avoid in the first place. The trade-off here is one of ease, not to mention the time it takes (or doesn’t take) to create an application with REALbasic, often a matter of mere minutes. For this reason, I find myself reaching for REALbasic to create all sorts of practical utilities. Something to print envelopes with bar codes? Something to count word occurrences in a textfile? Something to look up a dictionary definition on the Internet? Something to play my favorite card game with me? When I want an application of this sort, I don’t have to wait for someone else to write it, and I don’t have to pay someone else for it—I write it myself, with REALbasic. And REALbasic is not only for private programming; it has been used to create applications of commercial quality.[4]
REALbasic is also just a truly splendid way to program, or to learn programming. The language is small and simple. In the course of developing an application, it’s easy to obtain satisfying partial results early on; this constant satisfaction keeps the programmer motivated, and makes REALbasic a natural candidate for an informal, incremental style of development. Even more impressive is REALbasic’s inherent object orientation, which enforces good modern programming techniques, and inculcates, at an almost subconscious level, important higher-level notions such as classes and instances, encapsulation, and inheritance. I’ve taught REALbasic to children, and have seen them pick up the basics easily in a few days, writing an elementary animation program after a week and an object-oriented Tic-Tac-Toe game after two weeks. I’ve picked up a C++ textbook which I had formerly found confusing, and understood it clearly and immediately; REALbasic had given me a full grasp of the object-oriented concepts that had previously eluded me. Whether you’re a complete beginner or an experienced programmer, whether you treat it as a stepping-stone or as an end in itself, whether you want to create something useful or something fun, REALbasic is a great way to take charge of your Macintosh.
When I started writing the first edition of this book toward the end of 1998, the current version of REALbasic was 1.0. By the time the manuscript was turned over to the publishers, REALbasic 2.0 had emerged, and the last version of REALbasic of which I was able to take account was 2.1a4. At about that time, by sheer happenstance, development of REALbasic slowed considerably, so after the first edition became available in October 1999, it remained substantially correct for REALbasic 2.1 when the latter appeared in April 2000—a rare circumstance in today’s computer world, where printed books are usually left panting in the dust of the constantly evolving software they are trying to describe. REALbasic 2.1.2, which appeared soon after, was primarily a maintenance release, and the book was able to remain current, for all practical purposes, through the mediation of a web page of corrections that I posted at http://www.tidbits.com/matt/rberrata.html. In February 2001 the reprinting of the first edition provided an opportunity to correct some typographical errors, to account for some changed URLs, and to relieve readers of some unnecessary worry by deleting one or two outdated bug warnings.
Since then, REALbasic 3.0 has added many helpful features to the IDE, a complete rewrite of the SpriteSurface control, some rationalization of other built-in control class behaviors, better application memory management, greatly improved compilation for Windows, and the ability to compile for—and to run under—Mac OS X. There have also been numerous bug fixes (many of them, I’m proud to say, apparently inspired by criticisms, warnings, workarounds, and explanations in the book’s first edition). The sum of these alterations is a substantially new REALbasic; hence this second edition of the book. The latest version of REALbasic available to me before the manuscript left my hands was 3.2.1, and while it is impossible, by the very nature of software and of books, for a printed book to be perfectly coordinated with the software it describes, you can be secure in the knowledge that I did my level best to be accurate right up to the last minute. Some differences between your copy of REALbasic and what this book describes would be no bad thing, if the reason is that some of the bugs mentioned in the book are fixed!
REALbasic itself is also available in two editions, though these are simultaneous, not successive: the difference is that only the higher edition comprises the full Windows compilation and database capabilities. Nowhere in this book do I comment upon this distinction; I simply describe the higher edition. Those with the standard edition should have no difficulty mentally deleting the irrelevant passages, which are very few, consisting mostly of Chapter 22 (on databases) and the various mentions of Windows scattered throughout. Apart from this, the book applies equally to both editions of REALbasic.
Those who have purchased the higher edition of REALbasic in the expectation of building Windows executables may be disappointed to find that I don’t devote much space to discussion of writing Windows-specific code. The truth is that this is not something I know a great deal about. This is primarily a Macintosh book, I’m primarily a Macintosh person, and REALbasic, let’s face it, is primarily for writing Macintosh applications. My approach, therefore, is to assume that your application will be running on Macintosh. That is what I describe in detail. When I’m aware of the Windows implementation of a feature differing from the Macintosh implementation, I mention it as a deviation from the Macintosh standard; otherwise, I leave to your experimentation to discover the details about how particular features translate across platforms.
With Mac OS X, the problem is more one of timing. In a sense, the Mac OS X version of REALbasic is primary; to reflect this fact, the screen shots have been redone to reflect the new Aqua interface. Nevertheless, both Mac OS X and Version 3.2 of REALbasic that runs on it and builds for it are very new at the time of this writing. The “classic” REALbasic, which runs on and builds for Mac OS 7.6.1 through 9.x (to which I refer in this book, for want of a better name, as "Mac OS Classic”), is noticeably more mature and reliable. So I have ended up treating this as the standard, with Mac OS X differences treated as deviations from it, where I know about them.
The first edition of this book included, for the benefit of those who, for some unknown reason, persisted in using REALbasic Version 1, an appendix summarizing the differences between it and Version 2. It has not, however, been deemed worthwhile to maintain such backward compatibility in this new edition, precisely because it is a new edition. Those who have not migrated to REALbasic 3.2 can continue to use the first edition; meanwhile, the second edition is about REALbasic 3.2, and treats earlier versions of the program mostly as if they never were.
Hard as it is to believe, REALbasic was essentially the brainchild of one man, Andrew Barry. Or perhaps this is not so surprising, since why should we expect great software to be designed and produced by committee? I’ve never met or spoken to Andrew, but I feel as if I know him intimately. From the structure of REALbasic itself and from Andrew’s letters to the REALbasic mailing lists, I came to appreciate his profound, original insights into the nature of programming, and to see him as an extraordinary coder, a great teacher, a patient and generous helper, a sharp computer scientist, and something of a philosopher. To know his work has been a deep and abiding pleasure, and I hope that this book can in some measure serve as a sign of my appreciation and gratitude for his gift to the world.
At REAL Software, Inc., first Jannice Faber and then Geoff Perlman saw to it in the early days that I was supplied with a copy of REALbasic; this courtesy was much appreciated. Since then, my relationship with REAL Software has continued to be a pleasure, including some heated arguments which I hope they enjoyed as much as I did, and culminating in their awarding me the 2000 Cubie award as REALbasic Advocate of the Year, a proud honor indeed. Lorin Rivers, the product manager for REALbasic, has overseen various mutually agreeable arrangements. David Grogono has done splendidly the job I’d like to have had, providing technical assistance to users and bringing bugs to the special attention of the programming team; I have benefited from both categories of his work. Programmers Cortis Clark, Joe Strout, and William Yu have shown ingenuity, persistence, and balanced judgment in picking up the work where Andrew Barry left off, and also in providing answers on the REALbasic mailing lists. In this regard, though I greatly appreciate the contributions of all three, I think Joe Strout deserves special mention, for his constant presence on the lists, his patient and generous willingness to provide detailed information about REALbasic’s inner workings, and his ability to squash a bug or re-architect an entire REALbasic control class in amazingly short order. He is a presence on the Internet in various other guises as well, and it simply beats me where he gets his energy and his time. In any case, this edition of the book has been the beneficiary of his kindness; whatever I have learned since the first edition about what goes on inside the magic black box that is REALbasic, I have learned by hanging on the words of Joe Strout. To all the team, I hope that this book serves as a token of my gratitude, and that it helps REALbasic to go far in the world, as well it deserves to.
I should like to say a word also about the documentation included with REALbasic (written originally by Geoff, though various hands since then have labored to keep it up-to-date and corrected), along with the release notes provided at each iteration of the development process. My book is, I should make clear, in no sense a mere rehash of this documentation. It is, on the contrary, a thoroughly original work: I have disagreed with the organization and terminology of REAL’s documentation, going to great lengths to create better terminology and explanations of my own; I have approached with skepticism and suspicion every assertion in REAL’s documentation, and have taken much time confirming or denying each one for myself, in the process finding many downright mistakes and omissions (some of which, of course, were later corrected in REAL’s documentation on the basis of the first edition of this book); I have even deliberately ignored the REAL documentation’s examples and skipped reading entire passages, so as to approach the subject for myself with an open mind and to guarantee that the book is, except where specified in a footnote, “all my own work.” In short, this book documents my own approach to the learning and teaching of REALbasic, as I have come to understand it by experimentation, discussion, and thought. Nevertheless, it is also perfectly obvious that my book simply couldn’t exist without REAL’s documentation, which made REALbasic remarkably easy for me to learn at the initial stages, and which remains the primary source of facts in detail—there are, indeed, several places in this book where, with no reluctance whatever, I refer the reader to it for further information. So, to all at REAL who have contributed to the documentation and the release notes, a special thanks.
At O’Reilly & Associates, my first thanks go to Tim O’Reilly, my publisher and initial editor, for being willing to take on this book. He’s smart and helpful, and it’s a pleasure and an honor to work with him. Second, many thanks to the late Frank Willison, my original editor-in-chief. He was smart and helpful, and it was a pleasure and an honor to work with him too. It was through Frank’s generosity that I obtained a copy of FrameMaker in which to compose the manuscript, thus enabling the book to move through production much more rapidly and accurately than it otherwise might have done. He also did some smoothing of troubled waters, above and beyond the call of duty. He will be missed.
What makes FrameMaker, for all its faults, a pleasure to work with, is Mike Sierra’s brilliant series of templates. Robert Romano redrew the diagrams to make them professional, and provided clear and helpful instructions about them. For the first edition, Nancy Kotary was the production manager, occasional diplomat, and, as ever, a good friend, and Maureen Dempsey provided extensive production support and guided the first edition through its final stages. Cathy Record and Suzanne Axtell assisted greatly with the book’s postpublication fate, and treated me to a memorable meal. Rachel Wheeler oversaw the corrected reprint of the first edition. For the second edition, Troy Mott was editor, and made several insightful suggestions that have resulted in a friendlier exposition. Mary Brady was the hard-working production editor; her friendly professionalism was a great comfort, and the book owes its polish and consistency to her and to the sharp eyes and amazing memory of proofreader Norma Emory. To them all, and to the many others who, unbeknownst to us mere authors, mysteriously cause O’Reilly books to see the light of day, thanks.
This book owes a very, very great deal to the users who haunt the REALbasic mailing lists. I learned from what they asked; I learned from what they answered; I learned from what they got wrong; I learned from what they got right; I learned from explaining to them; I learned from what I couldn’t explain. In the years I have spent in their virtual company, we have grown together, like the fellow classmates that we are. I should like to thank them, one and all, for letting me play in their sandbox. It would be impossible for me to single out by name all those list members who have made a difference to this book. Some, those from whom I took particular nuggets of information or lines of illustrative code, are thanked in footnotes. But others have helped me in a more general way, probably without knowing it or intending to, just by being the kinds of people they are, knowing the kinds of things they know, and making the kinds of arguments they make. Since they are not mentioned elsewhere, I would like to thank them here: they are Anjo Krank, Fabian Lidman, James Milne, Rudi Muiznieks, S⊘ren Olin, Fabian Rueger, Steve Schacht, James Sentman, Art Urban, Jan Vanderwegen, and Paul Welty. Special mention must go to Seth Dillingham, who generously gave of his time to supply me with his entire archives of the mailing list as I was getting started with the first edition. Thomas Tempelmann and Tonio Loewald performed extensive technical review of the final draft of the first edition, for which I am very grateful; the book was crucially improved through their corrections and suggestions. Ken Hagler also did some sharp-eyed proofreading, saving me from many silly mistakes. For this edition, the book was helped immeasurably by the technical review comments of Apple Computer’s Quinn (“The Eskimo!”) and of REAL Software’s Cortis Clark and David Grogono.
From its readership this book has benefited twice. First, on a personal level, there are all those who, while the book was being written, though anxious for it to be finished and available, did not chastise me for how long it was taking, but cheered and urged me on, and those who, after it was published, took the time to send along words of commendation and appreciation. Their enthusiasm beforehand is what brought this book to life; their insightful response afterward is what made the time and the effort worthwhile. Second, on a critical level, errors were spotted and suggestions both pedagogical and technical were offered by numerous readers, and the simple fact is that if this second edition is an improvement over the first, it would not be so without them. Once again there are too many to mention by name, but I cannot resist citing here, because they are not mentioned elsewhere in the book, George Bate, Joe Brown (several gold stars), Bernd Froehlich, Dave Fultz, Joe Huber, Fabian Lidman, Tony Rich, Donald Siano, Bob Stern, Mark Stubbs, Kem Tekinay, Bob Urschel, James Wilson (several more gold stars), Charles Yeomans, and Andrew Who Is Nice to Bears. I know that there are others whose names I’ve omitted; I apologize, but I hope at least that when you see what effect you had on this edition you will realize that I listened and was grateful.
Finally, the traditional caveat is in order. Though I have received inspiration and advice from many quarters, nonetheless, someone has to take ultimate responsibility, and it’s clear who that is. There may, in this book, be accidental omissions, or areas where my understanding is faulty, or places where I guessed wrong, or points on which I should have taken the advice I was offered but didn’t. In short, this is my book, and the errors and shortcomings are my own, and no one else’s. I apologize for them, and I hope you’ll let me know about them, so that perhaps they can be mended in the future.
We have tested and verified all the information in this book to the best of our ability. If you have an idea that could make this book better, please let us know by writing to us at:
| O’Reilly & Associates, Inc. |
| 1005 Gravenstein Highway North |
| Sebastopol, CA 95472 |
| (800) 998-9938 (in the United States or Canada) |
| (707) 829-0515 (international/local) |
| (707) 829-0104 (fax) fax) |
There is a web page for this book, which lists errata, examples, or any additional information. You can access this page at:
| http://www.oreilly.com/catalog/realbasic2 |
To comment or ask technical questions about this book, send email to:
| bookquestions@oreilly.com |
For more information about books, conferences, software, Resource Centers, and the O’Reilly Network, see the O’Reilly web site at:
| http://www.oreilly.com |
To contact the author, send email to:
| matt@tidbits.com |
Most of the code examples in this book can be downloaded as REALbasic files, some of them in expanded form, from the author’s web site. The site also contains additional examples too large or elaborate to appear in the book, as well as pages documenting errors and corrections as they accumulate. The site is here:
| http://www.tidbits.com/matt/ |
The following typographical conventions are used in this book:
-
Constant width Used to indicate keywords, names of variables and parameters, values (such as string and numeric literals), code, and comments embedded within the code.
-
Constant width bold Used to indicate user input in examples.
- Italic
Used to introduce new terms and to indicate URLs, filenames, and notes to the reader within code blocks.
No one volume, not even a great big one like this, can tell you everything you want to know about REALbasic, for the simple reason that it’s impossible to guess what you might want to do with REALbasic. REALbasic is a tool to make tools, a program to make programs, and its uses are as various as the needs and desires and imaginations of all its users. So here are a few other resources that you might like to look at.
For REALbasic resources, a good starting place is REAL’s own site, http://www.realsoftware.com/, especially the “Made with REALbasic” page, http://www.realbasic.com/realbasic/mwrb.html, where you can find links to hundreds of downloadable code examples, classes, and model applications from generous users. There is also the REALbasic web ring, http://nav.webring.yahoo.com/hub?ring=xbasic&list, a portal to dozens of user-maintained sites. I would also strongly recommend that you consider joining the REALbasic mailing list, which is haunted by people who (for some unknown reason) actually want to help you learn this program: “Operators are waiting to take your call!” Subscription information appears at REAL’s site. There is also a Usenet newsgroup, news://comp.lang.basic.realbasic.
REALbasic lets you design your own interface, but it has no power whatever to keep you from designing it badly, nor can it cope with every nutty idea you might throw at it. Since REALbasic makes it all too easy to do whatever you like with the interface, you should know something about the principles of good interface design. I particularly recommend Tog on Interface, by Bruce Tognazzini (Addison-Wesley, 1992). Also, if you’re writing a Macintosh program, you should know how the parts of a Macintosh program are expected to behave. The official word on this topic is Apple Computer’s own Human Interface Guidelines, which can be found at http://developer.apple.com/techpubs/macos8/HumanInterfaceToolbox/HumanInterfaceGuide/humaninterfaceguide.html; as this book goes to press, the corresponding Mac OS X resource is available for download only in preliminary form, at http://developer.apple.com/techpubs/macosx/SystemOverview/AquaGuidelines.pdf.
This book is not a computer science textbook, and although it contains many examples, it is not a compendium of algorithms. If you want to know how to sort, or how to make an interesting data structure such as a binary tree or a doubly-linked list, this book won’t tell you. There are many books that do, and although they don’t use REALbasic’s own language, the principles are identical on any computer and in any language. The granddaddy of all such books is Donald Ervin Knuth’s The Art of Computer Programming, 3d ed. (Addison Wesley, 1998); a fine practical introduction to algorithms and data structures is Robert Sedgewick, Algorithms in C++ (Addison Wesley, 1998). To understand computer programs deeply, read Harold Abelson et al., Structure and Interpretation of Computer Programs, 2d ed. (MIT Press, 1996). There are many, many numerical and graphical cookbooks: the best numerics text is William H. Press et al., Numerical Recipes (Cambridge, 1992), available online at http://lib-www.lanl.gov/numerical/bookcpdf.html; good graphics texts are David Rogers, Mathematical Elements for Computer Graphics, 2d ed. (McGraw-Hill, 1989), and the several volumes of the Graphics Gems series (Academic Press, 1993-1995).
Another thing this book can’t teach in depth is object-oriented design. I do try very hard to give a sense of how to organize your program in an object-oriented way in line with the structure of REALbasic’s built-in object model, but as your programs become more complex and you start adding a lot of objects, you’ve gone beyond REALbasic itself into a world to which many books are already devoted. I particularly recommend Martin Fowler et al., Refactoring (Addison Wesley, 1999); its philosophy of both the nature and purpose of object-oriented code and the programmer’s day-to-day tasks have proved nothing short of revolutionary in my own life.
Finally, although this book teaches you to program REALbasic, and although it assumes that you will use REALbasic to write Macintosh programs, this book does not teach you to program the Macintosh or how a Macintosh works. The ultimate source on that topic is, of course, the massive Inside Macintosh. Much of it is available online, as web pages and as downloadable PDF files; the places to start are http://developer.apple.com/techpubs/macos8/mac8.html and its Mac OS X counterpart http://developer.apple.com/techpubs/macosx/macosx.html. You can also purchase much of this documentation on CD-ROM or in book form. The Windows equivalent web pages may be found at http://msdn.microsoft.com/library/default.asp.
[1] For a superb introduction to the sorts of things a Macintosh program must do just to exist, from maintaining memory to managing windows, see http://www.mactech.com/macintosh-c/classic-online.html.
[2] For more about HyperCard and my celebration of it, see http://db.tidbits.com/getbits.acgi?tbart=04075. For my initial response to REALbasic, see http://db.tidbits.com/getbits.acgi?tbart=05043.
[3] Some texts insist upon a distinction between object-based programming, which means programming in the presence of objects, and object-oriented programming, which means programming in the presence of polymorphism. I find this distinction artificial; in this book, I just use “object-oriented.”
[4] Some examples are: Intellinews, from Aladdin, makers of the StuffIt utilities, http://www.aladdinsys.com/intellinews/; and Whistle Blower, a server monitor utility, http://whistleblower.sentman.com/.
Get REALBasic: TDG, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
