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). *