To the Macs

Quick bottom line: The Mac has won, and this Expo was the happy celebration.

Reasons for victory? Hmmm.... How about snap and sizzle? It just feels good to use a Mac. There's some great Mac software. The hardware's gained a lot of horsepower. Thanks go to a lot of people: Xerox PARC, the original Apple Mac team, the early buyers, Apple's tech writers and support teams, all the programmers who've survived the steep learning curve, David E. Smith and his stable of MacTutor writers, Motorola's 680x0 chip design teams, all those who opened the hardware, Jobs, Sculley, and on and on beyond the spatial limits of this column.

The crowd energy at the Expo was a big wave, with as fine a glassy-walled tube to hang a cybernetic ten within as any mass computer event I've attended. There was too much to see, too many people to talk to, and some fun parties with good talk and/or loud, danceable music. All in all, a mighty fine fourth birthday.

The Mac made one of its first big public appearances at the 1984 West Coast Computer Faire. While talking to an Apple representative at that event, I yammered about memory, hard disks, slotlessness, and printer limitations. He scanned me up and down. Our disguises are easily pierced. "You're a hacker. Those are just hacker issues. Normal users don't need that stuff. We're giving them what they need."

So the Mac took off fast, then almost died. More RAM, SCSI drives, the Mac II, and the LaserWriter, in synergy with some innovative third-party software, brought it back to life and success. One of the treats of the Expo was seeing so many of the people who contributed to that triumph, the once-maligned hackers, now sitting in decision-making positions at Apple and the third-party development companies. Apple's in a particular hacker-hiring frenzy these days, picking up some great Mac people at a torrid pace. Sweet success over time is the best retort to silliness, eh?

Looking for places other than Apple to sell all those great Mac programs and programming skills you're busy developing? As I roamed the Expo, continually asked company representatives if they were looking to buy. I'm not your humble servant for nothing. They were. The consensus: Competent Mac programmers are still a rare commodity. Especially ones who are able/willing to write robust programs that provide specific solutions in very Mac-like ways and don't mind reworking their code in response to intelligent critiques.

So get copies of the Expo guide and/or the leading magazines so you'll have some addresses, crank up the word processor and mailmerge software, and send out those inquiry letters---the window won't be open this wide forever.

Scott Knaster was at the Expo. He's the Mac tech-support whiz who left Apple for a start-up stint with Guy Kawasaki at Acius. He's now back at Apple, deep into future stuff, and has a new book out: Macintosh Programming Secrets, published by Addison-Wesley.

Scott's been immersed in Mac programming for a long time and knows a lot about the art and science of it. There may be someone who's examined and debugged more Mac source code from more different programmers than Scott has, but I doubt it. His book pulls together a wide range of important, state-of-the-art, Macintosh programming concepts. It's got grand overviews, detailed techniques, and useful summaries. A lot of stuff you just won't see anywhere else. Plus, Scott explains things well. His writing style's smooth. He throws in history, cartoons, funny jokes, and even a special cameo appearance by Our Nation's Leader.

Sometimes, usually around 3:00 in the morning, I think I know what's going on inside the Mac. The thought has a short half-life. This book gives a more permanent effect and works in the bright light of day. It's one of those products that'll let you enjoy getting smarter. Back in the January column, I gave a short list of books that form the core of a good Mac programming library. Add this one to the group, near the top.

I wanted to talk with Dave Lingwood and Dick Hubert, a couple of longtime Apple communitarians and leaders, respectively, of the Apple Programmer's and Developer's Association and its mother ship, the A.P.P.L.E. Co-op. But they were always in the midst of a continuous feeding frenzy at the APDA booth.

Luckily, I bumped into Frank Catalano, the knowledgeable APDA public relations manager. APDA's up to around 20,000 members. It's got its typical order turnaround time down from 5-7 days to 48 hours. APDAlog the quarterly newsletter/catalog, keeps improving. I've got the January 1988 issue in front of me, and it's fun: good articles that are worth reading and lots of new products to slaver over, including final MPW 2.0.2 tools, a LaserWriter IISC reference, and 14 pages of third-party software tools and books. MPW's pretty remarkable stuff. (Yep, I've bitten the bullet and started to dive in; reports forthcoming, as I always seem to say.)

Of special interest to HyperTalkers: APDA's HyperCard Technical Reference, mentioned in the March column, has been enlarged, modified, and split into two pieces. New piece number 1, HyperCard Script Language Guide, is Apple's definitive 200-page Hypertalk reference manual. This is a final APDA draft, about 50 percent larger than the earlier (August 11, 1987) draft. New piece number 2. HyperCard Developer's Toolkit, contains several goodies. There's a nice typeset document, HyperCard Stack Design Guidelines from Apple's wide-awake Human Interface Group. It lays out the basic principles of intelligent stack design in a coherent way. There's a long MacWrite document that provides the details of writing XCMDs and XFCNs, along with several very useful examples in C and Pascal. There are five sample stacks that illustrate using the included XCMDs to cope with serial-port communications, sounds, and videodisc players. Finally. they've tossed in three sounds: a clang, a flute, and a weird voice saying. "Hi, there." If you're serious about HyperCard development. you'll find both these packages vital.

Finally, if you've got a book or software tool that'd be of interest to other Mac programmers, send it to APDA for possible inclusion in APDAlog. APDA scans carefully, and the good stuff gets in. Not that any of us think of money (heh heh), but you could do a lot worse than to land something in this highly targeted publication.

Yaaarrrggghh, always running out of time and space. Good ol' Tyler'll have my head. But, before I get down to some code talk: I was able to speak to representatives from Apple. Borland. Think (now of Symantec). Coral, and Smethers Barnes about all their hot new programming tools. Latest versions have hit the streets, as Apple's finished the current batch of major header-file changes. Source-code-level debuggers are coming. Levels of performance and abstraction are rising. The competition's hot. I was impressed by the commitment that these companies are bringing to the programming tools market.

And the programmers! Ai carambacita! I wish a few Martian anthropologists could've followed the crew of Macahologists who snaked through the San Francisco streets toward a Szechuan Chinese foodery Saturday night for what's become a main Macworld Expo happening---the Netters' Dinner. Combustible comestibility for a group of cybernauts who usually meet at long electronic distances. Hard to tell which was hotter/faster: the food, its consumption, or the idea flow. What is the link between this kind of cuisine and the programming mind, anyways?

Alright, chitchat's over. Let me calm down by discussing some highlights of the HyperCard Scouting Toolkit (ST) project whose images and code sources were shown in April. Please refer to that column for figures, listings, and an introduction to the project.

Stacks are composed of one or more cards. Backgrounds hold features that are common to one or more cards. Cards can contain buttons and text fields and graphic designs. Backgrounds can also contain buttons and text fields and graphic designs. Several stacks may be linked by buttons so that they form a set of stacks.

HyperTalk programs consist of a series of message handlers. Things happen when you work with HyperCard, and those events cause messages to be sent to various HyperCard objects: buttons, fields, cards, backgrounds, stacks, external code resources, and the HyperCard program itself. A message passes up a hierarchy leading from simple objects to increasingly powerful ones, until one of those objects deals with the message by handling it and not passing it on. An object's message handlers are contained in its script. Take a look at the various HyperCard books, documentation sets, and help stacks for diagrams of that hierarchy and more detailed descriptions of the flow of control.

The Scouting Toolkit lives on a stack that has one background and one card. The stack has no script. Neither does the background. And the background contains neither fields nor buttons nor graphics. Backgrounds are useful in stacks with more than one card, where they are used to hold information common to several cards. In this simple stack, there's no need for the background to do anything.

The ST card, which I'll call the STBC (Bat Cave), contains 17 buttons and 2 fields. The STBC has a script with two message handlers. Refer to last column's Figure 5 for a picture of the card and last column's Listing One for the script (as well as the scripts of all the other objects in the stack and brief descriptions).

When the card is first opened up, it's sent an openCard message. I'm nutty about Zen-like workspaces, so this card's openCard handler hides several things: the menu bar, the message box, the tool window and the pattern window. Later on, buttons on the toolkit let you toggle the visibility of those items. Minor problem in toggling: There are HyperCard functions that tell whether the last three are visible, but no such function exists for the menu bar. So the open Card handler stores an indicator in a global variable---one that is known throughout the stack world--imaginatively named menubarState.

If someone plays around with the objects on the STBC, certain buttons might go into hiding. A click anywhere in the STBC outside a button will be caught by the card's mouseUp message handler. It uses a simple loop to make all the card's buttons show up.

Button 1 is one of the most complex. It's the button that kills the Scouting Toolkit, deleting all its buttons and fields from a card, including itself. Button 1's script handles one kind of message, a mouse Up. The button will not delete the ST from the STBC; in that case, it'll flash a warning field at the user. On any other card, though, the message handler removes each button and field via a Victorian clockwork sort of process, as follows.

It turns the cursor into the button tool. For each button it then puts a click at that button's location to select it and calls the HyperCard Edit menu's Clear Button command. Next, it turns the cursor into the field tool. For each field it then puts a click at that field's location and calls on the Edit menu's Clear Field command.

These are two nice HyperCard features: simulating mouse actions and making menu selections. Note how the handler can remove the button whose script it's in. Also, note how I make sure the userLevel variable's high enough to let the handler pull off these tricks and am careful to restore the original userLevel when done. (UserLevel is a global-state variable that controls access to various levels of HyperCard features.)

Button 14's also interesting. It's the button that replicates the Scouting Toolkit onto a new card. On a mouse click, it copies itself to the Clipboard. Then when you paste it onto a new card, it brings over the entire ST and kills itself. How? Well, once pasted on the replication target, it receives a newButton message. The newButton handler starts a series of trips, going back to the STBC, copying a button, returning to the target card, and pasting the copied button in. Once all buttons have been transferred, it gets rid of itself, using the technique described earlier.

This process is slow. Using HyperCard's Lockscreen command, so HyperCard doesn't have to draw the screen on each stack round trip, speeds it up somewhat. Still, it'd sure be easier if multiple stacks could be open simultaneously.

Button 3, used to open up the ST, passes a button click on to another button. Button 4 plays music to accompany and emphasize its action. Buttons 5-8 are simple toggle switches. Buttons 9-12 use menu commands. Button 13's analogous to button 2. Button 15 passes a button click on to button 4.

There are only two fields. Field 1, normally hidden, shows up and displays a copyright notice under the control of button 15. Field 2, also normally hidden, shows up when someone tries to click button 1 from the STBC. Hidden fields are a neat way to add a sense of animated intelligence to your HyperCard work.

If you use the ST for a while, you'll want to tweak it. Two examples that I've worked on are installation into a background and being able to change the spatial configuration of the buttons, with the ST remembering that change. What's interesting is that low levels of object self-manipulation can be done in straight HyperTalk, without resorting to XCMD and XFCN work.

The more I work with HyperTalk/HyperCard, the more I appreciate the convenience, ease, tweakability, and power of the tool. There's a certain simple pleasure to working in its environment, one I haven't had since early BASIC on early micros.

Now, if they can just reduce isolation and modality and get that darned execution speed up. ...

Thanks to all of you who've proffered feedback---oral, electronic, paper---on my first column (January), appreciate each piece, pro and/or con. It's a major navigational aid. A few quick gleanings:

Wayne Pollock mentioned the gap in Mac literature between books for novices and those for experts and expressed hope that this column might fill part of that hole. I agree, and I'll try. And Scott Knaster's new book, mentioned earlier, should be helpful. Wayne also wants more skeleton code and examples. Good news on that front from Apple itself where the Developer Technical Support team has started work on a major new code examples effort. And this column will sport a small Multifinder skeleton Real Soon Now, as Prof. Pournelle would say. Wayne also wants some C + + material. Well, as mentioned earlier. I've finally begun fiddling with MPW, partially because I sniff that a Mac C + + will show up in that environment first. When it does, I'll muck about and report back.

James Savidge wrote requesting a little more information about the solitary useless Mac programming tool I mentioned in my first column. It was a C compiler, not one you see advertised anymore, but beyond that I say nothing. I refuse to give a company that won't refund money to a completely dissatisfied customer any form of energy. Besides. I haven't heard or seen squat about the hucksters for years, so hopefully their tent's collapsed and they've sunk back into the dark.

Several programmer buddies were happy to see more Mac coverage here in DDJ. I agree. But my favorite piece of mail came from a guy whose name I don't know---the missive's enshrined somewhere down at DDJ worldwide headquarters---who was P.O.'d at all the graphics that accompanied the January article. He reads DDJ for code, not cartoons. Now that's the DDJ audience I love! Keep it coming.

Apple's excellent Human Interface Guidelines book that I mentioned in the March column is now out in trade form from Addison-Wesley. A lot of the Apple docs will make it out via that route: drafts through APDA, finished stuff via A-W. It's called the Apple Technical Library. The folks from Reading do a nice production and finish.

SuperMac Technology's stopped manufacturing the Enhance board I mentioned in the January column. Too bad, it was/is a fine product. But we've got the Levco stuff now. Also, the final fix for the parasitic clip problem I mentioned regarding my Enhance board: a piece of carefully connived corrugated cardboard artfully wedged twixt the daughterboard and the clip, applying that constant pressure so needed for reliable electromechanical connection---Kludge Klassic #456.

Minor (Ha! Aren't they all when you own 'em?) bug in the March column's source code: the second instruction in the doDrawCntl routine, shown on page 70, should branch to that routine's closing RTS not to the label drawn. So put a label on the RTS, say DoDrCnBye, and change the line to:

BEQ doDirCnBye ;  it's invisible, so no need to draw it

This is a branch rarely taken, and the flawed version has a solid chance of not flaming a program. Classic formula for insect survival.

Yow, it's time to recede. Thanks to all the nice Maccites at the Expo who took time to share thoughts and endure my nonstandard interviewing techniques, including (but not limited to, as I'm prone to quirky memory and misplaced interview tapes) Harvey Alcabes, Scott Boyd, Frank Catalano, John Draper, Joseph Edozien, Chris Espinoza, Amy Goldsmith, Michael Gosney, Michael Green, Ray Heizer, Glenn Hoffman, David Intersimone, Steve Jasik, Margie Kaptanoglu, Bill Kelly, Scott Kim, Scott Knaster, Richard Koch, David Krathwohl, Lance Lewis, Ken Loomis, Greg Marriot, Julia Menapace, Jeff Nutt, Peter Olson, Howard Pearlmutter, J. Scott Phillips, Heidi Roizen, Gerard Schutten, David E. Smith, Joel Spiegel, Michael Swaine, Wes Thomas, Randall Tinkerman, Neal Trautman, and Steve Splonskowski. With special thanks to Amos Gottlieb and roommates for the fine and classic Haight Street gestalt accommodations.

Next time out? I've given up the prediction racket. My batting average is invisible. But, hey, it'll be fun no matter what, eh? Software! Books! People! Code! Especially code, because I've taken it light this month. So dive happily into those fine mind exercisers y'all are so addicted to, and come back ready to do the logic boogie.

Apple Computer Inc. HyperCard Developer's Toolkit, Version 1.0. Available through APDA. Part #KMS036.

Apple Computer Inc. HyperCard Script Language Guide. Available through APDA. Part #KMB009.

Knaster, Scott. Macintosh Programming Secrets. Reading, Mass.: Addison-Wesley, 1987. ISBN 0-201-06661-0.

Vendor

APDA 290 S.W. 43rd St. Renton, WA 98055 206-251-6048