Apex Programming Guide

Apex Application Builder

A User's Guide to Application Development in the Apex System

This document (c) 2000, Kandi's Kreations. I am releasing it as copyrighted freeware for the use of any persons who wish to program in the Apex 128k language system. Please do not upload to any other site until it is completed so we can avoid a deluge of unfinished documents. Perhaps, when this document is complete, I will allow it to be posted along with the correct disks and/or whatever extra programs I can put together. Thank you for your interest. Happy programming! :-)

*** Status Symbol Key Table ***     
* = Finished.          
? = In progress.         
! = Recently corrected.


Table of Contents        

Author's Notes ....................*
Intro To Apex .....................*
The Apex Command Line Interface ...*!
More About Macros .................*
Direct Macros .....................?


Author's Notes: 


   After working on the early drafts of this manual, I realize I am not an author of such texts. I hope to make this text enjoyable to read while explaining the use of the language and environment. It is not my intent to create a strictly technical document. I would rather create a document which can be easily read and hopefully inspire a few Apple II programmers to use the system to create some useful applications for our favorite computer, the Apple II.

   This document stems from my own use of the language. Both as a beta tester in it's early development stages and as a user and utility developer. I will also include help for using my generic application add on library, Apex.lib. I will try and keep this document as simple as possible. Where applicable, I will include information from the original Apex manual. I decided not to offer a duplication of the Apex manual for several reasons. Primarily, copyrights for the manual were not released when Microgram released the system to the public. Another, perhaps more important reason, my manual has been modified through the growth of Apex. It is a mixture of the original documentation with inserts and addendum's added. Unless you know which changes apply to which version of the system, you may wind up confusing yourself even more. Many of the older notes won't apply to most programmers unless you have collected the various system releases (of which there were many!) This seemed to me a better approach than trying to sort out my manual for appropriate information then go back and fill in all the gaps to make it understandable to someone without any experience in Apex.

   On my site, I will supply only the last (AFAIK) release of the system along with my library and any applicable demo programs which have been modified to use the library. There is little reason to restore the earlier releases due to syntax changes in the system which would cause difficulty with program maintenance. There was an earlier version which supported a 64k environment by using overlays and other advanced techniques, but it is still fairly limited and due (again) to syntax variations I think it should be left alone also. Considering the improvements in the final 128k release, I feel it is the best version to use and document. With this methodology you can be sure of having the best version of Apex and some quality programs to use for examples. This also allows for a common platform to build upon from both the developers point of view as well as the user's perspective.

   You may be wondering why I am already stressing the use of Apex.lib so early in this document. Aside from the obvious, author's pride, there is a very good reason. Apex let's you create applications with a mouse driven GUI. Not every Apple II user has a mouse. This may not be as applicable today as it was years ago. When I was beta testing Apex on my 2c, I didn't own a mouse. For many of the sample programs Don supplied me, a mouse was required. The keyboard adaptions worked, but were very awkward since the adaption tried to use the cursor keys to simulate mouse movement. In an effort to help, Microgram added a joystick read function. While the 'PAD' function worked, it was difficult to simulate a mouse with it. In my frustration, I created Apex.lib with routines which the programmer could use to treat the joystick just like a mouse. These routines improved the ability to create GUI programs which practically any II user with a 128k DHR system could run, as long as they had either a joystick or a mouse.

   These routines require very little effort from the programmer to support both devices and do so with a minimum of code use. This is easy to see when you start using the system and viewing the code. Since almost every II system should have either a joystick or mouse, I did not extend the system to support a keyboard pointer controller. As mentioned, this is very awkward and the code expansion really isn't worth it. Besides, what Apple II owner would be caught without their joystick?

   This is not to say that you should disregard the keyboard in your program's interface. I think that a system similar to that used in other GUI (read Mac or Windows) systems would be an added benefit to any program. Simply allow for key presses which can execute any particular function, or at least the minimum necessary to access the menu bar which can then be controlled by cursor keys.

   One final mention before we get to the meat of this project. This is (currently) a living document. That is to say, this document will be under continuos development and improvement. I will try to make this as obvious as possible. For new segments, it should be obvious. For changes in the information already provided, I will attach a link to explain them as best as possible. If you have information or feel you can help to expand on this project, please feel free to lend a hand. If you have worked with Apex in the past and would like to help with program examples, libraries or code, again, feel free to donate. You can contact myself, Phoenyx or leave a message in the news group comp.sys.apple2.


Introduction to the Apex Language

   Originally, Apex was based on the APL language with adaptions to the Apple II for compatibility reasons. In many aspects, Apex resembles BASIC and is an easy language for those who are familiar with BASIC. It must be noted, Apex is NOT Basic. It uses a different method of expression evaluation. Apex uses a direct evaluation rule which is like that used in APL. You can circumvent this by the use of parenthesis, which is recommended for the novice until you get a feel for the system. This will be explained in further detail in a later segment. As per the manual, Apex is not a complete implementation of APL, and during the development of the system, it has veered more towards the BASIC compatibility. All in all, it is a very unique system which offers a lot of possibilities.

   This section mentions many of the various drawbacks to this system. I suppose these drawbacks are subjective to the developer. Many of them are insignificant to me as the benefits of the language tend to outweigh them. IMHO, Apex's abilities in the development of useful GUI applications far outweigh the disadvantages. It should be noted though, the author did not always follow the standards laid down by Apple Inc. One example of this, you cannot pass program names to the Apex system program as you can with Basic.system. Apex must always have a STARTUP program to execute or it will enter the command line environment. I don't feel to limited by this as it allows for implementing a constant method for setting up the program's environment before executing the application. With Basic, if the program is launched via a program selector, it will have to ensure any setup is performed as required. Another, perhaps larger flaw which will be mentioned again in a later segment is failure to load to aux memory from an bank switched ram disk. This includes the initial execution of graphics mode. With the advent of hard drives in todays market, this may not be as much of a problem.

   Apex was designed as an application development system. This description may mean different things to different people. Primarily, it should be taken in context. Since Apex was developed in the era of the floppy drive, it was expected that applications would be developed to run from separate floppy disks. Each disk could/should contain all the data files necessary to execute the application. Apex is not limited to this simple layout. Since it was designed in Prodos, it can easily be run from any directory on a hard disk. This may require a little planning on the author's part though. Since the Apex system file is needed to start execution, it should be included in the application's base directory along with any of the other Apex support routines, such as HGR.1.

   A little brief on the basic Apex system and support files.

A128K.SYSTEM = Main system file. This includes the editor and program support routines.
CGR.1 = DHR Color graphics support routines.
DGR.1 = DHR Monochrome graphics support routines.
HGR.1 = HGR graphics support routines.
SGR.1 = GS Super graphics. I have never used this. Don told me once this was an experimental graphics library. He was developing it mostly to use in the fractal program he was creating. At the time I did not have a GS and had no use for it. There is an Apex program on one of the disks called MBSETGS which may help you out a little more. You must realize that this will limit any program which uses it to run on a GS only.

   These are the primary routines for the system. For graphics based programs, you only need to supply the appropriate graphics routine needed for the application. The original archive includes other program and data files. These are useful to give you a feel for the system. One other (possibly) important file is MENU. This program can be used in an interactive text system. If you enter MENU from the command line, this program is run. Apex will also run the program STARTUP at first execution. This is useful for any system setup as necessary.

   Apex also uses a HELP command. This command executes code in the current program starting at line 30000. How the help functions is up to you, originally it was intended to display help text on the program in memory. It could also be used to create a more interactive help system.

   A few more useful editor commands.

FLIST = list available functions.
CLIST = list editor commands.
VLIST = list current variable table.
GLIST = list current graphics commands.
BLIST = show commands in user supplied library.


   With these commands you can quickly find the function you need. I will explain the functions and commands in later segments based upon these groups.

   Apex programs are line oriented, although they can also branch to labels. Some planning on the programmers part is required since the range is limited from 0 to 32767. If you aren't careful, you can create the same spaghetti code as in basic. Apex supports value passing to subroutines. This can be useful, but since all variables are global is not strictly necessary. One advantage though is the ability to pass expressions. It is also useful to improve the program's readability.

   The logical expression evaluation is different from what many are used to. For example,

10 IF X .EQ. Y THEN PRINT "Match" ELSE PRINT "No Match"

evaluates for equality. There is also support for commands such as IFEQ which can be used as another method of conditional branching. These branch instructions can be used to define a variety of 'implicit loops'. Here is a simple example.

10 '*******************
12 '***.SQUARE ROOT.***
14 '***.CALCULATOR..***
16 '*******************
18 '
20 :loopstart
30 ENTER X IFMI loopexit
40 PRINT X, SQR(X)
50 GOTO loopstart
60 :loopexit
70 '
80 PRINT "End of session."
88 '
90 '**********************
92 '*** ENTER NEGATIVE ***
94 '*** NUMBER TO EXIT ***
96 '**********************


   Apex offers many other advantages, such as programmable keyboard macros. Expression evaluation from the command line. Improved line editing. Shortcut command entry for some commands. Easy access to DOS functions from the program. Uses standard 2gs fonts for graphic text display. Uses tokens for variable and label names and pre processes numeric input at program line entry. This enhances program speed. Many Apex programs run 3+ times faster than their Basic equivalents. 


The Apex Command Line Interface 


   Apex uses a CLI for standard system functions and program editing. You enter program lines by entering the line number with any necessary functions. By default, the CLI starts up in a split screen 40 column mode. The top part of the screen is for program/system output. The bottom five lines are used for command/program entry. These defaults are useful but often you may want the full screen or eighty column mode. To help control the screen mode, Apex uses the <ESC> key. Here are the key sequences.

ESC 1 = Full screen mode. Will clear the screen.
ESC 2 = Split screen mode. Will clear the screen.
ESC 4 = 40 column mode.
ESC 8 = 80 column mode.
ESC 0 = Enable vert.blank for IIe 80 column display.


   It is often useful to set your personal favorites for the screen mode and any other modifications to the system in the startup program. I will present a simple program to change the default screen to 80 and set the backspace to backspace before delete. In the system memory segment you may find other useful memory locations as well as the other bit values for the edit screen.

5 ' These two functions must
7 ' be used to set the initial
9 ' eighty column mode
10 VIEW/PT80
20 POKE 48752,PEEK(205)
22 '
24 ' Set backspace before
26 ' character delete
30 POKE $BE71,128 ' Poke a negative value


   This example also shows a feature of the remark function. Any text after the single quote mark is considered a remark. As you may have noticed, there is no colon between the two statements (use of colons is rather unpredictable and not always necessary, if in doubt use one). The interpreter simply ignores anything on the line when it encounters the remark token. Note, the startup program on the disk image I supply sets the defaults to 80 column and backspace before delete.

   Depending on how you design your system, Apex may load directly to the command line. It may also execute the startup program, and/or any chain of programs you decide on. Eventually you will need to exit a program to the CLI. To do this you use the <ESC> key. Unless you specifically trap for this event in your program code, you should always be able to enter the CLI this way. Until you are certain your program is correct and functions without errors, I suggest you wait before trapping for the <ESC> key.

   The Apex editor offers more functionality than what you may be used to. Not only can you use the arrow keys to move amongst the input line, there are several <control> keys you can use. You may also press enter anywhere in the input line, the whole line is accepted.

Here is the list of <control> keys.

B = Go to beginning of line.

E = Go to end of line.

D = Delete character. By default it is backspace delete. This is reversed when the delete key modification is used.

I = Insert text, press it again to return to over strike mode.

L = Convert uppercase character to lowercase.

Q = Delete all text under the cursor to the end of line.

R = Recover last line.

X = Abort current line entry.



   You have a variety of options from the CLI. You can edit the current program. Load and save programs. View the list of variable names, ect. Until you get used to the system, one of your most often used commands may be CLIST. You enter the command CLIST to view the available command line functions. Many of these are also available to running programs. A list of these functions will be presented shortly.

   Items in brackets are optional. In the case of LOAD & SAVE, Apex stores the program's name internally. Once you have loaded a program or saved with a filename you can simply type the LOAD or SAVE function. Alternately, use the NAME function to change the program's name. Another note of interest, when presented with any display from the CLI which extends past the bottom screen line, you may press the <SPACEBAR> to pause or the <ESC> key to abort. When scrolling text you can also press <return> to continue regular scrolling or <SPACEBAR> for single line scrolling.

   The DOS functions use a set of key words similar to those used in BASIC.SYSTEM. D (drive) and S (slot) T (file type) key words are used with DIR, CAT, and CATALOG. BSAVE, BLOAD, and BRUN use A (address), L (length), B (start byte) and T (file type). Apex also supports the B (block number) for the RDBLOK WRBLOK - according to the manual the block is read to $800-9ff. I have not verified this as I normally don't due block reads except in emergencies and then only with a known block editor.

SAVE = Save a file to disk. Sets the current program's name. Syntax: save [pathname]

LOAD = Load a program from disk. Also sets the current program's name. Syntax: load [pathname]

RUN = Run a program in memory or from disk. Also sets the current program's name. Syntax: run [pathname]

DELETE = Delete a file from disk. Syntax: delete pathname

RENAME = Rename a file on disk. Syntax: rename pathname1,pathname2

ONLINE = List available volumes. Syntax: online

CATALOG = List current directory or specified directory. Syntax: catalog [pathname]

CAT = Same as Catalog

CREATE = Create a subdirectory. Syntax: create pathname

PATH = By itself it shows current P8 path. Specify a new prefix to change directories. Syntax: path [pathname]

PREFIX = Same as path.

EXEC = Exec a text file of commands, use MERGE for line entry. Syntax: exec pathname

BSAVE = Binary save of a memory location. Apex can save memory from either bank. To save from the aux memory bank use a long address. Syntax: bsave pathname,A$2000,L$2000,TFOT (main memory graphics page) or bsave pathname, A$12000, L$2000, B$2000 (Aux memory graphics page. From this you can see the aux memory is appended to the existing file @ byte 8192) See also BLOAD.

BLOAD = Bload from disk to ram. Apex can bload to either bank of memory. This does not always work. If the disk is a ram disk which uses the 'Applied Engineering' bank switch method, Apex will choke. This also happens if you attempt to run Apex from the ram disk and run a graphics program. Syntax: bload pathname, A$2000[,L$2000] (main hires memory) or bload pathname, A$12000[,L$2000[,B$2000]] (Aux ram hires memory. From these examples, the bload to aux memory is taken from the file @ byte 8192)

BRUN = Execute a binary file. Syntax: brun pathname [,A$] It is supposed to be possible to execute machine language in aux ram. I have not verified this although the graphics routines also run from aux ram. This also shares the same problem with auxiliary memory cards as mentioned in the BLOAD command.

LOCK = Lock a file. Syntax: lock filename

UNLOCK = Unlock a file. Syntax: unlock filename

COPY = Copy a file. Syntax: copy path1,path2

OPEN = Open a file. This actually works from the command line to allow output of program listings and such to a text file for an external editor. Syntax: PROGRAM: open file_number/(read or write) pathname - CLI: open pathname

EX: 100 OPEN #2/WRITE FNAME

TYPE = View a text file. Syntax: type pathname

CLOSE = Close an open file[s]. Syntax: close [file#]

RDBLOK = Read a p8 block from disk. Caution is highly recommended. According to the manual, this loads the block data to $800. Syntax: rdblok integer.

WRBLOK = Similar to rdblok, writes block number to disk. Syntax: wrblok integer.

QUIT = Quit to prodos.

END = This was supposed to reboot the system. For some reason it no longer works on either my IIe or GS. BTW: Apex was created on a GS for the most part. Do not use, just EXIT to Prodos.

IN# = Input from a specified slot. I have never used this feature. Syntax: in# integer (1-7)

PR# = Send output to slot (pr#) Similar to basic.system. Primarily this is a printer. May also work with in# as a cheap terminal. Syntax: pr# integer (1-7)

PTRON = Turn on printer access.

PTROF = Turn off printer access.

DIR = List filenames only. In program code this supports file find. Syntax: dir [pathname]

DLOAD = Load a set of Icons to memory. You can use the EDICON program to create them. Colors can be simulated to the degree that the Apple II series handles them. I couldn't locate any reference to this in the manual, but I found an old demo I threw together which drew a set of walls from the icon table. Note: Originally this was the ILOAD command and was changed to avoid problems with Apple Inc. Doh, how could I have forgotten that. Syntax: dload pathname

FLOAD = Load a font into font memory space. Apex uses a special location for storing the font. Originally, this was $7300-93ff in aux ram. I have no mention of this changing and normally is not important to the developer or user. Syntax: fload pathname

MLOAD = Load a macro file. Apex has a default set of macros.@CCAT, @DDIR, @SSAVE, @PPTRON, @OPTROFF. As you can see, the macro is defined as the macro key plus the function. Later I will present a simple macro editor from the spec sheets I have on macros. Macros are used by pressing the Open Apple Key along with another key. Macros may also be used for menu selection in a program. This replaces the DEFKEY function from the early versions. Syntax: mload pathname

HOME = Clear the screen.

VRUN = Run a program with saved variables. Syntax: vrun pathname

ZRUN = Run a program, zero variables. Syntax: zrun pathname

LOMEM = Adjust program memory. Program memory is normally $6000 - $AC00 but can go as low as $0C00 if you use no macros or libraries. This may be useful to allow program code to run from the hi-res memory area. If you do this don't try any graphics functions. Use caution. This also shows the current value if used by itself. Syntax: lomem integer

HIMEM = Adjust himem location which controls the top of program space. Will also display the current setting. See LOMEM. Syntax: himem integer

NAME = Change or set the current program's name. Useful for the save file shortcut. Uses only the P8 filename. Syntax: name filename

NEW = Clears program memory.

MERGE = Merge a numbered text file which should contain program code. Useful for external editing or reentering program code from a text file to clean up the name table. Syntax: merge pathname

FREE = Show available program space. When I set apex's lomem to $2000 it gives 35451 bytes free. Normal is 19067. I will include a segment on memory later.

HELP = executes HELP from program in memory if available. Help code starts at line 30000. If you think there is any chance the user will get to the command line with your program, you should include some help lines. Originally Apex was designed to be an expert system and this command was a part of that.

CHANGE = Change a variable name. Note, you can only change a name, you can't delete one. See MERGE for another solution to this problem. Syntax: change name1 name2

CONT = Continue a program which was stopped by the <esc> key.

LIST = List program in memory. Can use line number ranges. Syntax: list [integer [ -integer]]

FLIST = List available functions.

GLIST = List available graphics functions. Defaults to the standard hi-res functions. You should still load the correct graphics driver file.

VLIST = List current variable table. Note, this table also includes branch labels. Don told me once what the actual limit on this table was, but I can't remember it nor find a reference. I'm pretty sure it's 128 because I thought the value was kind of small. I have never reached the limit so apparently it's not that important.

CLIST = List commands available.

BLIST = List commands in the binary table. This only applies if an external library such as apex.lib is loaded.

DSIZE = Show or set integer data size. Syntax: dsize [integer]

BSIZE = Show or set current string size (0-127). I have no idea why it is called bsize. Syntax: bsize [integer]

DUP = Duplicate program lines. You will need to reedit any lines with labels to correct the label pointers. Original lines are not deleted. Syntax: dup start_integer-stop_integer,new_start_line_integer

DEL = Delete line or range of line. A small caution. If labels exist, you need to check the program for branches to this label. Syntax: del first_line[-last_line]

EDIT = Edit line number or first line of code. Syntax: edit [line_number[-end_line_number]]

MENU = Run the program named menu from current directory.

CLEAR = Clear variable space. Does not clear variable name table. Currently the only way to do this is to reenter the program, either by keyboard or text file merge.


Shortcuts


R = Run

H = Execute help portion of current program.

F = Function list.

G = Graphic Function List.

L = List program.

CM = List commands.

V = List variable table.

D = Line delete.

C = Continue program.

E = Edit program or line.


More About Macros

   As mentioned earlier, Apex has macro capabilities. This was an improvement over the older method of 'Defkey'. The trade off for saving macro files was the loss of immediate macro definitions. Although if you really need this for a program, you might be able to incorporate the simple macro program presented later. Once the macros are configured they can be accessed by using <Open Apple> + <(keystroke)>. Each macro can hold up to 120 characters, including control characters.

   Macro files can be created either with an assembler or through an Apex program. I will present the minimal program given in the tech sheet. For assembly code each macro is formatted as 'DCI' string data with bit 7 low for each character but the last. The last macro string is followed by a one byte zero. Whether you use an assembler or the Apex program, you use the command MLOAD (syntax: MLOAD filename) to load macro files. Apex comes with a default set of macros which are loaded each time the system is run. If you want to use the same set of macros every time, you can load them from the startup program.

   Apex's macro file resides at $0c00 to $0fff, just below the library memory space. So for those of you who might use the assembler method the 'org' starts at $0c00. It is 3072 in decimal. Anyhow, you have only 1k space for macros, so be careful if you intend to use a lot of text in them.

   Here is the basic asm format for macros.

MACADR ORG   $0C00
       DCI ': ?'             ;Statement Macro
       DCI '/PRINT ?'        ;Calculator
       DCI '??PRINT ?'       ;Calculator
       DCI '@CCAT'           ;Catalog
       DCI '@DDIR'           ;Directory
       DCI '@SSAVE'          ;Save file
       DCI '@PPTRON'         ;Printer output
       DCI '@OPTROFF'        ;Printer off
       DCI ';@DOS "CATALOG"' ;Cat immed exec


   Based on this code segment you can see the macro format. The @ character performs two different functions depending on location. If it's the first character then the <Open Apple> is used to select it. This is the normal method for macros. If the @ symbol is the second character then the specified macro will execute immediately. This method shows support for macros at run time. Run time macros can be useful for menus.

   Author's note: I have been trying to verify the immediate execution of macros. As yet I can not get this to work. The simple program from the manual does not seem to work. If you want to try, here it is.

Macros defined as:
1@GOTO 100
2@GOTO 200

10 DOS "MLOAD TEST.MACROS"
20 GOTO 20
100 PRINT "LINE 100":GOTO 20
200 PRINT "LINE 200":GOTO 20


Here is the Apex program for creating macros. This code is fairly simple. Whether you actually use this program or not, you should at least study the code as it shows some of the Apex syntax.



100 ' Edmac - macro editor
108 DOS "VRUN" ' Save variables after each run
110 DIM MAC(20) :IF (MAC.NE.0) GOTO 200
112 ' For first run start with default macros
130 MAC(0)=": ?" :MAC(1)="/PRINT ?" :MAC(2)="??PRINT ?"
140 MAC(3)="@CCAT" :MAC(4)="@DDIR" :MAC(5)="@SSAVE"
150 FOR I=6,20 :MAC(I)="@" :NEXT
199 '
200 M=6 :macadr=3072 ' $0c00
204 ' Edit each macro until 0 entered
210 HOME 4,2 PRINT "EDMAC - Macro Editor"
212 VTAB 6,2 PRINT "Enter changes and"
214 VTAB 8,2 PRINT "Press RETURN to enter"
222 VTAB 10,2 PRINT "Macro #",M
224 VTAB 12,2 PRINT MAC(M)
232 EDIT MAC(M)=MAC(M)
234 VTAB 11,2 PRINT " (18 SPACES) "
236 VTAB 11,2 PRINT MAC(M) :WAIT 2000
240 IF (MAC(M).EQ."0") GOTO 300
250 ELSE M=M+1 :GOTO 210
260 '
300 size=0
302 ' Now put macros into macro space.
310 FOR I=0,M
312 string=MAC(I)
320 FOR J=1,LEN(string)
324 POKE macadr+size+J-1,string(J) :NEXT J
330 POKE macadr+size+J-1,NEG(string(J)) ' Last character
340 size=size+LEN(string) :NEXT I
350 POKE macadr+size-1,0
400 ' Now save macro file to disk
410 HOME 10,2 :PRINT "Enter macro file name!"
420 INPUT fname
430 DOS "BSAVE"+fname+",TMAC,A$C00,L"+HEX(size)
440 ' End of program













































Direct Macros

Apex provides DIRECT MACROS. You may use this feature to assign special functions to any character or numeric key. The specified function will be performed anytime the the key is pressed. They key press function may also be defined to accept text or numeric data entered from the keyboard. This method may be used from the CLI or in a program.

Examples of direct macros.

   /PRINT ?
   - Single calculator entry.

   ??PRINT ?
 - Repeat calculator entry.

   : ?
             - Statement entry.

These direct macros are part of the macro file loaded at system start up. The direct macro is executed whenever the lead key is pressed. Any text following the key press is inserted (printed) at locations indicated by question marks in the macro string.

Valid keys for heading direct macros are:

   ! " # $ % & ' ( ) * + , - . /
   0 1 2 3 4 5 6 7 8 9 : ; < = > ?


As numeric keys are always used to start program lines they cannot be used from the editor. Key assignment to a direct macro does not change customary use. For example, assigning / as calculator macro still allows use in arithmetic expressions to indicate division.

For your convenience, APEX defines / and ? as special keys which may be used as calculator keys. You may press the slash key and enter any valid expression. Upon entry, the value of the expression is displayed on the output screen. Multiple expressions separated by commas are allowed.

Program variables may be used with calculator statements. This allows you to interrogate a long running program to check progress or show values for debugging.

Using the question mark instead of the slash will allow repeat entry. The macro uses ?? as lead characters to indicate re-prompt in the calculator mode. You can check this feature by using the question mark key from the editor.

NOTE: Any symbolic name used in a calculator expression must be already in use within the program. Using an undefined variable name in a calculator expression will terminate with the message "UV ERROR" (undefined variable).

The calculator keys are useful for practicing the Apex notation. Expression evaluation rules differ from those used for BASIC.

During program execution you may use the calculator keys to check progress without interrupting the running program. Of course, this only applies to text based programs which allow display to the standard text screen. This can be useful for testing a real time process which can not be disturbed, such as data sampling from an input port.

The colon key is defined by the system to process any valid Apex statement. The statement macro has a very simple form : ? (colon space question mark). After pressing the statement key you may enter any valid statement. The statement will be automatically executed when you press entry. You may also use this method to assign variables without interrupting the program.

Like the calculator macros, the statement macro is part of the system macro file. You should ensure that the calculator and statement macros are included with any macro file you create. If you use the simple macro generator program presented earlier you will automatically create these macros.

Direct macros may include a second header character to reprompt the same key press after execution. For example, the statement example macro would use the form:

   :: ?


(RC) Recovered from the Original Site -- Updated May 2010