[futurebasic] Re: [FB] Re: Using Apple's "Official" Headers

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : December 2002 : Group Archive : Group : All Groups

From: Heather Donahue <maclists@...>
Date: Wed, 25 Dec 2002 12:57:46 -0800
On 12/25/02 3:15 AM, "Peter Bancroft" <peter@...> wrote:

> Heather
>> The page you linked to is laid out in simple tabular format.  This would be
>> difficult for record structures.  Toolbox functions might be hard to pattern
>> as well.  My first guess would be that the tabular format could contain some
>> data but the full information would have to be linked to elsewhere.
> Those pages are simple because that is the purpose of that particular site.
> I'm not going to try and sell FMP to you, but almost anthing can be done
> using it. For instance, a tabular summary could link to a large page of
> information, ie it is a title of a card in a card index.

That was the point of my reply, that a simple tabular format will be
insufficient and that full or additional information will need to be linked
to another page.  That will also need to be taken into account when
designing the layout.

I has some suggestions for the fields, like Robert Covington did but I
deleted them from my post.  The kind of information that he mentioned would
probably be sufficient, it's just the overall layout that might be

My recommendation would be to have the tabular format like this:

Toolbox/record/constant |            availability               | Apple URL
        Name            | Mac OS X | CarbonLib | Non-Carbon CFM |  <link>

An example result:

       Toolbox        |         minimum availability           | Apple URL
        Name          | Mac OS X | CarbonLib |  Non-Carbon CFM |  <link>
    MoveControl       |   10.0   |    1.0    |InterfaceLib 7.1 |  www.?

Obviously it's possible to have more fields, longer more descriptive fields,
I just didn't want to wrap the page.  OTOH, I think that less data on the
first page is a good idea.  If someone does a search, they are likely to get
many related results.

I would also include a category, such as you did got the ads.  One category
for functions, one for constants and one records, for example.

It's simple and the name field could link to another page that includes full
information.  Obviously some things, such as constants wouldn't require a
full page.  But the second page could include more of the things that RC
mentioned.  I'd also suggest a text field for comments, especially including
the comments that are in the original Apple headers.  Apple's header
comments are becoming _the_ way to find documentation.  They are putting
more documentation in the headers than in the Inside Mac.