.IF NBI .RM70 .LM0 .NOJUSTIFY .ENDIF NBI .IFNOT NBI .RM72 .LM5 .ENDIF NBI .TITLE EDT V3.0 Editing Windows .HEADERS ON .STHL ,0 .AP .hl 1 Introduction Those of you who read any of the many (very, very many) publications dedicated to users of personal computers know that this year one of the BIG buzzwords is "Windows". New products just arn't really "in" if they do not have windows. Well the VAX is not a PC but the goal of the system is to provide as much personalized functionality as possible. Since windows would definitely increase system ease-of-use, windows have been added to VPW and to EDT. This change will involve setting a new version of EDT (VPWEDIT) to be the user's default editor. This memo will describe behavior changes which might be noticed in using the new editor (EDT), and how to use the editing windows. What is a "window"? Well in their most elaborite form, one can envision different tasks all executing and writing their results to a constrained area of the terminals screen. The outputs may overlay each other and may even be in different colors to distinguish them. Windows are useful because one function can be started up and while it is proceeding, another function can be started in another window. To do this generally requires treating each terminal as a bit-mapped graphic device and drawing characters (reduced in size) into the appropriate windows. Very few of the VAX terminals are suitable graphic devices, however, and even if they were, implementing a full window package would be a significant undertaking. Rather, the current VAX implementation is aimed at being able to interrupt work in progress (without loosing context), so as to execute some new function. This functionality is provided either from within an editing session (using EDT of course) or from within VPW itself. .hl 1 The New Editor - VPWEDIT VPWEDIT should behave identically to the standard system version of EDT V3.0 (SYS$SYSTEM:EDT.EXE) which is supplied with VMS V4.0. To use it the following logical must be defined (at system or process level). .lit $ DEFINE SYS$VPWFILES:VPWEDIT EDT (local) or $ DEFINE/SYSTEM SYS$VPWFILES:VPWEDIT EDT (system) .END LIT Once this is done, VPWEDIT will become the default editor for your process (or all users). To its new features (windows, clipboards), a number of keypad definitions must be made. These definitions should be placed in SYS$SHARE:EDTSYS.EDT. The relevent definitions include; .lit DEFINE KEY GOLD H AS "EXT SET HELP HELPLIB ;- HELP ?*'System HELP Topic: '; SET HELP EDTHELP." DEFINE KEY GOLD V AS "XLATEVPW>^Z." DEFINE KEY FUNCTION 33 AS "EXT SET HELP HELPLIB ;- HELP ?*'System HELP Topic: ';- SET HELP EDTHELP." DEFINE KEY FUNCTION 34 AS "XLATEVPW>^Z." DEFINE KEY GOLD CONTROL D AS "XLATE?*'DCL to CLIPBOARD command: '^Z." .end lit Note the two wrapped lines. For the real EDTSYS.EDT file, the "-" should be missing and the wrapped line, one continuous line. With these keypad definitions; .lit GOLD H Access VMS system HELP from within EDT HELP Access VMS system HELP from within EDT GOLD Control D Issue a DCL command the output of which will be included into the Clipboard buffer. F20 Start up a window (VT2xx). GOLD Control-V Start up a window (VT1xx). .end lit .hl 1 VPW Windows For some time, the VPW procedures and tasks have permitted using the PF4 key to access a limited functionality "Command Screen". The work at hand could be interrupted, and a new function could be performed within the limitations imposed by the "Command Screen". Recently it was discovered how to maintain a full functionality VT100 compatible "window" (rather than "command screen") for the VPW procedures. Users now using the PF4 key (or F20 key on VT2xx keyboards in VT200 mode) should notice a very different display. At the top of the display is a header showing the current process name along with instructions on how to exit from the window. The top three lines of the display are reserved for this header. The bottom of the display acts as a normal VT100 terminal from which one can issue commands, edit a program, or even invoke a new VPW function. Each time a commmand is entered to the "$" prompt (used to be VPW>) the command is executed and the I/O for the command is restricted to the lower 21 lines of the display window. In order to maintain the window no matter what the user does, it is necessary to read the cursor position before reading each command. Consequently, typeahead does not work normally in "window" mode. Window mode typeahead is covered in the next section. The VPW Notebook Program which handles phonelists, the drawing file, etc., also has limited functionality windows which bears mention. Again the PF4 key activates the "Command Screen". However, until a substantial rewrite of Notebook is done, full functionality (and full screen) windows (which will permit video editing) will not be available. .hl 1 Window Typeahead VPW and our editor, VPWEDIT each provide users with the capability of having a nearly full function DCL "window" to use. Fron either VPW or the editor a window is invoked by pressing the F20 key on a VT2xx terminal or GOLD V on a VT100 series terminal. A limitation of the initial window procedure was that when within a window, typeahead would not work. New versions of the window procedures now have removed this restriction and typeahead seems to work almost normally at least one command deep and probably more. However, nothing is for free. The additional code had to be added to the window procedure to support typeahead may decrease response time slightly. Also once input has been entered into the procedures typeahead buffer (but a RETURN has not yet been pressed) a Control-U will not cancel the input. Now this is somewhat confusing (sorry folks) because if one is entering data at the prompt, a Control-U will cancel the input (it is still in the Terminal Drivers typeahead buffer, not the procedures). However, if one has issued a command, and while it is executing, enters a new command, that new command will get placed into the window procedure's typeahead buffer and be displayed on the terminal following the next prompt. This text can not be canceled with Control-U. To flush the procedure typeahead buffer, enter Control-Y to abort the command or press the REMOVE key on the VT2xx terminal keyboards. Either action will flush the buffer and you will be prompted for a new command. .hl 1 Editing Windows By themselves, the minor improvements in window handling by VPW would not be significant. However, users can access full function windows from within our standard EDT editor by using VPWEDIT. This means that while editing, one may temporarily halt the editing session in progress, create a new window, answer or send mail, request help, issue VMS commands, access VPW, or even start editing a new file. .hl 2 Creating an Editing Window To create a window while in the editor the user should press GOLD#V on a VT100 style keyboard or F20 on the newer VT2xx keyboard. When this is done, the screen will erase, and the window banner will appear at the top of the screen. The process name displayed at the top of the screen tells which window level you are currently in. In response to the "$" prompt, users may enter any valid VMS command. However, continuation lines are not yet allowed. The user may return to the editor by typing either Control-Z, EXIT, or LOGOUT. Typeahead does not work within a window because the system must request from the terminal its current cursor location after each operation. If EXIT, or LOGOUT is typed, the current window is deleted and the user is returned to the editor. However, if ^Z is typed, the window is retained for subsequent use. Since creating a window involves creating an VMS subprocess (a rather time consuming process), if the window is to be used again soon, leaving it around between uses is advantageous. However, if inactive windows are left around, AUTOLOG will issue warnings that the subprocess (window) is idle. If left idle long enough, AUTOLOG will delete the subprocess. This will have no effect on your work since the next time you need it, it will be recreated again. > .hl 1 Technical Notes on Customizing EDT V3.0 for DCL Windows .hl 2 Introduction Two new EDT features have allowed "windows" to be added t EDT. First, EDT is provided as a sharable image which may be called as a subroutine from within a user program. This functionality is described in Appendix D of the EDT V3.0 reference manual. Using the callable EDT interface allows one to create a program which exactly mimics functionality of the EDT editor. Second, EDT provides the nokeypad XLATE command which allows the user to pass command strings to a user-specified subroutine. Creating the window editor, VPWEDIT, is straightforward. A mainline program extracts the switches and files specified on the DCL command line and calls EDT specifying an action subroutine to call if the XLATE command is used. The WINDOW action routine establishes an exit handler to keep track of the current subprocess in use so that it can be deleted when the editor exits. The WINDOW action routine creates or attaches subprocesses as needed to provide the DCL window. In the following sections, these program modules will be discussed in greater detail. The interested user is directed to the sources for these modules in the [VPW.VPWEDIT] directory. .hl 2 The Editor Mainline The VPWEDIT editor is designed to be an exact replacement for EDT. This replacement is transparently accomplished by inserting a command of the form .lit $ DEFINE EDT SYS$SYSTEM:VPWEDIT .end lit in the system-wide login command procedure. Once this is done, DCL will invoke the VPWEDIT image rather than the EDT image in response to the EDIT command. The only function of the editor mainline is to find what switches and files are on the DCL EDT command line. VPWEDIT was written in BASIC but it could just as easily have been implemented in Fortran. BASIC was chosen because it handles variable length strings automatically. For efficiency, VPWEDIT should be installed as /OPEN/SHARE. .hl 2 The WINDOW Subroutine When the nokeypad XLATE command is processed, the subroutine specified in the EDT$EDIT call for handling the XLATE command is called and any text associated with the XLATE command is passed to the function subroutine. Since the XLATE command is not directly accessible when using the keypad editor, the window is invoked by control key functions which should be defined in the system wide EDT initialization file, SYS$SHARE:EDTSYS.EDT. .lit DEFINE KEY FUNCTION 34 AS "XLATEWINDOW^Z." DEFINE KEY GOLD V AS "XLATEWINDOW^Z." .end lit The key definitions in this example will cause the WINDOW subroutine to be invoked if either the F20 key on a VT2xx keyboard or Control-V on a VT100 keyboard is pressed. Since creating a subprocess is time consuming, the WINDOW function subroutine keeps track of whether or not it has one available for use. If no subprocess exists, it spawns a subprocess and invokes WINDOW.COM. The function of WINDOW.COM is to prompt the user for input, pass that input on to DCL, and to attach back to the main process if a Control-Z is entered. The PID of the invoking process is initially passed to WINDOW.COM as part of the command line so that the parent process can be attached back to. If, however, the subprocess already exists, the WINDOW function subroutine, simply attaches back to the subprocess running WINDOW.COM which again accepts the user's input and passes it to DCL. In the event that attaching to the subprocess fails because the subprocess was deleted, the WINDOW function subroutine tries to create a new subprocess. The WINDOW function calls two subroutines, GETPID and EXIT__SPAWN. GETPID is used to return the PID of the process both as an integer and as a text string. The EXIT__SPAWN routine is used to insure that any subprocesses created are deleted when the image exits. .hl 2 The Command Dispatcher -- WINDOW.COM WINDOW.COM is an example of using a command procedure as a DCL command dispatcher. Initially, WINDOW.COM executes a GOTO to the SETUP section. The SETUP section of the command file is located at the end of the command procedure to optimize response time. When trying to locate the label of a GOTO statement, DCL always scans the command procedure starting at the top of the file. To insure the fastest response time, the SETUP section (which is only used once) is placed at the end of the command procedure so that it does not have to be read more than once by DCL. During the setup section, the VT100 screen is erased and the process name is obtained to include as part of the prompt string. At START, the user is prompted for input and that input is sent directly to DCL. If the user types Control-Z on input, the command procedure attaches back to the editor. If the user logs off the subprocess, the subprocess is deleted and the user returns to the editing session. Note that throughout the command procedure, extreme care is taken to insure tha SYS$INPUT is always correctly pointing at the user's terminal. Note also that the ASK image is required for this procedure to work. During the time that the procedure is requesting a cursor position update from the terminal, it is possible that a user could try typing in a new command before the procedure was ready to accept data. This data would appear as part of the cursor location string. So that typeahead does not have to be disabled, additional code exists in the procedure to extract the cursor location output from the input string and place any remaining characters in an internal typeahead buffer. By keeping track of what is in the internal typeahead buffer, the window procedure can support typeahead almost normally. However, nothing is for free. Supporting typeahead does decrease response time slightly because of the extra code which must be processed. Also once input has been entered into the internal procedur's typeahead buffer (but a RETURN has not yet been pressed) a Control-U will not cancel the input. The only way to flush the typeahead buffer is to either enter a Control-Y to abort the command entry, or to use the REMOVE key on the LK201 keyboard.