On 3/1/05 6:09 PM, Mike Lazear didst favor us with:
>
> On Mar 1, 2005, at 12:11 PM, Laurence Harris wrote:
>
>> On 3/1/05 2:22 PM, Mike Lazear didst favor us with:
>>
> AddNibToNav is a bit heavy on the items. It wouldn't be bad to have two
> flavors of each sample code. AddNibToNavBasic and AddNibToNavComplete. where
> the first would just show what it takes to add a window to the Nav Open/Save
> window with maybe one simple checkbox. The "complete" could be more like what
> they currently have.
One simple example should be fine. Apple doesn't need to write our code for
us. If you can follow an example which adds, say, a popup embedded in a user
pane to an open or save dialog, you should be able to figure out how to add
a user pane with four or five items in it. I mean really, AddNibToNav adds
14 controls, many of which I've never even seen in a Nav Services dialog.
What's the point of that?
>> The headers are also very valuable when you want to know what's available if
>> you just read through those which are most essential to you. Searching the
>> headers tends to result in a lot fewer hits than Google when searching for
>> keywords. Someone asked the other day if there were a constant defined for
>> the command to show the character palette, 'chrp'. I searched the headers for
>> "chrp" and came up with one hit:
>>
>> kHICommandShowCharacterPalette = 'chrp'
>>
>> Googling for "chrp" is useless unless you're looking for the Canadian
>> Human
>> Resource Planners web site. If you Google for "chrp Apple" you get hits
>> about the Common Hardware Reference Platform. Searching for "chrp" on
>> Apple's developer site gives you 53 hits and none of them on the first
>> page
>> have anything to do with the character palette command.
>
> I use the Project Find quite often and I would have used it to find
> 'chrp'. I
> usually have Project Find set to "In Project and Frameworks". Thus I
> would have
> found 'chrp' in the header file as well.
>
> I totally agree that headers are a great place to learn about stuff
> once you know
> what you are looking for, i.e. a function name, constant name or such.
>
> But I've also been bit by searching for something like "special characters"
> and not being able to find it. Once you, or some else, points out the actual
> name of the function or constant its usually "duh, that's an obvious name".
There's a bit of an art to searching the headers. For example, if you're
looking for a command to show the character palette, here are some options:
- Open CarbonEvents.h since that's where the standard general command
constants live, search for kHICommand to find the first one and read through
them.
- Do a partial-word, case-sensitive search of that CarbonEvents.h for
"Character" since it's called the character palette and a constant for this
would probably contain the string "Character."
- If I use the regular expression option in CW to search for
"kHICommand(.*)Character", I get one hit:
kHICommandShowCharacterPalette = 'chrp'
> I'm really not trying to complain about the headers. I like that the
> engineers helped us out by adding the comments that they have. I just have a
> harder time finding what I'm looking for there unless I know the actual name
> of a function or constant.
That's my complaint about the web. Even if I don't have an overly unique
search key, a header search almost always returns a manageable number of
hits. For example, searching the headers for "Character" returns 452 hits, a
large, but manageable number (I can go through them pretty fast, skipping a
lot of them quickly because or the files which contain them). Googling for
"Character" returns 51,000,000 hits. Useless. Searching Apple's developer
site: 5620. Essentially useless.
>
> One of my biggest complaints is that there is still tons of documentation on
> Apple's site that is old, out-dated and no longer valid. It still might make
> sense to have for some developers but I wish there was a way that we could
> limit the docs that we search thru. My way around that is to add the word
> Carbon to most of my searches.
Admittedly Apple's tech pub people have delivered some good docs over the
past year or two, but the documentation situation taken as a whole is still
not good at all.
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
