Shareware Overload/ShartewareOverload.cdr/database/datamage.zip/DOCS.ZIP/APCNMAKR.DOC

Text File | 1991-07-22 | 71KB | 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?