LETTERS

MORE ON HIDING DIALOG ITEMS
In develop Issue 20, I came across the Q&A (at the bottom of page 107) that recommends using AppendDITL and ShortenDITL to add or remove many dialog items at once rather than using ShowDItem and HideDItem on each item individually. I agree with what's said; however, there's an issue with using AppendDITL that I encountered recently and confirmed with Developer Support.

I've been involved in writing an application that uses 'ictb' resources to define the font for each dialog item. This is necessary for our application to allow globalization. When AppendDITL is called to append items to the dialog, the associated 'ictb' resource for the appended DITL resource isn't loaded. 'ictb' resources are loaded only when NewDialog is called. As a result, AppendDITL can't be used in this case; the show/hide items mechanism must be used instead.

I find develop informative; keep up the good work.
-- Niall Quiggin

Ah, the inevitable exception to the rule. Thanks for pointing it out. -- Dave Johnson

PUZZLE PAGE ERROR: OPENRF
The solution for the Puzzle Page in develop Issue 20 is wrong. It says that the Finder should use OpenRF instead of OpenResFile. OpenRF allows the resource fork to be accessed only as a data stream, and so is useful only if the code wants to copy the entire resource fork without examining its contents. To look at bundles and icons and such, a routine such as HOpenResFile must be used -- which is, in fact, what the Finder calls.

The cause of the bug isn't that the Finder uses fsRdWrPerm, but that it uses fsCurPerm. Inside Macintosh: More Macintosh Toolbox implies that fsCurPerm will work fine if the file is open for writing by someone else, and that read permission to the file will be granted in that case. But unfortunately, fsCurPerm will fail, just like fsRdWrPerm, if the file is already open for writing. To guarantee access to the resource fork of the file, fsRdPerm must be used instead of fsCurPerm. This change was made to the Finder in system software version 7.5.1.

Still, you can't blame Shelley and Byron for getting the wrong answer; they're just dogs, and most dogs don't have access to Finder sources.
-- Greg Anderson, Apple Computer

I conferred with my dogs and they apologized profusely for assuming the inner workings of the Finder that they indeed did not understand. Thanks for the correction.
-- Cary Clark

PUZZLE PAGE STINKS
Has it ever occurred to you how small must be the audience to which your regular contributors KON & BAL are playing? Their Puzzle Page is elitist and intellectually arrogant. Who do you imagine would be privy to the Apple-Eyes-Only knowledge necessary to solve some of these puzzles? As you progress further and further into their morass of micro-minutiae, they indicate that you're less and less clever due to your ever-reducing "score." The whole concept is punitive, pedantic, and boorish. And those invectives at the end of the article continue the process of belittling the reader with the suggestion that, due to your incredibly low score, "Maybe you'd better stick to AppleScript." Ouch! As it happens, AppleScript is an incredibly powerful technology that helps to differentiate the Mac OS from being just another pretty interface. Their attempt at being humorous isn't lost on me, but it failed nonetheless.

Those guys are certainly smart and Apple needs to have people like that on the payroll. But the average fellow in Kansas with a subscription to develop who has adopted Apple as his computing beacon is mocked by such articles and to no real good end. The Puzzle Page is wasted on all but the most inner circle of monks in the Apple sanctum sanctorum.
-- Lance Drake

Your letter was surprising, since we get a lot of good feedback on the Puzzle Page. The puzzle format is just for fun (heh heh). The idea is that you learn something from the debugging techniques. Probably no one ever scores above 0, but that's not really the point. If you haven't already, you might want to take a look at the two letters in Issue 20 on the subject of the Puzzle Page.

Humor is a tricky thing: what some people find hilarious, others find repugnant. I'm sorry the Puzzle Page doesn't work for you. I certainly don't want any of our readers to feel mocked; maybe our publishing this letter will stimulate some dialog on this.

Regarding your specific comment about AppleScript: we couldn't agree more. We hope you'll be pleased with our new regular column, According to Script.

By the way, Apple does indeed need smart people like KON & BAL on the payroll, but they don't work for Apple anymore.

Thanks for writing.
-- Caroline Rose

UNTIDY CODE (GIVE US A BREAK)
Greg Anderson's article in Issue 20 of develop , in the listing on page 67, gave me a probably unintentional insight into the deeper workings of Apple code. Apparently, constructions like this

while (true) {
    do something
    if (somethingelse) break;
}

You're right; the use of a break statement in conjunction with while (true) is generally considered poor style. Good style would be:

condition = true;
while (condition)
    condition = DoSomething();

While code that appears in develop should of course use good style, the develop staff tells me that they are loath to enforce particular rules; they can, however, make suggestions, and will keep an eye out for this construct in the future. Apple's guidelines for software development recommend against using breaks inside loops and also against using do/while in place of a simple while loop.

The ultimate metric used to judge code should be the clarity of the intent of the algorithm in question. Using good and consistent style certainly improves the readability of code, but I would hope that small infractions of style would be forgiven if the intent of the code remains clear. Code quality is important to Apple, and we're always working at improving the process used to produce system software.
-- Greg Anderson

WHAT DO YOU THINK OF THE PUZZLE PAGE or the rest of develop , for that matter? We welcome timely letters to the editors, especially regarding articles published in develop . Letters should be addressed to Caroline Rose -- or, if technical develop -related questions, to Dave Johnson -- at AppleLink CROSE or JOHNSON.DK. Or you can write to Caroline or Dave at Apple Computer, Inc., 1 Infinite Loop, M/S 303-4DP, Cupertino, CA 95014. All letters should include your name and company name as well as your address and phone number. Letters may be excerpted or edited for clarity (or to make them say what we wish they did). *