&k3S&dDUsing IPC Programs With Tech BASIC&k0S&d@ Integral PC Tech BASIC is a UNIX (tm) application; this fact has caused some trouble for some users, but the IPC's UNIX (tm) enviroment provides many powerful tools for the astute user that can be used to the great advantage of the BASIC user. Using the IPC's tools, a BASIC user can create additional alpha windows (and load them with custom fonts) or HP-GL plotter windows, and move or resize them to suit his or her preference. The tools available to the BASIC user include: + set_win - creates or modifies an alpha window. + plotter_is - creates an HP-GL graphics window. + set_font - load a custom font (created with "fedit") into an alpha window. (The "plotter_is", "set_font", and "fedit" programs are shipped standard with the IPC; "set_win" is shipped with the latest IPC release software and on this disc.) These commands can be placed in an "Autost" script file and executed before the "Autost" script invokes the BASIC program. This brings up the first question: what precisely is an "Autost" script? A series of commands and programs that can be executed by the Integral PC's PAM shell can be written in a file; if the command "chmod +x " command is used to make this file "executable", when this "script" is invoked (by typing its name into PAM), PAM will sequentially try to execute all the commands and programs in the file. If a script is given the name "Autost" and placed on, say, a floppy disc, then, when the floppy disc is inserted into an IPC and the IPC is turned on, PAM will execute the "Autost" script automatically. "Autost" scripts are particularly useful for configuring the system at power-up, since they allow complicated sequences of actions to take place without the user knowing anything about what is going on. Getting an "Autost" script to work can be a little tricky - but there are tools available for the IPC to make things a little simpler: + press - allows a scriptfile to simulate inputs to a program. + sleep - provides delays for the scriptfile. (Both these utilities are available on this disc.) Explaining how all this software works would take a long time; there are document files elsewhere that discuss their fine details, so I must refer you to them. However, an example will serve to get you started. I had a Tech BASIC user with some problems, and I used an "Autost" script to help him out. The customer had two problems: he provide an alphanumeric display that could be read from several feet away and get IPC "Autost" scripts working properly. To quote from the letter I sent him: "Handling `Autost' scripts can be tricky. First, some background ... " "On power-up, the IPC goes through some initializations and then invokes PAM to execute the `Autost' script. However, PAM remains invisible until it is done executing all the commands in the `Autost' script, and only then pops up its window and softkeys." "PAM goes through the `Autost' script and executes each item in the file in sequence. One fine point: if a program name is simply entered as a line in the `Autost' script, PAM will NOT go on to the next item until that program has finished execution. That means that if the first item in the list is: &k3Sbasic&k0S - none of the rest of the script will be executed until BASIC is exited. This causes trouble if you want to execute something besides BASIC - but there is a workaround." "If you follow the program name with an `&', PAM will run the program `in the background'; PAM will spawn the program off as an independent process and then go on its merry way, executing the subsequent lines in the `Autost' script. For example, if you enter: &k3Sbasic &&k0S - in the `Autost' script, BASIC will be invoked, and then PAM will execute the next line in the script." "So, that being said ... I wanted to run the BASIC `time.pgm' demo program from an `Autost' script to illustrate how to configure the system using such scripts. I wanted to: 1. Invoke BASIC (which assumed to be in ROM). 2. Use `set_win' to expand the BASIC display to cover the screen. 3. Use `set_font' to load a large font into the BASIC display. 4. Load the `time.pgm' demo into BASIC and run it. This is not as easy as it looks. The first step is easy, though, I've already discussed that; I invoked BASIC in the first line of the script with: &k3Sbasic &&k0S The next step was to change the window and load the font. Unfortunately, once PAM has invoked BASIC in the background, it IMMEDIATELY executes the next line of the `Autost' script; if `set_win' and `set_font' are the next lines, BASIC will not have enough time to bring up its window." "Since both `set_win' and `set_font' need to have a window present to work, they will, in this case, both fail and output error messages. Not good." "But that was easy to fix; I can easily make PAM waste time by forcing it to echo strings into nowhere as follows: &k3Secho "This dummy string exists to waste time" > /dev/null&k0S So what's this `/dev/null' business, you ask? Well, all devices - printers, disc drives, windows (which look like terminals to the operating system) - in the Integral's UNIX (tm) system are all accessed just like files; they each have file names in a special directory, the `/dev' directory." "The `null' device file is just that - no device at all. A strange concept, to be sure - it's used in situations (like this one) where you want to make sure the output of a program remains hidden. (The `/dev/null' device file is affectionately referred to as the `bit bucket'.)" "So (back to the point) I wasted time by placing lines in the `Autost' script that echo strings into `/dev/null'. Of course, since I WANTED to waste time, I did not run the `echo' commands in the background; I left the `&' off the end of the lines." "(By the way, there is also a utility - called `sleep' - that comes with HP-UX Tools that will simply kill time for a specified number of seconds. This is a slightly more elegant way of killing time, but it also requires adding another utility to the autostart disc.)" "I then followed these lines with the invocations for `set_win' and `set_font'. (I ran them in the background - with an `&' - since there was no particular need for delay in that case.)" "The next step - loading the `time.pgm' file into BASIC - was tricky." "BASIC has no provision for handling command-line arguments - that is, I can't write: &k3Sbasic -saved time.pgm &&k0S - in the `Autost' script and have BASIC execute the SAVEd `time.pgm' file on invocation. (This is an odd oversight on the part of BASIC's designers on which I will not comment further ... )" "A workaround was designed called `bas_start' that simply `types in' the proper commands to the BASIC window - but there is another, much more powerful, utility, called `press', that allows you to simulate keyboard inputs to ANY window." "The `press' utility has the syntax: &k3Spress "Some string" window_name&k0S For example, if I wanted to enter a line in the `Autost' script to tell BASIC to `run' whatever is loaded into it, I would write: &k3Spress "run\r" basic&k0S (The `\r' instructs `press' to send a carriage return.) When PAM executes this line, these characters are entered into BASIC just as if they had been typed in." "The `press' program is very useful in `Autost' scripts, since it allows the script to `sit at the keyboard' and enter commands." "(A warning, though; `press' can't send strings to PAM from the `Autost' script, since there isn't a PAM window there while PAM is executing the script. In another case I managed to work around this by creating a PAM window from the `Autost' script, using `set_win'; this seemed to work okay, but I have some questions about how often I could get away with it.)" "One more comment on `press'; `press' interprets some character sequences specially - like the `\r' in the example - and it can be painful to try to send these special characters to the target window. However, these special characters can ALWAYS be sent by inserting their octal equivalent into the string; for example, a double quote (") can be embedded in the string by inserting a `\042' - the octal code for a double quote." "So, after I used `set_win' and `set_font' to configure the window, I used `press' to tell BASIC to GET `time.pgm'." "Since a GET takes a little time, I used more `echoes' to waste time - and then finished off the script with a final line that uses `press' to send a `run' command to BASIC to run `time.pgm'." "So that finished the `Autost' script - but that didn't get me completely out of the woods. You see, after PAM was done with the script, its window came up - and left its softkey labels on the display under the BASIC window." "I didn't want the softkey labels there, but I had the damnedest time figuring out how to get rid of them. BASIC could turn off its own softkeys, using a TERM0 escape sequence: &k3SDISP "~027&j@"&k0S - but it couldn't turn off PAM's so easily." "I sweated that one for a long time ... until I remembered that each window on the IPC display looks like a terminal, with an entry in the `/dev' directory that can be accessed like a file." "So I simply had `time.pgm' `store' the escape sequence in the device file for the PAM window: &k3SASSIGN 11 TO "/dev/screen/PAM"&k0S &k3SOUTPUT 11 ; "~027&j@"&k0S &k3SASSIGN 11 TO "*"&k0S Worked like a charm. (I had to insert a WAIT 1000 command in the BASIC program to make sure that the PAM window was on the screen before the BASIC program turned off its softkey labels.)" "By the way, this was NOT the same as doing a `press' to the PAM window. The `press' utility actually opens up the window's keyboard buffer and stuffs characters into it; the characters are then read by the program using the window, just as if they had been typed in." "Writing to the device file for the window simply writes characters straight to the display window; the program using the window nevers sees them." You can generally get "Autost" scripts to work with a little practice. However, if you have severe problems with them, you might consider another alternative: the "daemon" utility. This utility allows you to send PAM commands from BASIC simply by opening a file and writing the command string into it. See the "daemon.doc" file for more details.