Each of Searchlight's parameters is explained below, with reference to the clickable example code in the left frame: you can click a parameter from the example code to jump to its explanation, or simply read this page from top to toe.

Three of Searchlight's six parameters have a default setting which is mentioned below. If the default setting is the option you'd like to use in your own implementation, you can leave that parameter out of your HTML code.

The 'Archive' attribute & 'CabBase' parameter
JAR (Java ARchive) and CAB (cabinet) files are archives containing Java class files in compressed form, making them easier to handle and quicker to download. Most modern browsers are able to read one or other of these formats, and the Archive attribute and CabBase parameter tell the browser the name of the archive file to open. The .JAR, .CAB and .CLASS files must all be in the same directory, and the CODEBASE= attribute is used in the normal way, if required, specifying the absolute or relative location of this directory. Older browsers that are unable to read either the JAR or the CAB file will instead read the loose CLASS files.

Copyright
This parameter must be included or the applet will not run, whether registered or unregistered. To prevent mistakes we recommend that you copy/paste it into your code from the Getting Started page: it is case-sensitive, single-spaced throughout and should appear on a single line. If there's a problem with this parameter, you'll see a status-bar message that reads "Copyright parameter missing or incorrect" which should lead you to the problem.

ShowShortURLs
There are two possible values for this parameters: yes, or no, and neither is case-sensitive. The default is yes. When Searchlight displays the results of a search, it creates a list based on your Name parameter, if you chose to enter one. If you chose not to use Name parameters, Searchlight will list actual URLs instead. However, Searchlight's space is limited, so a long URL will often be truncated. By setting this parameter to 'yes', Searchlight will display only the filename of any documents containing matches for the search. If you opt for 'no', and the full URL would be too long to display, Searchlight will display a string in the form filename at hostname (such as document.htm at www.coolfocus.com). For many users, when testing relative URLs on your own local system, the hostname will be blank.

Target
Determines the name of the frame or window into which Searchlight should open documents clicked on the search-results list. The default is _top, but you would usually wish to set the name of a main frame in your frameset, where Searchlight is in a smaller frame. If you enter a name that doesn't exist within a frameset, your browser will open a new window instead, assign this name to it, and continue to use it when further search results are clicked.

URL1, URL2, ... URLn
If you opt not to use the SingleSearch parameter, there are the all-important parameters that determine which documents Searchlight should search. These URLs may be relative (such as "../docs/index.htm") or absolute (such as "http://www.server.com/docs/index.htm"). Note that these URL parameters must end with a filename - Searchlight cannot work from a directory name only.

You may enter as many URL parameters as you like, increasing the number suffix as you add more. However, try to ensure that no numbers are missing. Searchlight will read these numbered parameters in numerical order; if 6 sequential numbers are missing (for example, you have no URL10, URL11, URL12, URL13, URL14, URL15 parameters), it will stop looking for more. The order in which you list the numbered parameters in your code makes no difference to whether Searchlight will operate or not though, and there is no 'search priority' tie-in at work. However, the order in which you number the URL parameters does determine the order in which search results are listed. If you'd prefer all results to be listed alphabetically, for example, number each URL/Name pair accordingly.

Bear in mind that if you enter any absolute URLs, your browser will try to go online to retrieve and process the documents they refer to when you refresh it. Relative URLs can be easily tested offline, providing your local directory structure matches that of your web server.

If a document referenced by a particular URL cannot be found (due to spelling, removal, etc), Searchlight will ignore it and continue.

Name1, Name2, ... Namen
The number suffixes in this parameter work hand-in-hand with the corresponding numbers of the URL parameters. The Name parameter allows you to specify a name for the file in the corresponding URL parameter that should be displayed in the Search results list in place of the URL itself. It's preferable (although not necessary) to use the Name parameters, as explained in ShowShortURLs above, but remember that Searchlight's width is fixed and ensure that the names you enter are not too long to be displayed in full.

If the Name parameter is not included for any (or all) of your URLs, Searchlight will display the URL instead, according to the details in ShowShortURLs.

SingleSearch
Although the description below is long, please bear with it - this parameter is extremely easy to use!

This single parameter can take the place of the multiple URL and Name parameters. The benefits of using this parameter, along with additional tips, are explained in SingleSearch Tips. Rather than requesting Searchlight to read and catalog each of your HTML pages individually (requiring a separate URL connection to be made each time), in SingleSearch mode you create a single file and copy the contents of those separate files into it and then tell Searchlight to search this single file instead. To this file, you add 'pointers' that tell Searchlight where to find the individual files when somebody wants to read one (the equivalent to the URL parameter) and the names you want Searchlight to use in its Results list (equal to the Name parameter).

The value for the SingleSearch parameter gives the location (if necessary) and name of the SingleSearch file that contains all the text to be searched and cataloged. If this parameter exists, it overrides any URL or Name parameters you've included. In other words, you can't use this parameter and the separate URL/Name parameters.

A typical (if small!) SingleSearch file might look something like this:

<HTML>
<HEAD>
     <TITLE>My First Page</TITLE>
</HEAD>

<BODY>
   //
   // the body of your page...
   //
</BODY>
</HTML>
^firstpage.htm
^My First Page
^


<HTML>
<HEAD>
     <TITLE>My Second Page</TITLE>
</HEAD>

<BODY>
   //
   // the body of another page...
   //
</BODY>
</HTML>
^anotherpage.htm
^My Second Page
^

Notice those bits in bold type at the end of each 'page'? These are the vital 'pointers': after copying the contents of a page into the SingleSearch file, these 3 pointers must be added, and each must be on a separate line and in the correct order. Each must be prefixed with the ^ symbol (usually SHIFT+6). There can be as many blank lines between each 'page' as you like.