Full-View - Windows for Pick

(C) Copyright 1985-1996 Modular Software Corporation. All rights reserved.

Version 2.0 for AP - February 14, 1996

   Goto:  Table of Contents   Index
Chapter:  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15


FULL-VIEW interfaces to the Operating System and to your applications in several ways. In general, you can view FULL-VIEW as a layer inserted into the operating system which intercepts nearly all terminal I/O. In addition, in order to interface utility functions, additional verbs, subroutines, and techniques are used so that your applications can derive maximum benefit from FULL-VIEW.


Many FULL-VIEW functions are implemented within Pick BASIC through a parsing pre-compiler. This pre-compiler allows applications to interface to FULL-VIEW without the need for obscure user-exits.

The usage of the FULL-VIEW pre-compiler is discussed later on in this chapter. An overview of what the pre-compiler does will be presented at this point so that you can more fully understand what some of the FULL-VIEW functions are trying to accomplish.


The FULL-VIEW pre-compiler will process a number of classes of functions and statements. By "process", we mean that when one of these statements is included in a BASIC program, the pre-compiler will modify or alter the code so that what is actually compiled is not exactly the same as what was written by the programmer. This allows FULL-VIEW to create totally new statements and functions without requiring that the system BASIC compiler be modified. It also allows existing BASIC statements and functions to be enhanced so that they have additional features.

The following areas of BASIC are processed by the FULL-VIEW pre-compiler:


BASIC statements which input data from the terminal are replaced with macros which not only input the data but also process "Function Keys". FULL-VIEW supports all of the "normal" forms of the INPUT statements along with a special form with a length of zero indicating non-edited single character input.

FULL-VIEW also supports some versions of the INPUT @(X,Y) statements including use of validation masks. Unfortunately, different Pick implementations have functionally different methods of processing INPUT @(X,Y) statements and so FULL-VIEW's method of processing this statement may be different from the system's method for your particular machine. FULL-VIEW processes this statement to be compatible with Ultimate's Pick implementation. This implementation was chosen mainly because it seems to be without bugs (unlike some other implementations), and in general it makes sense to write programs in this manner.


There are several FULL-VIEW functions which are available as intrinsic BASIC function calls. These function calls are actually expanded into either assembly conversion user-exits or external subroutine calls. What is important is that you can write your applications with the simpler to use function format and not be concerned with what happens internally.


Some FULL-VIEW functions are called as external subroutines with the BASIC CALL statement. The pre-compiler will actually implement some of the call statements as different statements from what you have coded. There are two reasons for this. First, some FULL-VIEW subroutines are little more than assembly conversion user-exits. The pre-compiler can place these inside your calling program, eliminating much of the statements overhead. Second, the pre-compiler can group more than one subroutine into a utility routine which will occupy less code space on the system.


The BASIC version of the SMART-TREE BTREE indexing system is included with FULL-VIEW. The update interface to the BTREE system is implemented with the pre-compiler. This allows applications with "normal" BASIC file I/O statements like WRITE and DELETE, to update BTREE keys. The pre-compiler actually expands Pick BASIC file I/O statements into macros which call assembly user-exits to update the data file and keys in synchronism.


BASIC programs written to utilize FULL-VIEW functions should nearly always be compiled with the pre-compiler.


Many FULL-VIEW functions interface with application programs through the FULL-VIEW Pre-Compiler. This program is used in place of the system BASIC verb to compile programs. In general, all application programs which are to use FULL-VIEW or SMART-TREE functions should be compiled with the pre-compiler.


In order for the pre-compiler to operate, it must have access to a workfile to in which to store the intermediate generated code. This workfile will be created automatically if the program file exists in the same account in which you are working in and you are not referencing it via a synonym 'Q'-pointer. If you are referencing your program file via a 'Q'-pointer, you must create the workfile yourself. A separate workfile must be created for each program file that you are using. This workfile is actually a small duplicate data file which is created under the program file's dictionary.

For example, if you have a program file named BP, you would create this workfile by typing:

The size of the COMPILE.SOURCE data portion is not terribly critical since the pre-compiler will automatically delete any work items it places in the file.


The pre-compiler is an executable statement from TCL. The format of the pre-compiler statement is:

    PC filename itemlist {/options}
The "filename" is the program file which contains the programs that you wish to compile.

The "itemlist" is a list of item-ids, separated by spaces, of the programs that you wish to compile. A "]" may be specified to compile all programs and if the "itemlist" is blank, any active SELECT list may be used.

The "options" are single letters that are used to control various functions of the pre-compiler. Available option letters are:

Do not compile the code after it is generated.
Compile with the alternate syntax file. This option is used to interface applications with the SMART-TREE BTREE system without interfacing with the windowing functions.
Do not delete the generated code from the workfile. This allows you to examine the code to more fully understand what the pre-compiler is doing.
Edit the generated code after it is compiled. The pre-compiler will EXECUTE the system editor, allowing examination of the generated code.
BASIC Execution options:

Execute the BASIC command with a (C) option.
Execute the BASIC command with an (M) option.
Execute the BASIC command with an (S) option.
In addition, there are some options which are only valid on certain implementations. These options are present because of differences in compiling large programs on some systems.

Do not crunch the output code. The pre-compiler will normally try to crunch the main-line code by replacing any line longer than 25 characters with an INCLUDE of that line. This makes the main-line program much smaller and will usually allow you to compile nearly any program regardless of size. However, if you wish to examine the pre-compiled output (i.e. with the E option), this makes the program very difficult to read. This option is only significant on systems that; a) have INCLUDE or $INCLUDE; b) do not have $CHAIN; and c) are not unlimited item-size implementations.
Here are some examples of how to use the pre-compiler.



    PC BP *

    PC BP



Several pre-compiler source code directives are available to advanced programmers who wish to perform special or unusual tasks with the pre-compiler. These directives allow you to toggle the pre-compiler on and off for specific lines of code as well as specify and change the active syntax file. In order to use one of these directives, enter it as a line by itself into your basic source code with no spaces at the beginning of the line.


Turn the pre-compiler off for lines that follow.

Turn the pre-compiler back on for lines that follow.

*$PC SYNTAX {syntax.file}
Begin using the specified syntax file for the lines that follow.


It is nearly impossible to successfully mix programs that have been compiled with the PC verb with programs that are compiled with the system BASIC verb. The reason for this lies in the COMMON structure that the pre-compiler adds to the beginning of a BASIC program for both Windowing and BTREE interface reasons. If an application program calls a subroutine, and the main-line program is pre-compiled, but the subroutine is not, you will not be able to successfully run the pair if either uses any application COMMON. The only case where you can successfully mix pre-compiled and non-pre-compiled applications is the case of a pre-compiled main-line program calling an external subroutine which does not include any COMMON statements, does not pass any file variables (SMART-TREE file variables are different from system file variables), and passes all data to and from the main-line program in named variables in the parameter list.


The pre-compiler has several minor limitations which may affect the code that is generated in some cases:

  1. The pre-compiler has a limitation of the amount of code that it can process on some systems. This limitation comes from the fact that the pre-compiler is itself a BASIC program and BASIC string space is limited on some machines. The pre-compiler tries very hard to get around this situation, but it is still remotely possible that you may have a program that hits this limitation.

  2. The pre-compiler can, at an absolute maximum, generate programs that are 32K on any machine that is not unlimited item-size. This limitation is actually delayed if the machine which you are on supports either $CHAIN or INCLUDE/$INCLUDE. If you system supports $CHAIN, the generated program will automatically link to extension programs when they get to large. If your system only supports INCLUDE or $INCLUDE, the pre-compiler will try to compress your program by changing large lines into included items that are one line long each.

  3. The pre-compiler supports most formats of INCLUDE, INSERT, and $CHAIN with the following syntax's:

    INCLUDE item
    INCLUDE file item
    INCLUDE item FROM file
    $INCLUDE item
    $INCLUDE file item
    INSERT item
    INSERT file item
    $INSERT item
    $INSERT file item
    $CHAIN item
    $CHAIN file item
INCLUDE operates with the pre-compiler even on those systems where the operating system does not support INCLUDE.
  1. If you pre-compile a program on a system that does not support a native INCLUDE-type statement, you may have difficulty with some IF/THEN/ELSE syntax forms within the included module. The problems only occur with statements that are single-line forms of the IF statement or include forms such as END ELSE IF ... on a single line.

  2. Statements that contain system delimiters within quotes (value or sub-value marks) will fail to compile correctly if they are also within statements that the pre-compiler is processing. With SMART-TREE, these statements include:

  3. File I/O statements.
  4. INCLUDEd statements.
Statements that compute system delimiters using the CHAR(...) and similar functions will compile without difficulty.

  1. Single-line IF THEN ELSE type statements may fail to compile correctly if they are on the same line as statements that are pre-compiled. This is due to difficulties that the pre-compiler has in determining which ELSE or END clause goes with which IF or THEN clause. You should note that some Pick vendor's BASIC compilers have similar trouble, so it is a good idea to not use single-line IF THEN ELSE statements in all but the simplest cases.


FULL-VIEW has many interface functions which are called as external BASIC subroutines: These functions fall into two classes:


Some FULL-VIEW subroutines are actually implemented as macros by the FULL-VIEW pre-compiler. The subroutine can be used from programs of any precision. These include:

    GET.SCR                 START.CHILD.SUB         GET.SCR.DATA
    SENTENCE                GET.SCR.WINDOW

The remainder of the FULL-VIEW subroutine functions actually call external subroutines. One of two options are then available to you. If you are using BASIC application programs which are written with PRECISION statements other than precision 4, versions of the system subroutines for all other precisions are provided (you may have to load them seperately on some systems). These other subroutines have the same names as the original subroutine with a $# appended after the name to indicate the precision that the routine was compiled under. For example, START.WINDOW.SUB at precision 2 is called START.WINDOW.SUB$2.

   Goto:  Table of Contents   Index
Chapter:  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15