TextEdit documentation: "Programming Industrial Strength Windows"

  • “If you’re de­vel­op­ing Win­dows soft­ware for a com­mer­cial or shrink­wrap type mar­ket, this book should be required read­ing. ” —Joel Spolsky
  • "God help the programming industry!" —A reader from Japan

Once, TextEdit was a companion program for a book. Now, that book serves as the documentation for TextEdit. It's payback time...

þe Olde Contents

I've uploaded all the chapters, adapting to the Wiki formatting as best I could. Formatting and cross-references is a bit haphazard, but it's all readable. Most of the code listings are just placeholders, but you can find them all under the Source Code tab. Which is sort of the point, here on CodePlex...


Part I : Background

Chapter 1 — The Road Ahead
Chapter 2 — Designing for Users
Chapter 3 — Designing for Programmers
Chapter 4 — The Mechanics of Subclassing

Part II: Foreground

Chapter 5 — The Bare Bones
Chapter 6 — Exceptions
Chapter 7 — Off the Launch Pad
Chapter 8 — Child Windows
Chapter 9 — The Main Window
Chapter 10 — Customization and Persistence
Chapter 11 — Wait a Moment
Chapter 12 — File I/O
Chapter 13 — About Dialogs
Chapter 14 — File Management
Chapter 15 — Search and Replace
Chapter 16 — Printing
Chapter 17 — Changing Fonts
Chapter 18 — Going Abroad
Chapter 19 — Meanwhile, in the Background
Chapter 20 — Setup, and Down Again
Chapter 21 — The End of the Road

Appendix A — TextEdit Command Index
Appendix B — Bibliography and Recommended Reading

þe Olde Blurbe

“Error handling has been omitted for clarity.”

Too many times have I read that sentence in a pro­gram­ming book or article. Not that there’s anything inherently wrong with this; simplification is a legitimate tea­ch­ing device. The problem is that the literature is terribly one-sided—it’s a rare gem that says, “error hand­ling has been included to show how it’s done.” Many pro­gram­mers never learn how to han­dle er­rors and anoma­lies. Even more chil­ling, some never rea­lize that the is­sue exists. The re­s­ults are all around us: robust­ness and relia­bility are rarely con­side­red def­in­ing character­istics of soft­ware.

This book gives you an understanding of what it takes to build industrial strength software—software that works reliably and robustly, software that doesn’t get bet­ween the user and his task. It will not bestow soft­ware nirvana upon you; indeed, no book ever could. That un­at­tain­able state of grace can only be app­roached through ex­perience; the most a book can do is to help you get the right rather than the wrong kind of ex­perience. My highest hope is that the book will inspire you to care—about your users, about your pro­fes­sion and about getting the details right.

The adjective “fragmented” describes much of the computer literature. Many books use minimalist examples to illustrate various APIs and sub­systems, and rarely draw things together into a coherent whole. Again, this is not nec­es­sa­rily a Bad Thing; many excellent books use this app­roach.

Un­for­tu­nately, it is not enough. When you assemble those fragments to create a full-blown app­li­ca­t­ion, their in­ter­ac­tion gives rise to an ex­po­nent­ial in­crease in com­plex­ity, and a myriad of details must be con­sid­e­red. This aspect of soft­ware construction is rarely covered, and the lit­terature is left with a hole large enough to drive a truck-full of bugs through. Sadly, bugs and inconsistencies often are considered de­f­i­n­ing characteristics of computer software.

This book takes a more holistic approach; it is built around the develop­ment of a single 20,000-line application.

In ad­di­tion to error handling and app­li­ca­t­ion architecture, the book focuses on usa­bility. Efficient flow of information should receive much consideration during soft­ware design, but the current state of the World Wide Web is proof that it rarely re­cei­ves any consideration at all. Does the user really need that ani­mated deodo­rant on his desk, or would your develop­ment effort be better spent ensuring that the user can get his work done efficiently and effectively, and that his data are never lost? While I like cool stuff as well as the next programmer, I think it should be built on solid ground rather than shifting sands.


Last edited Aug 29, 2008 at 11:40 PM by petterh, version 37