Hints on Writing Good Script Files [ HP DeskManager Customization ] MPE/iX 5.0 Documentation
HP DeskManager Customization
Hints on Writing Good Script Files
Now that you have some understanding of how to write script files, here
is a summary of tips that will help you write better script files.
* Plan first. Don't start to write your script file until you have
thought through what it is going to do.
* Keep the logic simple.
* Test the script in your Work Area before installing it, it is
quicker to make changes in your Work Area.
* If you write a useful routine in a script which works well, save
it. You will probably be able to use it again! If you write lots
of scripts you may find you can build new ones to suit your needs
by combining routines you have already used. These have the
advantage of already having been tested.
* When testing a script file, it is a good idea to have &Echo 1 as
the first line. When you run the script it will display on your
screen each line of the script it processes along with the result
of any substitutions or returns it is asked to make. You can see
exactly what is happening as the script is being processed and
this is a valuable debugging tool. When the script is fully
tested, change the first line to &ECHO 0 rather than removing it.
This leaves the line numbers of your script unaffected and
prevents problems if any command in the script uses line numbers.
* Labels must always start in column 1, can be up to 16 characters
in length, and can have comments on the line after them.
* In general, when using loops in scripts, it is better to use
&FORWARD $labelname rather than &FORWARD number of lines or &BACK
$labelname rather than &BACK number of lines. It is also possible
to use &GOTO line number. However, if you use this and then add a
line before this line number, (for example &ECHO 1 as the first
line to help with debugging) the script will no longer jump to the
correct line.
* You can use &SAVE Z <VAR X><VAR Y> to concatenate the values held
in variables X and Y into one string held in variable Z.
* Using &SAVE array<VAR Y> where the value of Y changes, allows you
to use array type variables.
* If you want to use case statements then you can use &FORWARD
label<VAR X>, which will go to a specific label depending on the
value of X.
* If you are writing a script with loops in it, you may want to
include one of the following statements which will ask the user if
they want to continue going round the loop:
&EXIT <NOT <YESNO <PROMPT "Do you want to continue?">>>
If the user replies that they do not want to continue, by replying
with a "NO" for example, then the script exits.
* Parameters to a script may be added on the script command line.
They are accessed from within the script by using the <PARM>
active function. For example, if you have a script called
"Letters" with four parameters as shown below:
SCRIPT "Letters" A B C D
The following line in this script:
&PRINT Your parameter four was <PARM 4>
will give the result:
Your parameter four was D
* Nested active functions are evaluated from the inside outwards as
follows:
&PRINT <ADD <MULTIPLY 2 3> 5>
&PRINT <ADD 6 5>
&PRINT 11
11 is displayed on the screen.
* Some script commands test to see if a fact is true or false. True
is represented by a value of 1 being returned, false by returning
a value of 0. If anything else is returned it is considered to be
an error. The following truth table shows the results you will
receive when testing two values, A and B:
Parameter | Parameter | Test for | Test for
A | B | A and B | A or B
| | |
---------------------------------------------------------------------------------------------
| | |
0 | 0 | 0 | 0
| | |
0 | 1 | 0 | 1
| | |
1 | 0 | 0 | 1
| | |
1 | 1 | 1 | 1
| | |
You could produce a truth table like the preceding one with the
following script:
&PRINT Parameter | Parameter | Test for | Test for
&PRINT A | B | A and B | A or B
&PRINT ________________________________________________
&PRINT | | |
&SAVE a 0
$Loop1
&SAVE b 0
$Loop2
&SAVE x <AND <VAR a> <VAR b>>
&SAVE y <OR <VAR a> <VAR b>>
&COMMENT To line up correctly <VAR a> should be in column 13,
&COMMENT | in 25, <VAR b> in 31, | in 45, <VAR b> in 31, | in 45
&COMMENT <VAR x> in 51, | in 64 and <VAR y> in 70.
&PRINT <VAR a> | <VAR b> | <VAR x> | <VAR y>
&SAVE b <ADD <VAR b> 1>
&BACK Loop2 <LESS &<VAR b> 2>
&SAVE a <ADD <VAR a> 1>
&BACK Loop1 <LESS <VAR a> 2>
&EXIT
* You are allowed to have more than one label with the same name in
a script file. If you specify &BACK label, the script will look
for the next label back with the correct name. If you specify
&FORWARD label the script will look for the next label forward
with the correct name. If no label is found, an error is
produced.
* It is a good idea to put comments in your scripts using the
&COMMENT command.
* Installed abbreviations can be accessed from within a script.
* You cannot install an abbreviation and a script with the same
name.
* You should always check that you are in the correct area of HP
Desk, for example in the In Tray or inside a message, before you
continue the execution of the script.
* The plus sign (+) allows you to respond to HP Desk prompts from
within the script file using strings or active function variables.
* Abbreviations and scripts are evaluated before commands. This
means that if you have an installed script called Read, including
the command READ in another script will execute the Read script,
not the HP Desk READ command. To override this and execute the
actual READ command, put an asterisk (*) in front of READ,
(*READ). You can limit the use of certain commands by setting up
scripts with the same name as the command. For example, you could
take away the ENCRYPT command by writing a script called Encrypt
which displays the following sentence on the screen:
You are not allowed to encrypt files!
You can only use the * function to override commands in installed
scripts or your Work Area if you have been given the capability to
install scripts. This is for security reasons, otherwise anyone
could override specially set up script commands and use commands
they were not supposed to.
* Sometimes you may want to use angled brackets with the &PRINT or
&COMMMENT directives. For example:
&PRINT Enclosed in <>
This would produce an error because the active function in the
angled brackets is evaluated and found to be incorrect. However,
the percent sign (%) can be used to prevent the evaluation of any
active functions on a line. Therefore in this case you would use:
%&PRINT Enclosed in <>
MPE/iX 5.0 Documentation