Click above to get retro games delivered to your door ever month!

  When submitting code for the Nanforum Tooklit Library, please
  observe the following rules and formatting:

   1. Please format your headers exactly as shown in the samples.
      A good deal of time went into the creation of a program to generate
      this Norton Guide.  By submitting your headers in the requested
      format, future versions of the library can be released much more
      quickly then the first.

   2. Include at least one example of your function, no matter how
      trivial or obvious it may be.  An example is worth a thousand words.

   3. Enclose all references to parameters within angle brackets, ie:
      <nElements>.  The NG generator program will automatically
      highlight parameter references in the "Arguments" section.

   4. Do not put any blank lines between $sections$, the NG generator
      will insert them as needed.  Blank lines are ok within sections.

   5. The $ONELINER$ field must be no longer than 60 characters.  It is
      intended for a brief description of the function only.

   6. All fields except $FUNCNAME$, $CATEGORY$ and $ONELINER$ can
      contain as many lines as necessary.

   7. The $ARGUMENTS$ and $DESCRIPTION$ fields should contain blank lines
      between paragraphs or argument descriptions.

   8. The $RETURNS$ field is only necessary for functions.  If your
      submission is a command, omit this entry.

   9. The $INCLUDE$ field is for the name of the header file, if any,
      that is required for the use of your function.  Generally this
      will apply only to commands.

  10. The $SEEALSO$ filed is for the names of related functions or
      commands, and is used to generate the "See also:" references in
      the Norton Guide.  This field is optional and may be filled in by
      the librarian or documenter.

      If a $SEEALSO$ entry contains two or more words, enclose the
      entry within quotes, ie:

            $SEEALSO$
               "MENU TO" FT_MENUTO()

  11. It is preferable to have only one function per file, except for
      STATIC functions or internal support routines.  Do not document
      STATIC or internal support functions with a standard header
      (although they should be documented with comments).

      If it is necessary to include more than one "PUBLIC" function in
      a source code file, do not duplicate the initial file header (the
      one with the "File...." and "Author...." fields).


      Thank you.