SCHEDA 1.3 User's Manual 1 INTRODUCTION The Romans used the word "scheda" (pronounced SKAY-dah) to mean a slip of papyrus. In Botanical Latin, it refers to the label of a herbarium specimen. The preparation of specimen labels is for many botanists one of the most tedious parts of plant collection, since it requires both accuracy and repetition, two attributes that are often at odds. "Scheda ex machina", a label from a machine, approaches this problem by use of the computer, a device that is designed to be simultaneously accurate and repetitive. There are many advantages of using a computer for preparing specimen labels: 1. Information entered for one label can be retained to be used as necessary in others. If it was entered correctly the first time, no errors will be introduced by using it again. 2. Mistakes that do creep in can be corrected easily, before the label is committed to paper. 3. Multiple copies can be produced with no additional effort. 4. Mistakes can be further reduced, and entry speeded, by checking expected information, such as month or state, against a known list, and expanding abbreviations. 5. Information can be retained, to allow the production of additional labels at a later date, and to provide a database of collection information that can be used for other purposes (such as trip itineraries and lists of exsiccatae) in addition to generating labels. Using a computer for preparing labels is certainly not new; the first instances that I know of are from the middle 1970's, and many different solutions to computerized labels have been proposed since then. So why am I offering "yet another herbarium label program"? The original intent of this program was to serve students in beginning plant taxonomy courses. Every other program I looked at had one or more shortcomings for that task: 1. Some were designed for specific mainframe environments, including three different programs I wrote for the CDC Cyber 730. Mainframe programs are not easily portable (even if they are written in a portable language, the job control language necessary to make loading, running, and especially printing transparent to the user is usually machine-specific). Years ago, mainframes were expensive to use, and more recently they seem to be becoming less available than microcomputers. Printers that produce suitable output are often not generally available, even when terminals are. SCHEDA 1.3 User's Manual 2 2. Some were designed more for professionals than students; any program that assumes there will be 10 or more collections from a single site, and that collections will be made from a site repeatedly, isn't designed for the average beginning plant taxonomy student. Especially because the database functions are even more important than simple label production, a program designed for professionals will be necessarily more complex than one aimed at students. 3. A number of the available microcomputer programs are too expensive (if used legally) to provide to entire classes. I am especially thinking of programs written in database languages, such as dBase, that must be used with the database program (one legal copy per student, of course), or else compiled (e.g., with Clipper or Quicksilver, at ca. $500 for the compiler). Less expensive database programs, such as PC- File +, don't have the print-formatting capabilities to easily make traditional labels. 4. Programs relying on database languages are also resource- hungry. Many won't run with less than 384k RAM or fewer than two floppy drives, and some require 512k and a hard disk. Sadly, there are still universities where 256k and one floppy drive is not uncommon. Scheda is designed to circumvent these problems. 1. It runs on any IBM PC, AT, PS/2, or true compatible (including Compaq, AT&T, AST, Kaypro, etc.). 2. It is designed to be easy to use. It does some capitalization and expansion of abbreviations automatically, and it has a simple menu system. It has adequate database functions, but its primary function is to produce labels. 3. It is inexpensive. Although donations are gratefully accepted, you don't HAVE to pay anything for it, an important consideration when you are giving copies to every student in a class of 24, and your university administration has just decided to crack down hard on software piracy. 4. It will run in a machine with 256k RAM (and perhaps less - I haven't tried yet). It is *designed* to work with the program and data files on a single disk. It should work with a variety of printers, and currently has printer configuration files for stupid printers (underlining not supported), backspacing printers, Epson MX, RX, FX, and LX, and HP LaserJet (native font and Y cartridge). It works with either color or monochrome monitors, and in most cases automatically adjusts for that. So that's why I wrote it, and I hope you like it! SCHEDA 1.3 User's Manual 3 FILES AND INSTALLATION The distribution disk contains these files: SCHEDA.EXE The SCHEDA program SCHEDA.DOC This file FIXINDEX.EXE A program to reconstruct damaged index files PCONFIG.EXE A program for modifying the configuration file PRINTER.CFG The configuration file *.CFG Alternate configuration files for other printers Although there is still enough room on the disk for a reasonably large label database, some of these files are rarely used, so it is desirable to make a working disk. Here is how you do it: 1. Make a copy of the distribution disk (e.g., DISKCOPY A: B:), and put away the original. 2. Choose the appropriate printer configuration file and copy it into PRINTER.CFG (e.g., COPY EPSON.CFG PRINTER.CFG). The version of PRINTER.CFG supplied with the program will work with any printer, but it will not perform underlining. If a configuration file is not available for your printer, see the instructions for using PCONFIG.EXE. PCONFIG.EXE also allows you to change the values for the length and width of the paper (as supplied, it is set for a label width of 40 columns and a paper length of 60 lines) and the herbarium name printed at the bottom of each label. 2. Format a "bootable" blank disk, e.g., FORMAT B: /S (the /S parameter makes the disk bootable by writing the operating system on it). This disk will be the working disk. 3. Copy the following files from the distribution disk to the working disk: SCHEDA.EXE PRINTER.CFG (e.g., COPY A:SCHEDA.EXE B:) The directory of the working disk should now show three files, COMMAND.COM, SCHEDA.EXE, and PRINTER.CFG. All the rest of the space on the disk is available for data. To run the program, turn on the computer, put the disk in the A: drive (usually the top or left floppy drive, if there are more than one), and wait for the computer to ask you the current date and time (Scheda does not make use of these, so you can hit the key in response to the questions if you want to). You should then see the "DOS prompt" (usually A> if you are running Scheda as described here). Type "scheda" (without the quotes), and the program will begin. SCHEDA 1.3 User's Manual 4 USING SCHEDA General Design Scheda combines three general functions--data entry, data storage and retrieval, and print formatting. Although the first and last of these are more directly related to the task of labelmaking, the data storage and retrieval are the core around which the rest of the program is built. Like most databases, Scheda stores information in records and fields. Each label represents one record, and the different items that make up a label, such as genus or collector, constitute the fields. There are 22 fields in a single record: Family Genus Species Author Subspecies/variety/forma Infraspecific epithet Infraspecific author Collector Collection number Associate collectors Notes (2 fields) Day Month Year Country State County Location (3 fields) Number of duplicate labels The fields are presented on a data entry screen, where the user fills in the appropriate information for each. The data are then saved on disk in the database. Once in the database, label information can easily be retrieved or modified, and labels can be printed at any time, either singly as data are entered, or all at once when data entry is complete, or even later. The print formatting function of the program takes the data from each record, assembles them in the proper format for a specimen label, and sends the label to the printer, in as many copies as desired. The Menus The functions of Scheda are accessed through menus of the _______type (fill in the name of your favorite litigious spreadsheet company)--the first line presents several choices, with one highlighted. The highlighted choice can be changed with the left and right arrow keys. Beneath this line is a line describing the highlighted choice. To select a menu item, either (a) move the highlighting to the desired item with the arrow keys SCHEDA 1.3 User's Manual 5 and hit , or (b) hit the first letter of the desired choice, whether it is highlighted or not. When the program first starts, the main menu is displayed. It has six choices: Add Allows you to add new entries to the database. Find* Searches for a database entry, so it can be changed or deleted. Print* Prints specimen labels from the information in the database, or prints a species list. Utilities* Exports the information in the database into a file in ASCII format, or imports data from such a file. Data Carry Toggles between retaining or discarding data from the previous label when a new label is added. Quit Leaves Scheda and returns to DOS. The three menu choices marked with an asterisk lead to "submenus"; the submenu appears on the screen in the same place as the main menu, and asks you for additional choices. The other three main menu items lead directly to the activity chosen. Each of these menu choices is described below. ADD When you choose Add, the cursor will move to the first position in the Family field on the screen, and the menu area will be replaced with a somewhat cryptic guide to the editing keys. In general, you can just type in the information (see DATA CARRY below if information is already there). or the down arrow key will move you to the next field. The up arrow move you to the previous one. The up and down arrows will cycle you through the fields: if you are on the last field, down arrow moves you to the first, and if you are on the first, up arrow moves you to the last. On the other hand, if you hit on the last field, the label record will be saved and the program will be ready for you to enter the next label. The other way to save a label is to hit . Whenever a label is saved, a message appears at the bottom of the edit area informing you of that. Hitting abandons a label, and is also the way to get out of the Add mode. Hitting prints the label currently on the edit screen, whether it is saved or not, in as many copies as indicated in the field "How many copies:". Within a field, erases the character before the cursor, erases the character under the cursor, and the left and right arrow keys move the cursor through the field without changing it. -Y deletes everything from the cursor position to the right; this is the simplest way to blank a field. Scheda is designed to simplify labelmaking, and one of the ways it does this is by controlling data entry. This takes two forms, automatic capitalization and automatic expansion of abbreviations. The first character of the Family, Genus, SCHEDA 1.3 User's Manual 6 Country, State, and County fields is always capitalized. If you type in an entry in lower case, you can watch the capitalization happen when you hit or the down arrow to go to the next field [this doesn't always work with Country, State, and County, even though the capitalization does appear in the saved label; this is a "known bug" that will be fixed in a future edition]. The fields S/v/f, Month, and State accept abbreviations and expand them to their full form. In S/v/f, anything you enter that begins with "s" is converted into "ssp.", "v" into "var.", and "f" into "forma" (so you might as well just type the single letter). Month converts either a number between 1 and 12, or the first three letters of the month (capitalized or not) into the full name of the month. Any other input is not converted, so that you may enter the month in a language other than English, or for those of you that collect in the 13th month. In the State field, you may enter the two-letter United States Postal Service abbreviation for the state (upper or lower case, NOT followed by a period), and it will be converted into the full name of the state. Any other input will be unaltered, to allow for political divisions of other countries. You could type in "Massachusetts" instead of "MA", but you are strongly encouraged NOT to do this, because the contents of the State field determine whether the word "Co." (the 50 states except...), "Parish" (Louisiana), "Borough" (Alaska), or nothing (the rest of the world) are appended to the County field. If you type out the long name of a state, you must also type "Co." (or whatever) after the county name. (If you look at the end of the County field on the screen, you will see whichever word is appended to it.) This may seem rather complicated now, but once you get used to it, it will speed up data entry quite a bit. The Country field name is in parentheses on the data entry screen as a reminder that collectors in the United States generally do not enter the country for collections made in the United States. On the other hand, there is no reason not to (I prefer "United States" over "U.S.A"). Notes and Location each consist of more than one field. When you get to the end of the first field, hit to go to the next. Do NOT break a word at the end of a field, either with or without a hyphen; the print-formatting program rearranges these lines into a word-wrapped paragraph on the label, and your hyphen is likely to end up in the middle of a line. [A three-line single field with automatic word-wrap, much like a word processor, is on the list of enhancements for a future version.] The printing formatter automatically underlines the scientific name (q.v.); if you want something in Notes or Location underlined, precede *each* word to be underlined with a \backslash, like this. If you need to use a backslash as a printing character at the beginning of a word in these fields, you are out of luck. "How many copies:" always defaults to one. You may change it to zero if you don't want a label to print. The theoretical maximum SCHEDA 1.3 User's Manual 7 number is 32,767; if you try to print that many and it works, let me know. The Collection # field may not be left blank, and every collection number must be unique; it is used as a "key field" for the database index. If you aren't using collection numbers, you ought to be. I am personally a fan of sequential numbers staring with 1, but the field will accept any numeric or alphanumeric value, as long as no two collections have the same "number". FIND Find allows you to work with label records you have already entered. The first step in doing this is finding a label. Once a label is "found", you can edit it, print it, delete it, or go to the next label or previous label in either collection number sequence or taxon sequence. When you choose the Find option, the cursor moves to the Collection # field and you may enter a collection number to search for. If instead you wish to search for a particular taxon, hit the key on an empty Collection # field, and the cursor moves to Family. Enter the family, genus and species of the label you want to find. In either kind of search, if the specified information is not found, the following label (in collection number sequence or taxon sequence, respectively) will be displayed. Your choice of searching by collection number or taxon will affect the rest of your activities in Find, since it determines which of the two index files, collection number or taxon, will be used for sequential operations. For example, if you searched for collection number 327, and decided to go to the Next label (an option in the Find submenu, q.v.), it would be 328, regardless of taxon, but if you had instead searched for Papaveraceae Eschscholzia californica, and the label the program found happened to be collection number 327, the next label might be Papaveraceae Fumaria officinalis, even if its collection number were 183. Once a label is "found", the program puts you in the Find submenu: Update Edit a label; modify the information it contains. Delete Delete a label from the database. Next Go to the next label, in either collection number or taxon sequence, depending on which you searched for initially. Previous Go to the previous label, in either collection number or taxon sequence, depending on which you searched for initially. Exit Return to the main menu. All choices in the Find submenu return to the Find submenu when they are completed. SCHEDA 1.3 User's Manual 8 Delete, Next, and Previous are self-explanatory. Delete prompts for confirmation before sending your label to the bit-bucket. Unlike database programs such as dBase, once you have deleted a label it cannot be recovered. Update puts you in the same data entry screen as Add, with the contents of the "found" label displayed. The same editing keys are operative, saves the edited label (it replaces the original one), prints it, and abandons the changes. In addition, saves the edited label and goes to the next label in sequence (just as if you had pressed , selected Next, the Update), and saves the edited label and goes to the previous one. This allows you to examine and edit all your labels without leaving the Update mode. You can leave Update mode at any time by hitting . If you change either the taxon name or the collection number, theindex entry will be changed, and the label will immediately occupy a different place in the sequence; keep this in mind if you want to go back to it. You are prevented from changing a collection number to a duplicate of an existing label. PRINT You have already seen how it is possible to print a single label from either Add or Find/Update. Print allows you to print all or selected labels in the database, or to print out a species list. When you select Print from the main menu, it takes you immediately to the Print submenu: Labels Prints herbarium labels, as many copies as designated for every label in the database (0 copies = no label printed). Species list Prints a species list (family, genus, species) sorted alphabetically. Exit Returns to main menu. All choices in the Print submenu eventually return to the main menu rather than the Print submenu (with one exception; see next paragraph). Species list brings up its own submenu: Screen Sends the species list to the screen, one screenful at a time. Printer Sends the species list to the printer. Exit Returns to the Print submenu (this is the one exception). Labels and species lists are produced in a standard format that cannot be altered, with the exception of width and other printing parameters (q.v.). The label format fits my own prejudices of what a herbarium specimen label should look like (although it is not original with me, and has other advocates as well), and the species list follows the format I use for student collections in my California Flora class. If you don't like the formats, see SCHEDA 1.3 User's Manual 9 the section entitled Custom Versions. The label begins with the family name in the upper left corner. I've always been inclined against family names on labels, but it sure makes the specimens easier for unskilled workers to file. Beneath that and centered is the binomial, and if there is an infraspecific name, it is centered below the binomial. Because scientific names are of varying lengths, the binomial may be broken into two or three lines in order to fit all of it between the margins. Following the name is a single paragraph in the following format: COUNTRY. STATE. County.: This part is the specific location, however long that might be. This part is the notes, which might be information about the plant, its site, and its associates. Then comes the date, a blank line, the collector and collection number, and the associate collectors, if present. The last line of the label, centered, is the name of the herbarium, or any other text string you would like it to be (the string resides in the printer configuration file, and is initially blank; if it is left blank, every label will be two lines shorter, in case you need the space). The species list has a header line that says: Species List: Collection of Asa Gray Page 1 assuming that the first label in the database had "Asa Gray" in the Collector field. Following that are the collections; for each collection, the collection number, family, and binomial are presented in tabular form. Print formatting is controlled by a printer configuration file, PRINTER.CFG. This file may be edited with any ASCII text editor (e.g., WordStar in non-document mode) or with the provided program PCONFIG.EXE. See the section Using PCONFIG for specifics. The print-formatting part of the program in this version is not very graceful about recovering from errors; if the printer is offline or not ready, Scheda will translate the error code into English, but will exit the print routine, forcing you to start over after you correct the error condition. This in usually only an inconvenience. However, when Scheda is run on a fast computer (e.g., a 10 MHz AT clone) with a laser printer, it may send data to the printer faster than the printer can handle it, especially during the time between filling the page buffer and ejecting the page. An elegant way of handling this is planned for the next version; in the current version, if you set the page length to 60 in PRINTER.CFG, Scheda assumes you are using a laser printer, and delays for 5.5 sec (about the time it takes an HP LaserJet II to SCHEDA 1.3 User's Manual 10 fill and throw a page) between pages. This does not noticeably slow down the printer, and seems to avoid the problem. UTILITIES Choosing Utilities allows you to import and export the label data in an ASCII comma-separated file format. You are presented with a submenu: Xport Exports the data to a comma-separated file (it's spelled funny so it won't conflict with Exit when you make a menu choice by first letter). Import Imports the data from a comma-separated file. Exit Returns to the main menu. All choices in the Utilities submenu return to the main menu when they are completed. The label database file used by Scheda is not in an ASCII (American Standard Code for Information Interchange) text file format, nor is it in the non-ASCII format used by any other database program (most database programs have their own formats, although many can read or write the formats of others). That means that the only way you can modify or add to the database is through Scheda. There are two circumstances in which that is not possible. The first is if the database file is corrupted, because then Scheda may not be able to deal with it, either (a database can be corrupted by being edited with a word-processor, or by the same kinds of disk errors that corrupt other files and make people wish they had backed them up). The second is if you want to use the data with another program, or if you have data in another program that you want to use with Scheda. Both situations can be covered by providing the data in an ASCII text format. In the first case, the ASCII file provides a backup that can be fixed with a text editor. In the second case, an ASCII file can be a bridge between two different programs. Scheda exports and imports a specific type of ASCII file called a comma-separated file or comma-delimited file. This file type can be read and written by most major database and spreadsheet programs, and can be used by many merge-print facilities that come with word-processors. Unfortunately, there are no rigorously implemented standards for comma-separated files (paradoxically, one major database program that shall remain unnamed cannot re-import comma-separated files that it created itself if the fields contain both imbedded quotes and commas). Scheda implements the following rules, which are the ones that *ought* to be used by all programs: SCHEDA 1.3 User's Manual 11 1. Each record ends with a carriage return/line feed combination (i.e., is on a separate line). 2. All fields within a record are separated by commas. 3. A comma does not precede the first field of a record, and does not follow the last field. 4. Alphanumeric fields are enclosed in quotes (") if they contain an imbedded comma [Scheda encloses *all* alphanumeric fields in quotes]. 5. Imbedded quotes in an alphanumeric field are doubled (""). Scheda can import its own comma-separated files even when they contain complex arrangements of imbedded quotes and commas (if you find a circumstance in which this is not true, please let me know). It is possible, however, that Scheda may not correctly read the comma-separated files created by other programs, and other programs may not correctly read the files created by Scheda, if the other programs do not adhere to the rules above. The situation most likely to give trouble is imbedded quotes, so if none of your labels have fields with quotes, everything should work. When Scheda exports a file, it writes every field of every record in the file, including the "How many copies:". When it imports a file, only those records that do not duplicate collection numbers already in the database are added. Usually this is not a problem, since you are most likely to import into an empty database. Scheda's index files can also be corrupted; they are restored by a separate program, FIXINDEX.EXE, which is discussed in the section "Using FIXINDEX". If both the datafile and the index files are corrupted, and you have an ASCII export file, you are still in business. If you don't, you aren't. DATA CARRY One of the advantages of computer-assisted labelwriting is that information that doesn't change from one label to the next (such as collector, or perhaps location if you collected a lot of plants at one site) can be retained for the next label. This is called "data carry", and Scheda by default always carries all data except the collection number from the previous label. Then, when you are adding records, you only change (or erase) those data items that differ from the previous label. Thus, ordinarily, and Add screen will be filled with data waiting to be changed, rather than blank space waiting to be filled. On the other hand, if most of the information has changed from the previous label, data carry may be more trouble than it is worth. In those cases, you can turn it off by selecting Data Carry from the main menu. It is a toggle; you can turn it back on by selecting it again, and its current state is always displayed above the edit area. Data carry also has an effect on Add if it immediately follows a Find: the data from the last label found are displayed in the Add SCHEDA 1.3 User's Manual 12 screen, rather than the data from the last label entered. Thus, if you want to enter more labels for specimens from a location you have already collected, you can Find one of the earlier labels, and it will be a model for adding more. When Data Carry is off during Find, this feature is inoperative, and if it is subsequently turned on, Add will display the last label entered, rather than the last one found. QUIT Quit takes you directly back to DOS, without asking you for confirmation. It doesn't need to, because when you quit, any records that haven't yet been written to disk are written, the database and index files are closed, and any pages that are still in the printer are ejected. In general, you should avoid leaving the program in any other way except by Quit (such as turning the computer off, rebooting it, or using -C to abort the program). Sometimes you won't lose anything, but you could conceivably lose the last four labels, and if it is the first time you have used the program on a specific floppy disk, and you haven't entered any data yet, it can create data and index files of zero length, which will cause it to crash the next time you use it (if that happens, just delete the files SCHEDAE.DAT, SCHEDAE.IXC, and SCHEDAE.IXN, and try again). MENU TREE Here is a diagrammatic representation of the menu tree: main submenus menu |Add | |Update | |Delete |Find---------------(record search)-----------|Next | |Previous | |Labels |Screen |Exit |Print---------|Species List-----|Printer | |Exit |Exit | |Xport |Utilities-------------|Import | |Exit | |Data Carry | | |Quit Using PCONFIG Configuration files for several popular printers are included with the program; the appropriate one can be copied into the file PRINTER.CFG. PRINTER.CFG can also be edited with a text editor SCHEDA 1.3 User's Manual 13 or word processor that produces ASCII text files (e.g., WordStar in non-document mode). The included program PCONFIG.EXE is a simple text editor with a screen that explains the meaning of each line in PRINTER.CFG. You can begin PCONFIG by typing PCONFIG, in which case it will prompt you for a filename, or PCONFIG fn.CFG, where fn is the name of the configuration file you want to edit. PCONFIG will then present you with this screen: [NOTE: the following section is 80 columns wide and contains IBM upper-ASCII characters. It may not print properly on your printer!] ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ Line 1 Col 1 Insert Indent ³ Form length (lines) Í>³66 ³ Width of label (characters) Í>³40 ³ Use (1) form feeds (2) line feeds Í>³2 ³ Printer initialization string Í>³ ³ Printer termination string Í>³ ³ Begin underline string Í>³27 45 1 ³ End underline string Í>³27 45 0 ³ Herbarium name to appear on label Í>³ex herbario CSPU ³ ³ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ þ The form length for 8« x 11 paper is 66. For laser printers use 60. þ A label width of 35-45 characters is appropriate for pica type. þ Laser printers require formfeeds for starting new pages. Most other printers can use either. þ The initialization string can be used to select a compressed typeface, and the termination string to turn it off. þ Some printers underline by backspacing and overprinting with "_". To select this method, leave the begin underline string blank and set the end underline string to "BS". ^K^D saves file, ^K^Q abandons 21:50 NL ------------------------------------------------------------------------------- The window in the upper right is the edit window, and it behaves like an ordinary text editor (it is in fact the Borland Binary Editor, similar to the notepad in Sidekick). It uses most of the same editing commands as Scheda. In addition, - takes you to the top of the file and - to the bottom. It is possible to shift the file relative to the edit window and its guidelines; if this happens, - should straighten it out. The guidelines to the left of the edit window tell you what each line of the configuration file does, and the suggestions below help you decide what values to use for your specific printer. The file shown above is EPSON.CFG, for an Epson MX/RX/FX/LX series printer. The herbarium name is the one that I use. SCHEDA 1.3 User's Manual 14 Values for the printer initialization string, printer termination string, begin underline string, and end underline string are entered as the decimal codes for the ASCII characters, separated by spaces. Your printer manual will supply this information. The numbers to use are the same ones it tells you to use in a BASIC chr$() function. The code for "escape" (or "esc") is 27. PCONFIG (and Scheda) will allow you to enter up to 255 characters total of numbers and spaces, but especially long underline strings may interfere with centering and word fill. Notice that the initialization and termination strings are blank. This is the accepted way of telling the program not to tell the printer to do something. If you are using continuous-form herbarium labels, you must accurately calculate the form length in lines, and set the new page method to "line feeds". If the form length is off, successive labels will not line up properly with the paper. Currently there is no provision to prevent two very short labels from printing on the same form, but they would have to be *very* short. On the other hand, if a label is longer than the form, it will continue to print onto the next form, and when it is complete, the printer will advance to the top of the following form so that the rest of the labels are lined up. The resulting long label will have a peforation running through it, but it will still be usable. NOTE: Scheda assumes that species lists are printed on 8« x 11 paper. If the form length in PRINTER.CFG is 60, it is assumed that you are using a laser printer, and the same form length is used for species lists. If the form length in PRINTER.CFG is any other value, species lists are printed with a form length of 66. If you make a change in the file that Scheda cannot recognize (for example, a letter instead of a number), Scheda will inform you that the file is corrupted before it displays the opening screen, and it will use defaults that are similar to the supplied PRINTER.CFG. Using FIXINDEX A database file without both index files is useless to Scheda, even if all the data are intact. Since a change of a single character could corrupt an index file, it is important to have a way of recreating index files from an intact data file, and FIXINDEX is the tool to do it. SCHEDA 1.3 User's Manual 15 You will know that you *probably* need FIXINDEX if you don't have current backups of your files and if: 1. Scheda won't load, and gives an error message in a box, alluding to a file TACCESS.ERR. 2. Scheda loads, but the data seem garbled or in the wrong fields. 3. Everything looks OK until you try a Find, and then the program crashes, again with an error message. So this is what you do: 1. Copy all the data and index files to a backup disk (e.g. COPY SCHEDAE.* B:). 2. If you have an up-to-date ASCII export file (SCHEDAE.CSV), delete SCHEDAE.DAT, SCHEDAE.IXC, and SCHEDAE.IXN, run Scheda, and select Utilities/Import. This almost always gives the cleanest fix. 3. If you don't have an up-to-date export file, delete files SCHEDAE.IXC and SCHEDAE.IXN and run FIXINDEX. Just type in the name at the DOS prompt--either it works or it doesn't. 4. If it claims that it succeeded, run Scheda and see if everything looks all right. 5. If it says it failed, or if Scheda still won't deal with it, copy the files you backed up in step one back onto the Scheda diskette and call in your local computer wizard, because you are in trouble. In tests, FIXINDEX always worked when the index files of an intact data file were deleted, so if it doesn't work for you, chances are you data file is messed up, too. There is nothing untrustworthy about Scheda; it is as reliable as most database programs, even ones you pay big bucks for. I provide these solutions to you because accidents do happen, and I don't want you to lose your data. But if there is a moral to this story, it is BACK IT UP, Back It Up, back it up... SCHEDA 1.3 User's Manual 16 TECHNICAL NOTES (Don't stop reading this unless you are really bogged down) System Requirements: IBM PC, XT, AT, PS/2, or true compatible (if it runs Sidekick, it will run Scheda). Any video card that supports the IBM upper-ASCII character set (which is just about every thing, including MDA, CGA, EGA, PGC, VGA, Hercules, AT&T, etc.) 256 kbytes of available random-access memory (RAM). One floppy disk drive. A printer. Scheda is designed to automatically detect and identify the video card in you computer. If it detects a color card, it uses colors in the screen displays; if it detects a monochrome card, it uses the two intensities of white (or amber, or green...) on black, and inverse video. If you have a black-and-white monitor attached to a color video card, or a portable computer with an LCD screen, Scheda will not know that the monitor cannot display color, and the screen display may be illegible. If this happens, run Scheda by typing: SCHEDA /B The /B parameter will cause Scheda to display in black-and-white no matter what kind of video card it detects. Scheda creates three different files as a normal part of its operation: SCHEDAE.DAT database file SCHEDAE.IXC collection number index file SCHEDAE.IXN taxon name index file All three files are created on the default directory of the logged disk drive. If the files are renamed or moved to another disk or directory, Scheda will assume they do not exist and create new ones. Yes, I could have made it more flexible than this, but the program was intentionally designed to work off of a single floppy disk, and by doing it this way, the user has one less thing to worry about (but see Custom Versions). Scheda also creates a fourth file, SCHEDAE.CSV, when label data are exported. Only SCHEDAE.CSV can be successfully modified with a text editor; the other files may only be accessed through Scheda (see Using FIXINDEX). Scheda and its associated programs are written and compiled in Turbo Pascal 5.5. SCHEDA 1.3 User's Manual 17 REVISION HISTORY Version 1.3, 21 July 1989 - The county name did not print if the state was not entered as a two-letter abbreviation. That effectively precluded using the county field for political subdivisions outside the United States. The problem was fixed. Version 1.2, 21 October 1988 - Unnecessary blank lines were removed from label output and the label printing routine was modified to account for individual labels that are longer than the form length. Version 1.1, 14 September 1988 - The ASCII import/export routines were modified to work with comma-separated files. Version 1.0, August, 1988 - The first distributed version, following beta testing by the students in my California Flora class (thanks!). LICENSE AGREEMENT This program is not in the public domain. It is copyrighted by the author. You are encouraged to give out copies of this program, since one of its purposes is to make computer-assisted labelmaking widely available. There are only three restrictions on your use of this program: 1. You may not distribute an altered copy of the file SCHEDA.EXE. 2. You must include with every copy either this file or a printed copy of it. Students may not want the complete package, including PCONFIG.EXE and FIXINDEX.EXE, but everyone should get the documentation. 3. You may not charge anything for the program, other than a disk fee not to exceed $1.50, nor may you include the program with any other program which is sold. Your use of the program constitutes your agreement to abide by these simple restrictions. SCHEDA 1.3 User's Manual 18 $ $ $ $ $ You don't have to pay anything for this program. If you don't like it, you can erase it. If you do like it, you can use it as long as you want, and if you never pay for it, your cosmic karma will remain unscathed (if you're using it, you're doing botany, and that elevates your karma considerably). If you would like to make a contribution, it will be gratefully received. For any contribution over $15, I will send the latest version of Scheda, along with some other programs I've written, and some classic and indispensable public domain and freeware utility programs that I've collected. Please send donations to: Curtis Clark [ ] [ ] IMPROVEMENTS PLANNED, SUGGESTIONS WANTED I intend that the next major version of Scheda will have better recovery from printer errors, some sort of global search and replace, and better printer support. I also hope to improve the reading and writing of comma-separated files (the current program code is *not* elegant). I would appreciate any generic Pascal routines that could accomplish these objectives, especially the comma-separated files; I've been known to re-invent the wheel, but I would prefer not to. I would also like to hear of any bugs (or "undocumented features") you encounter while using the program, and any suggestions you have for improving it (somebody already suggested a Macintosh version; as soon as Borland comes out with Database Toolbox for the Mac and someone buys it for me, I'll Get Right On It...). I don't always respond to U.S. mail, more often to E-mail (and I'm not always easy to reach by phone), but I will try to get back to you, and if I especially like your suggestion, I'll send you a copy of the version that includes it. Send suggestions to: Curtis Clark Biological Sciences California State Polytechnic University Pomona CA 91768 (714) 869-4062 BitNet: cbbq010@calstate SCHEDA 1.3 User's Manual 19 CUSTOM VERSIONS So maybe you don't like the label format, or you want an opening screen that says "provided to the students of Botany 47 by Professor Doe" or you have some other special requirement. No problem! Send me your specifications for a customized version, and I'll give you an estimate. Prices are very reasonable, and satisfaction is guaranteed. MORE LEGAL STUFF The computer programs SCHEDA, PCONFIG, and FIXINDEX, their associated files, and this documentation are copyright (c) 1988 and 1989 by Curtis Clark. Scheda and Fixindex use the Turbo Pascal Database Toolbox, copyright (c) 1985, 1987, by Borland International. Pconfig uses the Borland Binary Editor, copyright (c) 1987 by Borland International. Sidekick is a trademark of Borland International. WordStar is a trademark of MicroPro International Corporation. IBM, PC, XT, AT, and PS/2 are trademarks of International Business Machines Corporation. "Scheda", a term commonly used by Botanists Internationally, cannot be trademarked.