June 95 - Letters
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;
}
are acceptable at Apple nowadays. Surely there must be a better, less sloppy and lazy way to do this.
(Please don't ask me what's wrong with it; that would force me to go and buy Windoze machines
next.)
-- Joost Carpay
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). *