Power-Programmierung

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

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

Wrap

Text File | 1988-01-24 | 19.1 KB | 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 (219) 696-6760 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 (219) 884-9508. 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: (999)999-9999, 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 (219) 696-6760 ----------------------------------------- Quick Basic is the trademark of Microsoft, Inc. Btrieve is the TradeMark of SoftCraft, Inc. XENIX is the TradeMark of MicroSoft, Inc.