Power-Programmierung/CD1.mdf/basic/tools/cvt/cvt324.doc

Text File | 1988-01-24 | 20KB | 425 lines

     The reason for this program is to allow the modules for a
library to be developed/compiled for userlibs or .QLB's in a 1 or
more larger modules.  It also converts a program designed for QB3
to QB4 code.
     When you create a .LIB file the LINKer access to that file
is in granule chunks.  This means that if you want to use a Basic
routine that compiled to 40 bytes of machine code and it is part
of a 10-K module; the linker loads 10-K of machine code.  The
remaining code may never be accessed but will be present in your
EXE file

     The program runs with a lot of instructions.  You shouldn't
have any problems figuring out what you need to do.

     The initial goal for these progams was to automate the
creation of my LIBraries.  The Library is a commercial library
marketed as the dBASICs ToolKit.  It contains a large number of
SUBroutines.  The subroutines call other subroutines and FN's.
The FN's are contained in a header file along with a large common
block.  Original development broke about 90 routines down into 5
Basic files.  This was sufficient granulation of the library for
development under QB3 and would have remained so; until QB4 came
along.  When QB4 provided the enhanaced FUNCTION, it was possible
to do away with one of the weak points found in Basic; its
requirement to place a FN called by a SUB in the module being
compiled.  Now the library would be most efficient under QB4 when
each subroutine was a seperate module.
     Enter the dilema!  How do you maintain the two libraries?
Each calls for a substantial modification to optomize it for
different QB versions.  A maintenance nightmare loomed.
Maintenance now seemed to require total recall to avoid
introducing more problems with each simple maintenance act.  The
function/fn disparity could have been partialy overcome by
retaining the existing maintenance structure which used a special
file header for each module that using INCLUDE to provided the FN's
needed by the module; then the actual module.  A second set for
QB4 would replace the FN include with the DECLARES needed in the
module.  It would fail to provide the enhanced granularity that
was available under QB4.
     The solution was to create a set of programs that would
process the original granules into a form that would be most
efficient with the appropriate version of QB.  The solution is
based on maintining the library in its original QB3 format of a
number of related modules that provided the optomal granulation
for QB3 and below.  The program would then process those granules
and create master compile modules and .FN modules for QB3 and
individual granules with the appropriate DECLARES included in
each SUB/FUN granule with QB4.

     CVT324 does the processing of a group of up to 20 BASIC
source files that, when combined, create a USERLIB or QUICKLIB
for either QB1-3 or QB4 and an appropriate .LIB file.  The LIB is
created with each of the SUB/FUNCTIONS included as a seperate
ranule.


.cp8
     You inform CVT324 of the following information:
     o    Version of QB being used. (1-3 or 4+)
     o    The name of up to 20 source modules used to create a
          library.
     o    The '$include line that will provide common
          information.
     o    If you want the display to be slowed to allow review of
          processing.
     o    If you wish to name the output modules yourself or
          allow the program to name them.  If you use the
          automatic function, Sub/FUN names must be unique in the
          first 8 character in each name.

     The program then processes the modules to granules and
writes batch file information to speed up the subsequent
compile operation.  It can also write a control file that will
automate and speed-up subsequent reprocessing.  It can also write
a file containing all code modules for creating DECLARE
information and the environment library.
     If Version 4 is selected, it changes each DEF FN found into
a FUNCTION and revises the FN's in all code written to remove FN
from the source.  The user can confuse this operation with odd
commenting and should review code to ascertain and correct for
any minor problems found.

Type
---------
     Purpose
     ------------------------------------------------------------
[!].MGF
     Maintains information about the modules that will be used to
     create a library.  Text may be edited to add/change.
[G].SQ3 [G].SQ4
     Creates   a  .SQ?  granule  for   each   Subroutine/Function
     contained  in  the  assigned  modules.   3/4  indicated   QB
     version selected.
[G].FN
     Creates the .FN granules needed by subsequent processing for
     QB3 compiles. (When QB selected is less than 4.)
[G].FUN
     Creates a .FUN granule for each FUNCTION or DEF FN(QB4 option)
     contained in the assigned modules.  These are used with QB4.
[!].BAT
     Creates a batch file using the master file name assigned
     that will automate the compiling of the library and
     USER/QUICK libraries.  This file can be created by either
     Gran? program.  The proper one to use is the one created by
     CVT324 when compiling QB4 and Gran3 when Compiling for QB3.
[!].TXT
     Creates the @file for LIB use.
[!].QB3 .QB4
     Creates a Basic source file that contains all of the
     assigned modules.  Used to compile the QUICK/USER LIB and
     get the DECLARES needed.
[!].DCL

     Reads all the DECLARES found at the start of the .BAS file
     and writes the file used by Gran4.
[M].QB3
     Reads each module found in [!].MGF file; determines the FN's
     needed by the module; writes the modules from the .FN files
     create by CVT324 to .QB3; writes a $include for source module
     and $include for commons.
[G].SUB  [G].FUN
     Reprocesses all of the .SUB and .FUN files created by CVT324.
     It locates all CALLs or function assignment in the module;
     places the declares at the beginning of the file and
     rewrites the updated file.

[!] indicates Master name used to reference library modules
[M] indicates the name of each module found in master list
[G] indicates each subroutine/function found in the modules


The reason for this program is to allow the modules for a library to be
developed/compiled for userlibs or .QLB's in a 1 or more larger modules.
When you create a .LIB file the LINKer access to that file is in granule
chunks.  This means that if you want to use a Basic routine that compiled
to 40 bytes of machine code and it is part of a 10-K module; the linker
loads 10-K of machine code.  The remaining code may never be accessed but
will be present in your EXE file

The program runs with a lot of instructions.  You shouldn't have any problems
figuring out what you need to do.

                              WARNINGS
If you use the automatic naming, the program uses the first 8
characters in the routines name to name the output file and
appends .SUB or .FUN to create a DOSname.

If you have Fn?????() in the QB3 granules, you will have compiler
errors. This should not occur with QB4 because you can recreate
all FN's as FUNCTIONS which can be compiled as granules of their
own.  However w. QB4, you will have to place DECLARES in the
files created before compiling.  This can be done with the
include option to reference all SUBROUTINES being created in a
header.

If you scatter REMarks that include things like 'read to exit
sub, the utility will have problems.  You should be able to see
these problems by the lack of or improper color changes or the
list created.

REMEMBER, it is possible in REMarked areas to confuse the utility!

Work from backups or be certain that the files being generated
will not overwrite valid, existing files.

The program is NOT case sensitive.

                                *****


This is a shareware product.  The product has been slightly
crippled in the following manner:
  o  forced 1 second pause when displaying each output line
  o  Displaying of text while processing cannot be disabled
  o  Partial documentation is provided.
Otherwise, the shareware version works exactly like the commercial one.

For the Commercial version, send $25.00 to:
    Ken Prevo
    Digital Design Consultants
    15303 Colfax St.
    Lowell, IN 46356
    [phone]

QB4 Source Code is available for an additional $25.00

                         Commercial Ver. Speed
   On a system where all files already reside in disk cache,
files written to memory disk, system 10-mhz 80286: Lines
processed just under 60 lines/second.  Writing to hard disk drops
speed to about 35 lines/sec.  And without cache, (Vanilla I/O)
its around 28 l/s.  These speeds are with source code display
turned off.  With source code display turned on, it typically
take 3-6 times as long to process the file. With all file output
turned off processing exceeded 80 l/s.

ASSUMPTIONS (Best Coding Method)
It is assumed that you probably have a common block.  This block
should be developed as an $INCLUDE file.  You will need to have
it included with each granule created.  This is provided for by
allowing you to add a line of code to the start of each module.
You should also include all of the declares needed by ALL modules
to this file.  MS states that the referencing of the uncalled
modules will in no way effect the size of the .EXE file created.

Users of QB4 will load the combined code produced using QB.EXE to
create the DECLARE file that is needed by this program.  The
declares are inserted in the granules (Only where needed) to
allow referencing of different granules in the granule being
processed.  MS states that referencing a routine with a declare
statement that is not needed in the module/program does not force
the linker to load the granule referenced.  It is therefore
possible to develop one Declare include file that references all
modules; even the modules that are not needed in your coding.

Comments that contain [space] then FN SUB or FUNCTION followed by
a [space] will be lost in processing. You should surround these
instances with single quotes to avoid such a problem.

If you have comments that include the actual name of a subroutine
not in the module, the DECLARE associated with that subroutine
are also included in a module, it is best to single quote such
references to avoid this happening.


This program should properly handle all common coding methods.
If the program errors in processing, I would appreciate a sample
of the code that does this.

This can be upload via compuserve, my id is 73167,1701.  It can
also be sent to the LANS BBS [phone].  LANS BBS can also
receive messages forwarded from a number of other PCBoard BBS's.
Address msg. to Ken Prevo.

                       *** ADVERTISMENT ***

This utility was written to support the following library that is
Sold By Digital Design Consultants:

              dBASICs ToolKit for BASIC Programmers

     The first release of the dBASICs ToolKit supports Quick
Basic and the  Btrieve file manager.  Future release are planned
that will provide support for XENIX5 Basic Compiler with Btrieve,
and Fortran/Pascal/Masm/C with Btrieve in DOS and XENIX.

     The dBASICs ToolKit gives Basic many of the features found
in 4th generation language.  dBASICs supports relational data
structures.  Programs can be developed in a fraction of time
utilizing the integrated dBasics environment.

     Program development begins with the designing of data
structures using Webster--the data dictionary program.  Webster
provides all of the standard Basic variables and adds:
     - Money Variable (no more Basic rounding errors)
     - Julian Date Variable
     - Time Variable
     - Phone Variable
     - ZIP code variable
     - NAD NameAndaDdress variable
     - Upper Case String
     - Social Security Number variable
     - User defined data variables

     After developing the data file structures, screens are
developed using ScreenStar, the screen design program.
ScreenStar is a full screen editor with the following features:
     - line and box drawing
     - access graphic character
     - access to character prohibited by Basic
     - painting of blocks
     - centering text
     - column lock
     - 32-color sets that define Input/Display colors
     - line insert/delete to and from buffers
     - screen text input from files
     - screen access of up 10 data dictionaries (files)
     - position/display fields for i/o
     - move blocks
     - print screen to printer or file

     - store screen in Binary file for fast screen loading

    After creating the screen and data dictionary files, special
files are generated that control all screen and file handling
inside the application.  The library provided, allows a program-
mer to open a screen definition file that uses up to 10 data
files at any one time.  You can append a record to a file with
just 3 lines of program code.

     This powerful development system allows a programmer to
develop programs in a fraction of the time often needed by other
programming environments, such as dBASEIII, RBASE, Informix, or
Focus.  In fact, if you assume a standard user interface, (same
command character to add, append a record etc.) the same program
can handle any single file with a custom screen without recom-
piling. A sample program, that does just that, follows:
'$Include:'dBASIC.INC'
  'dBASICs functions/Header file
Call ReadSDF((Command$)
  'open file from command line--
  'read and displays screen data
f% = 1 'file #1 is being used
While -1 'loop forever
  Call EditChoice(2,24,1,x$)
  Select Case x$
   Case "A" 'add
'here are the 3 lines of code needed to a record, mentioned earlier
     DD.Work$(f%) = String$(DD.Len(f%),0) 'clear the workspace
     Call EditAll(f%) 'edit every editable field
     Call DD.Append(f%) 'add the record created
   Case "F" 'find
     Call ParseKey(f%) 'input key to search for
     Call DD.Find(1,"=") 'locate record
     Call ShowAll(f%)   'and display it
   Case "E" 'edit current
     Call EditAll(f%) 'edit rec.
     If GlobalCommand$ <> "^Q" Then Call DD.Update(f%) 'rewrite if no abort
   Case "P" 'previous record
     Call DD.Prev(f%) 'step back -- eof handled internally
     Call ShowAll(f%) 'and display it
   Case "N" 'next record
     Call DD.Next(f%) 'step ahead -- eof handled by lib.
     Call ShowAll(f%) 'and display it
   Case "X" 'exit to DOS
     Call AllDone("") 'close and exit without reporting error to error file
   Case "D" 'delete current record
     Call DD.Delete(f%) 'delete record and reposition file
   Case Else 'report error
     Call ShowPrompt("Bad Input")
     Call Bell 'should soft alarm (Not terminal dependent)
  End Select
Wend

    Yes, this short program will edit; update; search; append to
any file created using dBASICs's screen and data dictionary

creation programs.
     The routines provided in the library perform elegant data
entry of all data types.  Fields can be edited ala WordStar com-
mands.  Numeric fields are input from the left ala a calculator.
Special variable types have formats/picture capability.  eg.
Phone: [phone], input positions for this picture are at the
number positions only; () and - are skipped during entry and are
not stored to the file for a saving of file space.  In fact, the
phone number is stored as a double precision value. (8-bytes file
storage)  Dates are stored in two-byte Julian date format.
Julian date allow aged accounting reports, etc. to be easily
programmed.
     Because the basis for the dBASICs ToolKit is the Basic
language, the programming environment does not impose the
limitations found in many commercial database programs.
Limitations such as no arrays, only flat file management, based
on earlier DOS versions, new programming language with an extend
learning curve, and limited to the number of fields or open
files; is a thing of the past.
     Included in the library are over 100 routines (many of which
are called by other subroutines; and therefore need not be
learned) that maintain files and avoid programmer use of
Btrieve's primitive call.  There is single call editing of: a
single field; a group of fields; or all fields.  The library is
very powerful, easy to use, and provides the ability to
manipulate fields and files based on the utility programs that
are part of the toolbox.
     A function file is included that will support the new
variable types; eliminate Basic's notorious rounding error;
support the library routines.

     The toolbox contains other support utilities that
automatically create ISAM/Btrieve files from data dictionary file
information; combine screens for direct memory loading of multi-
page screen to color/EGA monitors; and dBASICs even writes the
preliminary documentation for a screen.

     The programming environment created by the dBASICs ToolKit
eliminates the need for many of Basic's commands.  Files are
automatically opened as required.  Basic FIELDing statements are
not needed.  The old 10 as x$,15 as y$ ad infinitum are now a
thing of the past.

     User support is provided and the best available.  Support is
free! -- no additional charges are made.  Also, a bulletin board,
free to dBASICs licensees, is planned.  The bulletin board will
provide users with free dBASICs updates; a forum to discuss
problems and solutions; a library of programs that use the
dBASICs ToolKit; public domain and shareware software featuring
Basic and programmer related utilities.

     dBASICs' design philosophy was to avoid creating programmer
barriers.  As an example, the program default number of fields is
512.  This is more than adequate for almost any application.  The
design allows the user to edit the created files to have up to

999 fields, if sufficient memory if available.  Up to 10 data
files may be opened.  Again, more files may be opened by the
programmer up to the constraints imposed by software or hardware.

     Evaluation software with demo programs that makes use of the
dBASICs ToolKit is available upon written request on media
letterhead or by phone.  Tear sheets of any articles or reviews
are requested.

                 Pricing: (QB3/Btrieve Version)
                  Single Copy           $495.00
                 Site License          $1500.00
                 Corporate License     $5000.00

     Free upgrades are provided via modem to all licensed users.
No added charges for compiled applications containing dBASICs
routines.

Dealer/Distributor inquiries invited:

                For further information contact:
                            Ken Prevo
                   Digital Design Consultants
                          15303 Colfax
                        Lowell, IN 46356
                         [phone]

            -----------------------------------------
         Quick Basic is the trademark of Microsoft, Inc.
           Btrieve is the TradeMark of SoftCraft, Inc.
            XENIX is the TradeMark of MicroSoft, Inc.