Black Box 4

home *** CD-ROM | disk | FTP | other *** search

/ Black Box 4 / BlackBox.cdr / database / datamage.arj / DOCS.ZIP / APCNMAKR.DOC next >

Wrap

Text File | 1991-07-22 | 69.5 KB | 1,308 lines

DATAMAGE - APPLICATIONS MAKER INTRODUCTION: There are those who would call doing what you may do with APPLICATIONS MAKER, as what you can do with dBase, etc. PROGRAMMING. These people, evidently, do not know what programming is. I do. And I would liken both dBase and APPLICATIONS MAKER to writing batch files for MS-DOS. Placing a band-aid on a cut on your head does not make you a brain surgeon. Folding a piece of paper into an "airplane" and flinging it does not make you a engineer/pilot, etc. This is not to say that programs like APPLICATIONS MAKER have no validity; were that true I would not have taken the time to write it. The facility of such a program is the origination of small, inconsequential (though useful) APPLICATIONS without taking the time to write a real program, or to learn how to use a real programming language. Let's take a typical application as a case in point. It loads a datafile, allows the user to select a MARKER file, then creates a simple report from the records in the marker. Let's say that you are a professional programmer, like myself. Just for the sake of argument. Though I have megabytes of code I have already written it would take me a couple hours to produce a program to do what the sample application does. I would need to "round up" code to load a file, control the screen, load the marker, and finally write a little code to print the report. Then I would need to compile, test and debug it. Not to mention having the SKILLS to do same. Working with APPLICATIONS MAKER I would be able to originate the application, test and complete it within ten minutes. After you master this DECEPTIVELY easy applications generator you will be able to do the same, in the same time. Going on the assumption that your are not a programmer APPLICATIONS MAKER will prove to be all or (more likely) MORE than you can handle. Though there is no syntax to learn, no text file to write and no compiler to master, you will STILL need to organize what you want to do and initialize input/report items to get your job done. I have made it as easy for you as I can. But, in order to give you what you need I have been obliged to give you the ability to totally ruin your datafiles. There's NO WAY to have the former without the latter. MODES OF OPERATION and COMMAND LINE ARGUMENTS: APP MAKER can be started with the full pathname of it's target application following the program name on the MS-DOS command line. If it is it will go directly into execution mode. When the APP runs to completion or ends with an error the program will terminate. This will facilitate the use of APP MAKER from a batch file or as a menu option of your fave menuing system. It will also deny keypunch help the opportunity to enter the edit mode and, perhaps, ruin your application. The remainder of the command line arguments pertain to the handling of the screen. If you don't want color use the BW (or bw) argument. All of the arguments can be in either case, in any order. If you will be running APPLICATIONS MAKER under a multi-tasker (windows, double-dos etc.) you will need to use the NO argument. This will disable the writing of data directly into the video ram, which would mess up your pretty screen. If you are using a C.G.A. display you will need to use the CGA argument. These old-style color displays need special treatment when placing data into the screen memory, and this argument enables it. The NO argument above over-rides the CGA argument, you need not use them both. When APPLICATIONS MAKER is started from the GO program it will pass this information along. You supply the command line arguments to GO, it supplies them to APPLICATIONS MAKER, which is the only program in the system that makes use of them. If you are obliged to use these special-purpose arguments all the time it may become rather borsome. You can make a batch file to do it for you. Call it GO.BAT. If there is a program and a batch file with the same name MS-DOS will pick the batch file to execute. Let's say you need the BW argument to run APPLICATIONS MAKER on your monochrome computer. You would enter COPY CON GO.BAT and press return. Then enter GO.EXE BW, followed by holding the control key down and pressing the Z key. Then hit return. MS-DOS responds 1 FILE(S) copied. Now, when you type GO, the batch file executes, executing GO with the command line argument. You must take care never to suply command line arguments to GO that are not listed above, i.ie BW, NO or CGA. If you do this and opt to run the BASE program the illegal argument will be interpreted as the name of a MACRO to be executed. PROBLEMS WITH I.O.C.B. ALLOCATION IN LARGE APPLICATIONS: An I.O.C.B. is an input-output control block. This is an area reserved in low memory, for the use of MS-DOS. These areas are used for open files, and their number is controlled by the FILES command in your CONFIG.SYS file. Simply put, it is necessary to have an available I.O.C.B. for each open file. APPLICATIONS MAKER can have up to thirty-four files open at once. But we'll also need an I.O.C.B. for both screens, the keyboard, each line printer attached to the system and each of the devices attached to com ports (like modems, laser printers, mice etc.). And one to load/save the application, and to read any menu files you may choose to create/use. The default value for the FILES command is eight in DOS 3.3. To allow your computer to open more files you either create or modify your CONFIG.SYS file to contain the FILES command. To use APPLICATIONS MAKER at it's full capacity (which, in many cases, is not necessary) you would include these two lines in your CONFIG.SYS file: FILES=40 BUFFERS=40 Don't over-do it, here. Use only the number of files based on what you will need, as increasing the capacity for open files also decreases the memory available for your programs and data. The CONFIG.SYS file is read as the final stage in the BOOT (or startup) process. The computer allocates it's I.O.C.B.s and buffers accordingly, and there is no way to change these parameters once the system is up and running. HOW THE PROGRAM WORKS: In any program such as APPLICATIONS MAKER the general idea is to write some EXTREMELY generic functions and allow the user to call them and supply parameters to them. The user originates only the top-level control structure, the rest is supplied to him. This is why applications take up over twice the program space required by a real program, and why a real program will execute up to ten times faster than an application. All the other applications generators, like dBase, require you to learn their (would-be) language, and to write a syntactically correct text file in order to do the most rudimentary things. The amount of "dues" you have to pay before you can get anything from such a system is totally out of line with what can be done with it. And such a format bars all but the most patient and computer- literate from making use of the system. DATAMAGE, on the other hand, does most things with no setup at all. There is NEVER a syntax to learn, nor a text file to write. These requirements make it more difficult for me, the author, and FAR EASIER for you, the user. That's all right - I ENJOY doing this. Different strokes, for different folks. If you can read this text you already understand the format of the applications you will originate. You started reading this at the top, working your way down from left to right, line by line. And that's EXACTLY how APPLICATIONS MAKER will execute your application. By making use of a format with which you are already familiar you are freed of most of the work of learning the system, and you may concentrate on the logic of your application. This not to say that you will need to learn nothing before using APPLICATIONS MAKER. You will need to know many things: What a datafile is, what a record and a field are, the details of YOUR datafiles and the information they hold. DATAMAGE is designed to teach you this BASIC knowledge as you use it. That's a lot better than your having to learn it BEFORE you can use it! If you have mastered the BASE program you already know what you need. If you have not, please stop, here, and start there. Any attempt to use APPLICATIONS MAKER without a thorough knowledge of datafiles, etc. is bound to fail. APPLICATIONS MAKER uses two screens. The initial screen displayed holds the functions you use, in the order that you use them. The secondary screen holds the report items you select, in the order in which they will be executed. The report is optional - you don't have to print anything. There are twenty-six basic functions on the input screen. These functions range in scope and complexity from the simple placement of a heading on the input or report screen to the finding of a record in a file. There is nothing here that you can't understand. From my point of view, this program is so easy as to be comical. You may find the going tough. The key, here, as in LIFE in general, is to believe in yourself. You don't have to be a programmer. You don't even need to be particularly intelligent. Just start off by doing the simple things you found in the tutorial. Then, working from there, experiment around a while. As you do this you will learn what a datafile is, how it's organized, how to use the FILE indexes to find records, how to select records on the basis of their content, etc. With DATAMAGE you work your way up through the system. APPLICATIONS MAKER is the top level. It's successful use depends upon your having learned what the preceding parts of the system have to teach. Your knowledge is like a snowball rolling donwhill. It can't help but grow! APPLICATIONS MAKER took two years to implement. It could have been done in two months, were a lesser program acceptable. There are many features included in the program to make it usable by the neophyte. There is always a prompt, in plain english. Provided you have familiarized yourself with the rest of the system you should be able to originate applications without reading these docs. There is nothing new, here, in terms of function. All the capabilities of APPLICATIONS MAKER appear in other programs, with the possible exceptions of menu fields, browse keys and the ability to make use of multiple printers. In terms of methodology, however, APPLICATIONS MAKER is totally new and radically different. If there is a program that you can use, this is it. INITIALIZING YOUR SCREENS: The size of both screens is specified during the definition of the application, but they are initialized a little differently one from another. The INPUT sub- screens are of a fixed width: seventy-eight characters. You may use up to one hundred sub-screens in your application, and direct control into any of them. The REPORT, however, does not have a fixed width. You may have a wide-carriage printer; you may opt to use different print pitches. If your printer supports fifteen characters per inch and your paper is eight inches wide your report could be one hundred twenty characters in width. The report width can be set to whatever value you desire. When you begin a new application you will be prompted for the number of SUB- SCREENS comprising the INPUT screen, and the number of COLUMNS on the report screen. These may be INCREASED at any time by editing the application, but the screens can never get any smaller. In order to quickly display and use your screens they are created when the application starts. This necessitates the provision of a space to store the screens. Storage of screens is usually done in the computer's memory in order to provide quick access to the data. The screens may be up to 7,800 characters in width and 1,900 lines tall. Each character requires a byte to hold it plus a byte to hold it's attribute. Simple multiplication of these three numbers gives us 29,640,000 bytes of storage space for EACH screen. Since PC hardware running MS-DOS provides only 655,360 bytes of memory it is easy to see that storing the screens in memory is impossible. But if you have a 60 megabyte hard disk to spare you can use APPLICATIONS MAKER to it's full potential. Most real-life applications use no more than ten screens horizontally and vertically. Most computers can furnish 592,800 bytes of disk space. Since you may use the same screen files for all of your applications this is a realistic situation, and you won't find yourself out of disk space. When you begin a new application you must enter a path/filename for the screen files, which will be kept on disk. Suggested is the /MAGE/DBSEFILE directory created by the DATAMAGE installation process to hold data imported from dBase formatted datafiles. If you have a RAM DISK on your AT system, in expanded/extended memory, you can make good use of it to store your screens. This will result in very fast screen access. As of version 3.5 DATAMAGE does NOT have multi-user capabilities. This means that the system runs on ONE computer and the programs within the system can NOT handle the access of datafiles by more than one user in a simultaneous manner. Multi-user capabilities are planned for version 4.0. For now, all of your applications can use the same screen files. These files will be of the size of your largest application, and if they are used by an application that requires less disk space then only the first part of the file will be used. Doing this will save you lots of disk space if you run several applications. USING APPLICATION MAKER SCREENS: The screen is divided into two windows: the upper data display area, and the lower dialog box. In the dialog box you will see information relevant to the operation of the program. In the data display area you will find your application; this is where the work will be done. While running the program you will often see choices in the dialog box. A brief heading will be on the left, then the choices available will be listed with one choice highlighted. You may press the number key associated with your desired choice, or use the arrow keys to highlight the item, then hit return. At times the program will display options in the dialog box. An example is: Insert Delete Write Quit. To select one of these options you press the capitalized first letter of the option; to get Quit press Q. NAVIGATING IN THE SCREENS: APPLICATIONS MAKER uses your standard PC editing keys to navigate. The four arrow keys will move one position in any direction. When the control key is held down and an arrow key is hit you will move one full screen in any direction. When the shift key is held down and an arrow key is hit you will move approximately one quarter screen in any direction. CHANGING SCREENS: Pressing S or s will TOGGLE THE SCREEN. This switches the display between the INPUT and REPORT screens. The screens are just alike, so be certain to check the upper left corner of the dialog box before taking action. Help for the report screen is available by pressing H from there. MAKING and TESTING YOUR APPLICATIONS: Your method of origination not withstanding, it is necessary to create a test environment in which to test and debug ANY new program/application. Right now there is a 720K disk in my drive B: that is being used to test APPLICATIONS MAKER. It is my test environment. I can totally blow this disk away and I won't care at all. I will just re-format it, copy the datafiles I am using onto it, and start again. No damage done. If I blew out my hard drive I would need to spend several hours after re- formatting it to replace my compilers, libraries, source code, word processor, com program etc. OF COURSE it's all backed up - my father raised no fools! But, who needs the grief? What I do with the C language and what you may do with APPLICATIONS MAKER are two VERY different things. I will not give you the ability to zap your disks. But your DATAFILES are another story. Whether or not they will survive is up to you. IF they do it will be because of care and planning on your part. CREATING YOUR TEST ENVIRONMENT: NOBODY (including myself) writes code or makes applications that work, first time, requiring no testing/debugging, etc. And nobody in their right mind tests programs/applications that change the data in their source datafiles on their only copy of a real datafile. It just isn't done. Try it, and you'll find out why very quickly! Do you have car insurance? Fire/theft insurance on your home/possessions? YOU BET you do! Everyone makes a mistake, and things happen. Your car/home represent a major investment on your part, as the data in your files represent the investment of someone's time to enter it. DATAFILE insurance costs no money, just a little time. PLEASE take the time to "buy" it! To make a test floppy simply take a blank floppy and make directories on it that share the names of the directories holding the actual datafiles on your hard drive holding the data you will access with your application. Let's say you have a CUSTOMER file and a INVNTORY file, in directories with those names. Place the blank floppy in a drive. Make that drive the default. If you're using drive A:, then enter A:. Now, from the A: prompt, enter MD CUSTOMER, then MD INVNTORY. Enter DIR. You should see two directories on the floppy. Now, depending upon the capacity of your disk and the size of your datafiles, you may not be able to write the entire datafile onto the test floppy. If your files are few and small, or your disk capacity is large, simply enter COPY C:\MAGE\CUSTOMER\*.* A:CUSTOMER, and COPY C:\MAGE\INVNTORY\*.* A:\INVENTORY. You just copied the datafiles onto the floppy, and you are ready to go. Your test disk now holds all you need to do your application. In the case where the total disk space occupied by all your target datafiles exceeds the total space available on the floppy you can use the BASE program to select a group of records in the files that you feel are representative and will fit on the floppy. The fewer these records the better. As you develop and test your new application it will run faster, reports will waste less paper, etc. To do this, enter COPY C:\MAGE\CUSTOMER\*.SAD A:\CUSTOMER, then COPY C:\MAGE\INVNTORY\*.SAD A:\INVNTORY. You have just moved the datafile DEFINITIONS onto the floppy. Now, start DATAMAGE in the normal manner and select option four, POWER COPY. Select CUSTOMER as the SOURCE file and opt to move records in a marker file. Select your marker made for this purpose, opt for automatic segment pairing on absolute field numbers, then hit F9 to execute the move. A datafile on the floppy with only the records in the marker will be created. Repeat this process for the second datafile, and so on. CREATING AN APPLICATION: It's REAL handy to have a FILE MAP of each of the datafiles you will use at hand while originating the application. APP MAKER displays the fields in the file and allows you to choose one MOST of the time. The exception to this rule is when you are entering a formula. Since you may use any field in any file in your formula it is, at that point, impractical to display the files window. To make a FILE MAP you simply load the target file with the BASE program, hit F3, ready your printer and remove the paper. If you have taken my advice and created a test environment on a floppy you need not load the file on the floppy to make the file map. Making one from the real file on the hard disk will produce the same results, except for the pathname atop the printout. Now, at long last, you are ready to start the APPLICATIONS MAKER program. To do so, start DATAMAGE in the normal manner. Select option six from the system menu. After the program loads you will see the initial menu. Select option two, create application. The program will read the datafiles it finds on drive C:. The entire point of making the test environment is NOT to use these files. So, press your escape key. The screen will clear and you will be prompted for the path of the data which you wish to access. Enter A:. The program will display a menu of the datafiles it finds on your test floppy. Select the files you will use, in any order. When you have selected all your files, or have selected the maximum of eight files, your screen will clear and you may start work on your application. When you save the screen the names of the files you loaded will be the first thing written to disk, followed by your input screen items, then your report screen items. You should save your application often while making it. You can test-execute your application right from the edit screen by pressing T or t. The test will allow you to verify that things are happening as you wish. You will also need to exit the APPLICATIONS MAKER environment and use the BASE program to verify that any/all file updates or records created contain the correct data. Please check your applications over carefully as to verify the validity of your processes. When you are CERTAIN that your application works as you desire you copy the APL file you made into one of the datafiles on drive C:. To select the application from then on you first select that datafile, then select the application from a menu of the applications recorded in that datafile. The first time you access the application from the hard drive you will need to change the path/file names of the datafiles you are using. As you may have noticed, this facility is provided as the files are loaded by the edit option. As each of your files appears on the screen opt to edit the filename. It the example above the name of the first file will appear in the dialog box. It will read A:\CUSTOMER, or A:CUSTOMER. Press home to move your cursor to the first of the string, then replace the A: with C:\MAGE\. After converting your filenames press W to save your application. Now your application will run the datafiles on drive C:. INITIALIZING INPUT ITEMS: To place an item on the input screen you use your arrow keys, page-up, page- down, home and end to locate the cursor at the position on the screen where you wish the item to appear, then press return. To edit/move/delete an item on the input screen you place the cursor in any space occupied by that item and press return. You may also view the status of any screen item in this manner. Here is a listing of the functions available. These are the building blocks from which you may construct your applications. INPUT ITEM TYPES: The input screen can initialize five types of items: DATA, HEADING, CONTROL, FILE and MISCELLANEOUS. DATA TYPES: If you opt to initiate an item of type data the program reacts by opening a window and displaying the files you loaded in your application. By selecting a file from this menu you are specifying to the program that the data entered/placed into this input item is to be written into the file in the field you choose from the next window. You may have input items that are not written into the new record. These items may be for the purpose of display, calculation, or data written into a relational file. To bypass the selection of a field in the main datafile press escape. At this point the program must determine the type of input item you are initiating. If you selected a file and a field this information is at hand and already in the computer's memory. If you pressed escape to signify an item not written into a file the program will prompt you for the type of item. After nailing down the type of input item the program displays the options available for that item. DATE ITEM OPTIONS: ENTRY: User enters date. READ: Date is read into item from relational file. Before readn and the program will continue. If your user fills a field or fields declared as indexed NON-UNIQUE, or some but not all of the fields declared as CROSS-INDEXED and a match is found the record will be displayed on a screen similar to the record access screen in the BASE program. Your user will then view the record. After pressing Q to quit the record your user will have the option of accepting the record displayed, or continuing the search for the desired record. If a record is not found the program will offer your user the option to retry the search, or to quit. If your user opts to quit the search the program will offer to find the record on any of the modes above. If your EXPANDED KEY item has a label to handle bypasses your user will have the option to continue, if not the continue option will be replaced by the option to abort. If the abort option is selected the APPLICATION will end with an error. KEYS NOT FOUND: Any of the KEY TYPES may fail. Your user may enter data into a key item that is not found in the target file. Or your user may BYPASS the key item by simply pressing return on it. The KEY ITEMS have the built-in option to handle bypasses by either branching to a label, or aborting the application. This is defined during the initialization of the KEY item. In the event of your user entering data that is not found the program will not halt, but will display five options to deal with the situation: RETRY, CONTINUE/ABORT, EXPAND, BROWSE and ENTER RECORD. If your KEY ITEM has a label to go to on the bypass of that item the second option offered to your user will be CONTINUE, else the second option will be ABORT. RETRY will allow your user to try the KEY entry again. ABORT will end the application and CONTINUE will bypass the item. EXPAND Will allow your user the option to search the file on RECORD NUMBERS, or the FILE INDEXES. If the FILE INDEX option is selected ALL of the indexes will be available as search targets. BROWSE will produce and fill the BROWSE WINDOW, and allow your user to video- select his record from the file. ENTER RECORD will allow your user to enter a new record into the target file. This record will then become the source of the data read/written to/from that file. KEYS, WRAP-UP: As you can see, APPLICATIONS MAKER provides many ways to do a LOOKUP. There is NO other data program that offers this power and flexibility while finding records in relational files. STATIC: A static string field is left alone. It is the equivalent of a COMP field in the numeric type. You may use this type of string field as the target of a string formula, covered under it's own heading later on. NUMERIC ITEM OPTIONS: ENTRY: User enters number. READ: Number is read into item from a relational file. AUTO-FILL: A value entered during setup is placed in the item. AUTO-INCREMENT: All records in the target datafile are read to determine the highest value stored and the value found is incremented by a value entered at setup. The item is filled with the result. MENU: The numeric menus are just like the string menu items; see above description. The only difference being that the second value for each selection, which is returned to the application, must be a number. FORMULA: If you initialized a numeric field you will have the option of applying a formula to it. The formulas all start with the value placed into the item, be it a keyboard entry, a read from a relational file or the content of another field, perhaps itself the product of a formula. If a formula field is declared as editable the edit will take place after the formula has been executed. Formulas are covered under their own heading a little later in these docs. COMP: Comp fields are left alone. They may be filled via a formula. DATA TYPES, WRAP UP: READ ONLY ITEMS: All types except entry can be protected from edit by the user. You will be prompted for the accessibility of each new item as you initialize it. RELATIONAL WRITES: When a relational write is used the data it contains is stored in the computer's memory. It remains there until a REL WRITE input item is executed. This is necessary as your application may be aborted by the user, encounter an error, etc. If your application terminates (or is terminated) prematurely you would have a merry old time finding and backing off the changes you made to the relational files! All DATA types can be written into up to ten relational files. You will be prompted during the initialization of the data items for the file, the field and the write mode. The writing of relational items to VARIABLE fields within a file is also supported via the placement of the desired field number in an element of the USER NUMERIC ARRAY. This comes in handy for doing relational writes from within loops. READ/WRITE MODES: The string mode can either over-write and destroy the current content of the target field or be appended (added to the end) to the current entry. The numeric mode allows for addition to, subtraction from, multiplication or division by and replacement of the current value. In order to be certain what will be written into a write field you must remember that the write takes place when fill the item. So, whatever is stored in the file buffer when the item is executed is what will be written to the record in the relational file. PRINTING DATA ITEMS ON YOUR REPORTS: Input DATA items may be placed on the report. The final prompt in the process of initializing a screen item provides this ability. If you opt to print the screen item your screen will TOGGLE into the report display and your cursor will be full like it is when you are moving an item. The items can also be moved to the report by pressing return with the cursor located anywhere on the desired item, then pressing 6. To place the input item on the report all you need do is position the cursor where you want the item to print and press return. After placing the item you will specify right or left justification of the data within the space you have provided for it. String data is usually left justified, while numerics right. HEADING TYPE: Opting for a heading causes the program to allow the entry of a heading. The heading and it's location are stored as a screen item and the count of screen items selected is incremented by one. CONTROL TYPES: LABEL ITEMS: The labels establish a position on the screen to which you may go. The labels can be duplicated. If you use a GOTO ITEM to branch forward to a label the program will search for that label from wherever you are on the input screen. If it is not found the application will end with an error. The same for a GOBACK ITEM, but the search is done BACKWARD from wherever you are. GOTO ITEMS: The gotos cause the screen to branch FORWARD to a label. BREAK items will also be found by forward gotos, but GOBACK items will find only labels. GOBACK ITEMS: The gobacks cause the screen to branch BACKWARD to a label. These items, when used in conjunction with or as an argument of an IF ITEM, will allow you to create loops. In the jargon of programming a LOOP is a series of instructions that are repeated while/until a test evaluates true/false. LOOPS can be very useful. They can also create LOCKUP if their test never evaluates as planned. If this happens to you just hit your escape key to halt the application. IF ITEMS: The IF ITEMS provide the ability to do a set of operations IF a certain requirement is met. The targeted data is TESTED to determine whether or not the requirement is met. If it is the IF is said to EVALUATE as true and the operations are executed; if not the IF is said to EVALUATE as false and the set of operations will not be executed. This is known as CONDITIONAL processing. STRUCTURE: The structure of the IF ITEMS is identical to the same structures in any other program. In the jargon of the programmer, ARGUMENTS are parameters supplied to a function. The ARGUMENTS for the IF ITEMS consist of a CONDITIONAL argument which defines the test to be done, and up to ten EXECUTION ARGUMENTS which are to be carried out if the test evaluates as true. DEFINING THE CONDITION TO BE MET: The IF ITEMS can compare any of the three basic data types in DATAMAGE files. You may compare numbers to numbers (dollar-formatted fields are numbers), dates to dates or numbers or strings to strings. All three data types may also be compared to CONSTANTS, which are values that you include in the IF ITEM. You may NOT, however, compare dates or numbers to strings, or vice-versa. SYNTAX OF THE CONDITIONALS: Yes, this is one of two places within the DATAMAGE system where you will be required to enter SYNTAX, or commands that conform to a specified format. But the claim that a DATAMAGE user need NEVER learn SYNTAX is not false; the SYNTAX is supplied to you on your screen during the entry of the IF ITEMS and FORMULAS. Your entries are SYNTAX-CHECKED during both entry and execution of the IFs and FORMULAS, and appropriate error messages are displayed should you make a mistake or, for example, attempt the division of zero. COMPARING NUMERIC DATA: Numeric data may be stored in a field within a file, an element of the USER- ARRAY, or included in the IF ITEM. You may compare any of the above to any of the above targeting on equal, less than, greater than, or not equal. COMPARING DATE DATA: When we begin comparing dates we have a slight problem. You may be prone to enter dates in the formats: MM/DD/YYyy (normal) or DD/MM/YYyy (military). When entering dates into DATAMAGE fields the format is displayed for you, and detectable errors are met with a beep, and the return to the entry of the date. When creating your IF ITEMS this is, of course, not available. This situation will NOT DO! When dates are compared within the DATAMAGE system the software converts them into numbers. You may have noticed that the BASE program can sort a datafile on a date field in a hurry; this is how it's done. This date format is commonly called a METRIC date. Let's consider the date: 01/02/91. If it was stored in a field whose format was MM/DD/YY, this date would represent Jan. 1, 1989. On the other hand, if this date were recorded in a field whose format was DD/MM/YY, this date would represent Feb. 1, 1991. Note that omitting the first two digits of the year will cause the software to assume that you mean 1,900 and whatever is present. For this reason the DATAMAGE system is no good for recording dates before the year 100 a.d. (Sorry, history buffs.) In order to convert this date to an ABSOLUTE value we first process the year. The 91 is stripped from the end and, since it is less than 100, 1,900 is added to it. the result of this is 1991. Now, the software selects the month, be it in position 1 and 2 or 4 and 5. Assuming the more common MM/DD/YY format, the O1 is added to the end of the 1991, giving 199101. Now, we do the same for the day, giving 19910102. Finally, this string is converted to a number. When you enter date CONSTANTS within your IF ITEMS you MUST use the METRIC date format. This may be a small inconvenience for the short period that it takes to get used to it, but it will save many errors. It should be noted that this is necessary only when CREATING an application, and is not supported when entering data into the program. You may also compare date fields to values in the USER-ARRAY. These values must also be in the METRIC format. You can use a numeric field with the auto- fill option to get the date into the USER-ARRAY, where it becomes available for use as a target of date or numeric comparisons. This process may be the ARGUMENT of an IF ITEM, giving you the ability to use different comparison dates as needed. COMPARING STRINGS: Strings may be compared in all the normal manners: equal, greater than, less than and not equal, plus one more that is unique to the string comparisons: contains. If the contains operator ( is used it always looks for the second string (on the right of the operator) within the first string. If the greater than or less than options are used the result will be according to alphabetic order. No, you can't use APPLICATIONS MAKER to sort your datafiles - the BASE program performs that function rather handily upon up to eight targets of the same or mixed data types. You may then create a MARKER FILE that makes the product of the sort available to APPLICATIONS MAKER. CONSTANTS may also be incorporated into your string IF ITEMS, but the space provided for them is significantly less than the maximum length of a DATAMAGE string field, which is 250 characters. In the rare case of needing to use a string CONSTANT that is longer than the space provided you're out of luck. When comparing strings APPLICATIONS MAKER always removes all the spaces from both targets and converts all the upper case letters to lower case. Thereby using the CONTENT of the string and ignoring it's case and spacing. EXECUTED ARGUMENTS: Legal EXECUTED ARGUMENTS for IFs are EXECUTE FORMULA, DO, DO PRINT, GOTO, GOBACK, ABORT and KILL RELATIONAL WRITES. The GOTOs, GOBACKs and ABORTs must be the LAST argument of the IF item as they terminate the IF. Any arguments following these items will NOT be executed. Care should be taken in using the ABORT option of the IF items. This will abort the application! If you have used the REL WRITES item to store interfile updates they will NOT be executed. If your application keeps running totals etc. they will not be listed. The application will stop dead. If you desire only to abort the current iteration of a repetitive application (such as one that enters records) you should simply branch to a label past your write record and rel writes. This should offer the user the option to enter another record (by entering 1), or to quit (enter 2). The result of this numeric screen item should be placed in an element of the user numeric array via a formula, then tested with an IF item. The KILL relational writes argument is provided for this eventuality. If your application has made use of the REL WRITE item to store interfile updates to be executed at a later time (when the record is completed) you will need to delete these relational writes when you branch to the next iteration of your repetitive application in order to prevent their execution the next time a REL WRITE item is encountered. The KILL argument will also obviate any/all DO statements in effect. If the KILL is encountered within a DO statement the program will need to negate the effect of that DO so that the next BREAK item will not send control of your application back to the item proceeding the DO. This will work no matter how many levels of DO are currently in effect, including recursive DOs. If there is any possibility of branching to the next iteration of a repetitive application you should also take care concerning whatever running totals you are keeping. This can be accomplished by placing the data for the running totals into another element of the user numeric array, then adding it into the running total after the last possibility of aborting the record has been executed. Compound IFs, block IFs and IFs with ELSE arguments all evaluate to a series of simple IF/GOTO operations, as do SWITCH (C), SELECT CASE (BASIC) and CASE OF (PASCAL). If you do not understand what I am talking about, here, don't worry about it. If you do then you should already know how to do these constructs with IF/GOTO. Simply put, there are many times when you want to execute operations only if a multiple test evaluates true. For example, you might wish to update a file if the record being entered is a sale AND the purchase is being charged. To do this you might reverse your tests. The first IF might test for the record NOT being a sale, then branch around the file update. The second IF might test that the purchase is NOT a charge, then branch around the file update. There are also many times you want to execute an operation if one of several tests evaluate true. You might wish to abort a record if it is a charge and the customer has no credit OR is at/over his credit limit. This is easily done by testing for no credit, branching to the abort. Use a second if to test for over credit limit, branching to the abort. Or reverse your tests and branch around the abort. There may be times when you wish to get at the ABORT and KILL options without a test. These items are almost always the result of a condition in your application, but, due to the structure of your logic, they may occasionally be needed as stand-alone functions. To do this you must initiate an IF, as these items are available only as arguments to IFs. Just type as the test of the IF: U1=U1. The first element of the user numeric array will (hopefully) always equal itself, so the arguments will always be executed. I am not writing a textbook on programming here, nor ever will I do so. APPLICATIONS MAKER is written for those who need to produce simple applications in order to do their work and are possessed of little or no programming ability. By providing and explaining the more intricate features of real programming languages I would totally confuse such a person. If you are a programmer you should look in the \MAGE\DOCS directory and find sample source code, in BASIC and C, to process DATAMAGE files. Due to it's six byte reals PASCAL is not equipped to handle these files. DO ITEMS: The DOs cause the screen to start execution at the first occurrence of the target label, and to continue until a BREAK ITEM is encountered. The DO and DO PRINT items will start looking for the label at the beginning of their respective screens. When you define a DO item on the input screen you are, in effect, defining a FUNCTION that your "program" may call from anywhere within the input screen, including from within the function itself. A function that calls itself, in the jargon of the programmer, is called a RECURSIVE function. Many real programming languages do not allow this. If you are going to use DO items to create and call functions, especially recursive ones, a programming method called "top down" is highly recommended. To do this you define all functions before they are called. Just place a GOTO item as your first screen item, and use as it's target label the place in your screen where you wish execution of your "program" to start. And place that label at the start of your control routine. Between the initial GOTO item and it's target label place all your functions. When you use a DO item to call a function you will go to the FIRST occurrence of that label. If it's atop the screen you may re-use that label later without worrying about losing control. Each time a DO item is encountered the program uses a little memory to record DO's location so you can return when the BREAK item is executed. If your computer has less than the full compliment of 640K, or your applications are extremely large you should watch using recursive DO functions, as they may cause you to run out of memory. If this happens the program will recover by displaying the (DREADED) out of memory error, and terminating your application. This has yet to happen, but it could easily occur on a computer with 384K, and might happen up to 512K. DO PRINT ITEMS: The DO PRINTS cause the screen to start report execution at the first occurrence of the target label on the report screen and continue until a BREAK ITEM is encountered in the report, or until the report ends. BREAK ITEMS: The BREAKs will cause the screen to return to the item after the DO which caused their execution. If the DO was an argument to an IF the remainder of the arguments to the if will be executed. If no DO is in effect when a BREAK item is executed it will be ignored. BREAK items are also the target of forward gotos. BREAK items appear on both the input and report screens. END ITEMS will halt execution of the application. LOCATE ITEMS: With the LOCATE ITEMS you may control your screens. APPLICATIONS MAKER screens may be up to 100 screens wide. You may choose to use implement an application that uses ten horizontal screens. Each of your ten horizontal screens might be a task within your application. You will need to be able to control the execution of your application so that it goes to the start of the desired sub-screen, and then works it's way down while staying within that horizontal boundary. This is the purpose of the LOCATE ITEMS. The first option of the LOCATE items is to BEGIN or RELEASE the enforcement of the horizontal boundaries. If you use a DO to execute a function in your application and that function is located outside the horizontal boundary you have specified you will need to release the LOCATE ITEM currently in effect. When you complete the task associated with the horizontal section of the application you may wish to go back to the first screen and display a menu item so that the user may select another task, or exit. Again, you will need to release the current LOCATE. If you do not the application will end with a LABEL NOT FOUND error. Whey you BEGIN a LOCATE you enter the vertical row and the horizontal column of the upper left corner of the screen you desire to execute. The program then displays your screen, at that row and column. The LOCATE ITEM also causes the program to ignore any LABELS not within the horizontal limits you specify. If you use GOTO, GOBACK or DO items they will not find LABELS whose horizontal position in the application is not within the boundaries specified. Your screen WILL find items whose vertical position in the application is not on the same visible screen as your starting point. So, you may scroll the screen vertically to any position you wish within the horizontal limits you set. FILE ITEMS: GET RECORD ITEMS: The GET RECORDs will cause the next available record in the targeted file to be read into the file's buffer. The data it contains will then be available for use. If you have loaded no MARKER FILE these items will read all the records in the file. If you have used the LOAD MARKER ITEM (below) these items will read the records in the MARKER FILE, in whatever order they're in. The GET RECORD ITEMS take a label as an argument. When all the records have been processed (end of file or marker) the GET RECORD ITEM will do a forward goto, branching to that label. WRITE RECORD ITEMS: The WRITE RECORDs will cause the data in the buffer of the targeted file to be written to disk into the record from which it came. These items differ from the RELATIONAL WRITES in that the write happens whenever the item is encountered and an entire record is written instead of a single field. Their use can cause you trouble if your application terminates prematurely due to an error. Your file has been updated and the rest of your application, after the error occurred, did not happen. So, place WRITE RECORD items as near as possible to the end of your application. NEW RECORD ITEMS: The NEW RECORDs will trigger the creation of a new record in the targeted file. Your user will need to select, or allow the program to select, a record number for the new record. The NEW RECORD item MUST be used in applications that write new records into datafiles. Failure to do so will cause the first or current record in the file to be over-written when the write is executed. When NEW is used the first available hole in the file (caused by record deletion) or new disk space for the record is read into the file's buffer and any data it may contain is replaced by spaces or zero. So, use NEW items at the top of your screen, or at the top of the segment of your "program" that creates a new record. The NEW must be executed before any of the fields in the new record are filled. Using NEW after some of the fields are filled will WIPE THEM OUT. Use a WRITE RECORD item when you have placed the necessary data into the record, to record it to disk. RELATIONAL WRITE ITEMS: The RELATIONAL WRITEs will cause the execution of the relational writes stored in memory for the targeted file. These relational writes are created when the WRITE TO ANOTHER DATAFILE option within data items is used. Unlike the WRITE RECORD item, these items will not be executed until the RELATIONAL WRITE is encountered, presumably as the last step in your process, and only a single field is written as opposed to an entire record. So, if your application ends with an error, nothing is changed. If you update file five, field seven, then use that file/field again before you execute the RELATIONAL WRITE the new value will be used as the list of relational writes is searched before data is read from disk. Like the DO items the RELATIONAL WRITEs use memory to store their file, field, new value and update mode. And they could exhaust available memory if not properly managed. So, if your application is cyclic and updates files via these items you should place a RELATIONAL WRITE item for each file updated near the end of the cycle to conserve memory. If the application bombs these writes will not be executed, and you're in trouble again. RESET FILE ITEMS: The RESET FILEs will cause the file to be reset to the first record. If you have used the LOAD MARKER FILE item to load a marker for the file the marker file will be closed, and you will be able to load another marker or process all records. It is not necessary to use this item just to close a marker. LOAD MARKER ITEMS: The LOAD MARKERs will cause the loading of a MARKER FILE written by the BASE program in the targeted file. These MARKER FILES give you the ability to process a pre-defined group of records in a pre-defined order. After executing a LOAD MARKER the GET RECORD items will fetch the next record from the marker instead of the file. When initializing a LOAD MARKER item you may select a MARKER FILE from the menu of the markers present. You may also press escape to bypass file selection. You will then have the option to allow the user of your application to select the a marker from that same menu. This is handy to do a report or operation on a group of records selected at runtime. MISCELLANEOUS ITEMS: CHECK INPUT ITEMS: The CHECK INPUTs will cause the program to display the input screen for the user. The page-up, page-down (etc.) keys will be active and the user can view the entire input screen via their use. No changes can be made to the input screen. The user may opt for OK or ABORT. The CHECK INPUT items take a label as an argument. If the user opts to abort the input, presumably due to a keying error, the application will do a forward goto to that label. BLANK INPUT ITEMS: BLANK INPUT ITEMS: With the BLANK INPUTs the input screen will be renewed. The data entered will be replaced by the squares you see when the application is loaded. You may wish to balnk only a certain portion of your application's input screen. To support this you will be prompted for the beginning and ending line (vertical) and screen (horizontal), thusly creating a box within your application in which all items will be renewed. CHECK REPORT ITEMS: The CHECK REPORTs will display the report as the CHECK INPUT items display the input. As with the CHECK INPUT items, a label on the input screen is required as an argument. The application branches to this label if the user aborts the report. These items also take a label on the report screen. The report is made starting at this label and continues until the next break item on the report screen or the end of the report. If the user OKs the report it will be printed from the CHECK REPORT screen. There is no need to use a DO PRINT item after the CHECK REPORT item, unless you want two copies of the report. BLANK REPORT ITEMS: With the BLANK REPORTs the report screen will be renewed. The data on the report screen will be replaced with the spaces you see when the application is loaded. Like the BLANK INPUT items you may specify vertical and horizontal limits within which to blank your report. Unlike the input screen, the report is of varying width. Therefore you will need to specify the beginning and ending COLUMN (vertical) of the area to blank. It should be noted that each item on the report screen is blanked with SPACES just before it is filled by the program. If your report uses GOTOs to branch around some of it's items you will need to use a BLANK REPORT item to remove the data they may contain from the preceding report, as they may not be executed. DEBUG ITEMS: The DEBUG ITEMS are for the purpose of halting your application during testing and displaying the contents of the USER ARRAY or the USER STRING ARRAY. These storage areas, or arrays of VARIABLES, are covered in detail in a proceeding section. They are used to store your data in the computer's memory. There are many times while doing a program or application when something isn't coming out right and you wish you could see what one of your variables contains at a certain point. You can always initialize a data item and set it equal to the desired variable, then place another data item directly after it that requires you to press return to continue, thereby stopping the application. But, depending upon how you have organized your screens, there may not be room for this method and it requires more work than simply placing a DEBUG ITEM at the place in your application where you wish to view your variables. The DEBUG items are meant to be used during development. Presumably you will remove them from your finished application. Each DEBUG ITEM allows you to view the contents of and give names to the variables in the USER NUMERIC ARRAY or the USER STRING ARRAY. If you wish to view/edit both arrays you may place two debug items, back to back. The DEBUG ITEMS are also available from the edit screen as a keystroke. Pressing D will display the contents of the variables after the test-execution of your application. COLOR ITEMS: With the COLOR ITEMS you may create a rectangular area on your input screen that displays the foreground and background colors of your choice, provided that you have a machine that can display color and that you have not started the program with the BW command line argument. The COLOR ITEMS are unique in that they are ignored during the execution of your application. They are executed only during the LOADING of the application, and can NOT be used to change the color of an area on the screen while running your application. For your convenience the COLOR ITEMS are placed on the screen when initialized, and removed from the screen when deleted. You should take care when using these items. If you define a small color box, then a larger color box than infringes upon or covers it you will spoil the first box. You need to define your color areas so that any boxes within boxes are found during loading after the larger box. Failure to do so will result in a mess. As in the execution of the applications, the loading takes place from top to bottom, right to left. You should define your color boxes first, then place your data/heading items within them. You CAN do it the other way, but it will be more difficult and take more of your time. If you wish to add color areas to an application you may locate your cursor on the items they contain, opt to MOVE them then press return with the cursor in the same position. You will then have the opportunity to adjust the color of the item without re-initializing it. NUMERIC STORAGE AND CALCULATIONS: THE USER NUMERIC ARRAY: One of the major differences between an applications generator and a programming language (in my mind, at least) it the ability to allocate the computer's memory to store data. APP MAKER is of the former type, but you may use two thousand six hundred and eighty bytes. This user memory is divided into two sections, the first to store numbers and the second to store string data. You may not specify how many items you can store, nor the type of data they will hold. An ARRAY is like a pile of papers. With APP MAKER numeric array you have one hundred and fifty pieces of paper, neatly stacked. But they are small, big enough to write down only one number on each sheet. To determine WHICH piece of paper you will write to/read from it is necessary to use a SUBSCRIPT. The subscript is, itself, a number. In this case it must be between one and one hundred fifty. It matters not if you conceptualize this as the first piece of paper being on top, or on the bottom, as long as you don't change your mind after you decide which way you will look at it. The subscript 1 will access the first piece of paper, and 45 the forty-fifth. The user array can be accessed only via the formulas, but any element thereof may be placed on the report screen. To set user array element 20 you would use a formula item on the input screen, say "=#8>u20". This would place the value now stored in file one, field eight into the twentieth element of the user array. You could also use >+ to add the value to the current content of this element, >- to subtract it, etc. To use the data contained in the user array you must, again, use a formula. The formula "=U45>f5#9" would fetch the number stored on the forty-fifth sheet and place it in file five, field nine. As before, you could use >+ to add this value to the field's current content, and so on. NUMERIC FORMULAS: The formulas available for crunching numbers are business oriented, and lack the ability to do fancy math which seldom, if ever, has any relevance in the processing of accounting-oriented data. The idea, here, is to give you access to each and every numeric item while making it as easy and understandable as possible. This is the hallmark of the DATAMAGE system. The formulas may contain two basic types of items, as well as user supplied literals. The formula items are: OPERATORS and IDENTIFIERS. The former causes something to happen, the latter defines on what data processes are carried out. IDENTIFIERS: #, Uu, Cc. #: The pound (or number) character is used to denote a field within a datafile. By placing #22 in a formula you direct input/output from/to field twenty-two. WHICH file the program will act upon will be covered shortly. Uu: The U identifier directs input/output from/to an element of the user numeric array. By placing U22 in a formula you specify the twenty-second element of the user numeric array as target of the operation. Legal arguments to the U operator range from one to one hundred fifty, as there are one hundred fifty elements in the user array. Cc: The C operator accesses one of the two possible counters that may be stored in a MARKER file written by the BASE program. In order to use these values you must, of course, load a marker file containing counters, then read a record from that marker file. OPERATORS: + - * / > Ff. The first four operators should be familiar to you, with the possible exception of the *, which has replaced the X as the symbol for multiplication. The > operator, in this case, does NOT relate to comparison based on the second value being greater than the first. The formulas do no comparisons; the IFs do that and, in an IF, the > sign means what you're used to. In the formulas the > is the symbol to direct output. It can be used anywhere in the formula, as many times as you like. The F operator might be considered an identifier except for the fact that it's affect remains until you use another F operator, or the formula ends. With APPLICATIONS MAKER you may load and process up to eight datafiles. You will, then, need a way to specify which of the files you wish to access at any given time, and this is the purpose of the F operator. If you omit the F you are going to use the first file loaded. After including an F in your formula it sets the file. By placing F4 in your formula you select the forth file loaded. Any # or C identifiers placed after the F operator will operate from the fourth file. To specify different files just use another F operator. EXAMPLE: =#4+u34+c2*F4#3/8>+F2#2 This formula would fetch the value of the current record in file one, field four, add to it the thirty-fourth element of the user array, add to that the value stored in counter two of the current record in file one, multiply that by field three in the currently loaded record in file four, divide that by eight, add that to the second field in the currently loaded record in file two. As you enter your formulas you will see a screen that lists the above information. After you press return your formula will be checked. If it has detectable errors an appropriate message will appear and you will resume editing your formula string. If you need to give up just hit escape to blank the input, then press return on an empty string. You should have at hand a FILE MAP for the files you are using in your application. In this way you'll know where your data is. The file maps are printed by loading the file into the BASE program and pressing F3. They will save you a lot of grief. STRING STORAGE AND MANIPULATION: THE USER STRING ARRAY: The string storage space works like the numeric array except that there are twenty elements having a maximum length of seventy-four characters. Twenty may not seem like many, but the APPLICATIONS MAKER program operates with that number of general-purpose string areas. The string space is provided for you to combine and process strings. You may have a datafile that holds three fields: city, state and zip code. If you were obliged to print these areas individually you would have undesirable spaces between them. By applying a STRING FORMULA you may create a field that contains all three of their values without the intervening spaces. STRING FORMULAS: The string formulas are as above, but, obviously, you can not subtract, multiply or divide strings. You may add them to the current content of the target, or you may replace the current content of the target. Your target may be a field in a datafile or an element of the string array. You may place your string array element on your reports by positioning your cursor on the report screen and option for data, then selecting the user string array as the source of the item. It may appear left or right justified. You may encounter errors when processing strings. Perhaps the most common is field overflow. If you add one string to another and the resulting string exceeds the seventy-four character limit your application will crash with an error message. If you attempt to place a string into a field in a datafile that is longer than the field you will copy only the allowable length. This will NOT cause an error, as it is sometimes desirable. You might also attempt to place a string on your report that exceeds the space you have allotted for it. This, as the overflow, is an error that will not happen every time, in every record. Some records containing shorter strings in their fields than others will cause them to work OK. But, when you run into a record or records that have the full allowable strings stored your application will crash. Please see the section above on testing. APPLICATION REPORTS: To help you keep track of your applications the program prints a handy little report detailing input screen if activated from the input screen or the report screen if activated from there. This printout details each of the items you have selected, in the order found. The data for each is the same that is displayed when you place the cursor on that item and opt for status. SCREEN COLORS: When creating or editing an application on a machine that has the ability to display color and provided you have not started the program with the BW command line argument, you will have an opportunity to select the default colors for the screen border and data display area, and the dialog box. The program clears the data display area and fills it with the words: THIS IS WHAT THE TEXT WILL LOOK LIKE. The dialog box will hold the instructions on how to change the colors, which is accomplished via the arrow keys. You may also use the B key to select/deselect bright text. Applications that have been created with the use of color may be executed on computers that can not display color, in which case they will appear in black and white. They can be edited and re-saved. When moved back to a machine that can display color the colors you selected will still be present. The colors, of course, can NOT be edited on a machine that can not display color. BEYOND THE CAPABILITIES OF APPLICATIONS MAKER: This program, like any other of it's ilk, will take you only so far. There are many things that it will not do, many processes that it will not support. It is designed for the purpose of allowing the user to implement simple, mundane processes. It is not a programming language by ANY stretch of the imagination. It is a simple and easy applications generator, that's ALL. Unlike the rest, DATAMAGE does not limit you to what may be done from within the system. In the C:\MAGE\DOCS directory you will find sample source code, in BASIC and C, that addresses the loading and processing of DATAMAGE files. First off, you learned the BASE program. But it wouldn't allow you to design your screen, or to produce a custom report. It wouldn't allow you NOT to write a new record into a file, to make process loops, to directly place data from the relational files onto your screen or report, or to control what happened and when in many cases. So, you moved up to APPLICATIONS MAKER. And there is only so much that can be done with it. Each step of the way LESS was done FOR you, and more power/responsibility was placed into your hands. There is yet another level. It is REAL COMPUTER PROGRAMMING. And the DATAMAGE comes complete with some code with which you may start. It's not as hard, dry, or booring as some might have you believe. I find it to be the most fascinating and truly addictive thing my life has revealed. WRAP-UP: Like I've said before in these docs: I'm not about to try and teach you how to "program." WHY is that? Well, first off, I'm too busy trying to teach myself, and probably will be until the day I die. But there is more to it than that. My mind is not your mind. My logic is not your logic. I can take you only so far. I can flap my wings like crazy and you will notice that my body lifts off the nest. But, when it comes time for YOU to fly, you're just plain going to have to do it for yourself. You are going to have to do it YOUR WAY! I could easily have invented some jobs, then written MY WAY of doing them as THE WAY to do them. That would be a lie, and very counter-productive, as well. There are as many ways to write a "program" as there are people capable of writing it. What is the best way? THE WAY THAT WORKS FOR YOU! ONE MORE THING: (a personal comment) Recycled computer paper has recently become available in all shapes and sizes. I am using it, it works, and other than it's vanilla color (caused by NOT bleaching it and, thereby, not making dioxin to poison our planet) it is exactly the same as the virgin paper I used to use. When I am done with it I carry it to the recycler. I refuse their paltry payment. Let them keep the money and become more profitable. PLEASE, please, please use recycled paper! There are only so many trees and we are now taking them down far faster than they can replicate themselves. The trees separate the carbon dioxide from the oxygen in our air - they recycle these gases for us so we can live. Might we not do the same for them?