
FIRST STEPS FOR CONVERTING S'87 APPS TO CLIPPER 5.X
( For New Clipper 5 users )

Aside from the benefits of lexical scoping, which are
considerable ( taken as a whole ), there are many practical
reasons for converting existing, working S'87 apps to
Clipper 5.x, especially if future development is in
progress or anticipated.

Two major reasons are: the improved debugger; and access to
the many new 3rd party libraries with features not
available to S'87 developers.

If the program runs flawlessly in S'87, then if it is TOO
HARD to convert it to Clipper 5.x, we just WON'T DO IT.
But if we could find a relatively easy way to get the
system converted, the clients MIGHT SPRING FOR IT.

First step.  Create function/procedure names for each prg,
( to later compile with the /n switch)  circumventing the
implicit function/procedure designation, and thus enabling
the filewide delcaration of MEMVARS & FIELDS in  the third
step. Be sure to terminate the function/procedure with a
RETURN /RETURN NIL statement.

Second step. Compile all modules with the /n switch ON and
the /w switch OFF.  Believe it or not, the Clipper 5
compiler catches lots of errors not caught by the venerable
and reliable old S'87 predecessor.  Correct all the errors
first.

Third step.  Run the system through a documentor program
or other utility which will create a data dictionary
containing each and every FIELD in the system.  SORT and
PRINT a list of fields, showing database name as well.
I use DOC for this step. Use whatever works.

Fourth step.  Compile each module with the /n/w/v/a/b
switches set, and redirect the output to a file called
progname.err ... FOR EACH MODULE.  Repeat: get rid of
ERRORS first.  Edit the text of the .err file, aligning the
key words vertically, one over the next.  SORT THIS LIST
on KEYWORD.  These are the ambiguous tokens, assumed to be
memvars (mostly).  PRINT the list. QEDIT/TSE will sort on
columns, Multi-Edit will not.

Fifth step. COMPARE the list of WARNING keywords with the
FIELDS list, and highlight the FIELD keywords in the
WARNINGS .err file with a marker.  Now, edit the .prg, and
insert FIELD DECLARATIONS for all the highlighted keywords.
Beneath that, insert MEMVAR declarations for the rest of
the keyword warnings.  This is done just above the first
function declaration. In this way the declarations will be
file-wide, and all the pesky private and public variables
will no longer have to be MEMVAR'd/FIELD'd in each
procedure/function to eliminate warnings.  Be very careful
not to declare a field token as a memvar, as it will BITE
YOU. And double check the memvar/field list for typo's,
which the compiler is good at spotting for you.

RECOMPILE.  You should have ZERO warnings due to ambiguous
variables, and you are about 90% converted to Clipper 5.x.

There are lots of Clipper 5.x features worth incorporating
into your applications: greatly improved browse control,
open get system, much improved array handling, code blocks,
pre-processing, object-oriented programming.

The reason I choose NOT to eliminate all public and private
variables in the beginning is that the task is sometimes
"TOO HARD", and it's not worth the effort from a business
cost/benefit point of view.  UNLESS... I don't know
what???.  Since Clipper 5.x has arrived, almost all of the
286 machines have been replaced by 386 or 486 processors,
and we "ain't seen nuthin' yet!". So speed wouldn't be a
valid reason to totally re-engineer a working program to
get rid of private and public variables.  With the advent
of EXOSPACE, and Blinker 3.0 at the doorstep, saving a few
Kbytes of memory in the symbol table couldn't cost-justify
spending hundreds of hours removing private and public
variables.  Future development is a different story. To be
sure, lexical scoping is extremely important, especially in
very large, multi-programmer applications/systems.

As a safety measure, if time is available, try to alias all
field references.  This is a time-consuming retrofit, but
it will pay big dividends in debugging, especially if
debugging is done by others. And it should become standard
prodedure in new application development.

There are 7 compiler warnings, 80 compiler errors, and 40
fatal compiler errors listed in the Clipper 5.2 Norton
Guides.  It is assumed that you are familiar with them...
or that you WILL become familiar with them.

If you have delayed in converting some of your larger
applications to Clipper 5.x, now is as good a time as any
to make the move.  With release 5.2c, Clipper  is once
again a stable, reliable development platform.  And by now,
most of the 3PL's are Clipper 5.x compatible. You don't
have to embrace all the new stuff at once.  Make the move.
Use the new compiler; get into the pre-processor; enjoy the
improved debugger; explore multi-dimensional arrays;
taste code blocks; browse Tbrowse.

