Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: headers / list search / docs (was:putting '/' or '(' in the menu item)



On 3/30/05 8:25 AM, a.d. jensen didst favor us with:

> On Mar 29, 2005, at 5:41 PM, Laurence Harris wrote:
> 
>> Did you try reading through Menus.h?
>> 
>> /*
>> * Metacharacters in the text of this item (such as the dash) are
>> * ignored.
>> */
>> kMenuItemAttrIgnoreMeta       = (1 << 8),
>> 
>> Read those headers.
> 
> Not to pick nits (I agree that the headers are a good place to look,)
> but here's an example of frustrations that a programmer can face.  He
> probably would have read right past that bit if he even got to it, as
> he wanted to know why a '/' and '(' weren't going into the menu.

I have long advocated that people should read through basic headers such as
Menus.h, MacWindows.h, CarbonEvents.h, and a few others. By that I mean read
through them from beginning to end to learn what's in them, not just a quick
search to find the solution to the problem. These headers (particularly the
ones documented by the HIToolbox team) are the most information-dense
resource I know. If, after reading the above comment, one searches the Menu
Manager Reference PDF for "metacharacter," in short order he'll find a table
of the metacharacters and their effects. In fact, if you search that
document for "/" the second occurrence is in the table of metacharacters.
Now, if you're going to tell me software developers shouldn't be expected to
read documentation such as the Menu Manager Reference PDF, even when having
a problem, then we're just going to have to agree to disagree. ;-)

My thinking is that if you don't know about metacharacters, what else don't
you know? What else might you be doing incorrectly, with APIs which have
been superceded, or by doing more work than necessary? The time saved by not
reading these things is usually less than the time wasted later tracking
down these kinds of problems.

Sure, we could just give people answers to questions like this, but how does
that help them the next time they have questions which are answered in the
headers or docs? I'm just trying to encourage people to do what's in their
best long-term interest.

> He didn't know about a related problem with a 'dash', and the term
> meta-character was introduced in Bryan's follow up post.
> 
> Those of us who have been around for a while know that the / was used
> for assigning command keys, and ( for disabling a menu, but, to this
> guy, it just didn't work for any sensible reason he could see.  Put him
> out on an island, he might never figure it out.

Sometimes that's absolutely true. Many times ‹ this one included ‹ it isn't.
This is not obscure information. It's not on page one of the "How to write
Mac software" guide (not being literal here, so no one ask me where to find
guide ;-), but it's not obscure.

> I agree with the 
> "programmer, help thyself" mantra that "read the headers" espouses, but
> if you don't even know WHAT you're looking for, lotsa luck.

That's why people should take the time to get a general understanding of the
basic technologies. Too many people are in such a hurry to write code that
they think they don't have time to read documentation.
> 
> A neat community project (I don't know, maybe it's already been done,)
> would be some sort of wiki that was built from many of the questions
> I've seen posted to the list.  The list search is less useful because
> no one indexes and tracks it -- there is great information passed out
> on here, but often times it's three posts into a thread that may or may
> not come up in a search.
> 
> Far simpler for someone to say "I've got a problem with a menu.  I'll
> go over here and look in the menu forum.  No, no one's asked it before,
> I'll post a question and once it's answered, everyone else will be able
> to find it."  Ala:
> 
> menus: creating menus:
> q: The text of my menus doesn't show up properly
> a: <background> <solution>

Even better still is to study the available documentation. I think it's a
big mistake to only view the documentation as resource for solving problems.
I've learned a lot reading docs and headers. I've learned about APIs,
constants, and CarbonEvents I didn't even know existed. Then later, when I
need to do something, I'll think, "Hmm, I seem to recall seeing something
about this." Then I go back, find it, figure out how to use it, and life
goes on.

Larry

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden

This email sent to email@hidden

References: 
 >headers / list search / docs (was:putting '/' or '(' in the menu item) (From: "a.d. jensen" <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.