Shareware Overload/ShartewareOverload.cdr/database/datamage.zip/HELPFILS.ZIP/AM_CTR_T.HLP

Text File | 1991-07-02 | 17KB | 316 lines

APPLICATIONS MAKER - HELP FOR CONTROL TYPES

The  CONTROL  ITEMS relate to the program flow, or control,  of  your
application.   They may be of nine types:  LABEL, GOTO,  GOBACK,  IF,
DO, DO PRINT, BREAK, END and LOCATE.

LABEL ITEMS:  With the LABEL ITEMS a position on the screen to  which
you may go (or BRANCH) is established.  The labels can be duplicated.

GOTO ITEMS:  With the GOTO ITEMS the application will branch  FORWARD
to a label.  BREAK items will also be found by forward gotos.

GOBACK  ITEMS:   With the GOBACK ITEMS the  application  will  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.    Each
individual repetition of a LOOP is called an ITERATION.

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  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 perform another iteration (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.  (DO ITEMS are coming later.)

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.

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 iteration 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 operation.

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:  With the DO ITEMS the application will 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 recursion.

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 application 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  448K,  and
might happen up to 576K.

DO  PRINT ITEMS:  With the DO PRINT ITEMS the application will  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:  With the BREAK ITEMS the application will 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: With the END ITEMS the execution of the application halts.

LOCATE  ITEMS:  With the LOCATE ITEMS you may control  your  screens.
APPLICATIONS  MAKER  screens may be up to 100  SUB-SCREENS  wide  and
tall.  Each SUB-SCREEN is 78 columns wide and 19 lines tall.  You may
choose to use implement an application that uses ten SUB-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  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.

When you initialize a locate item you are prompted for the SUB-SCREEN
then  the vertical line within your application at which you wish  to
locate the screen.

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.