====== Creating Your Own Background Processes=====

^Published By^Date^Version^Knowledge Level^Keywords^
|Sprezzatura Ltd|01 APR 1991|2.0+|EXPERT|BACKGROUND, PROCESS, INDEX.CONTROL, INPUT.CHAR, @CAPTURE, @SCRIPT, @DATA|

Version 2.0 added the ability to add index processing hooks to be called
either in place of INDEX.CONTROL or after INDEX.CONTROL has completed its
own processing. These are defined in Management, Environment, Indexes. Many
subscribers have indicated that they steer clear of these features because
they are unsure as to how they work. This article outlines the major points
to be aware of when developing either process. A simple starting project to
experiment with on a network is an EMail process to check for mail for the
user when the keyboard is left alone. A working prototype should be possible
with less than one hours work.

==== Replace Background ====

The Replace Background routine must be a called subroutine but may then do
anything required by the developer. Note that if this is used indexes will
not be updated unless the developer calls INDEX.CONTROL when processing has
completed. If this is done, control will not be returned to the replace
background process until the user has pressed a key then left the keyboard
alone again. Once INDEX.CONTROL has been called it keeps control (see Volume
1 Issue 4 pp10,11).

==== Post Index Check ====

The Post Index Check routine must be a called subroutine but may then do
anything required by the developer. It is called from within INDEX.CONTROL
when updating indexes has completed. Note that if this is used indexes will
not continue to be updated unless the developer returns control to
INDEX.CONTROL when processing has completed. (Thus when the Post Index Check
has completed it should RETURN, not sit in a loop waiting for a keystroke.).

==== Caveats ====

In both cases the developer ought to check for the user pressing a keystroke
and return control to the user as soon as is practically possible. For this
reason routines ought to be developed in a modular fashion with checks for
input between each module. If this is not done the routine may become
unusable. Note that INPUT.CHAR should not be used to check for a keystroke
as after the wait time has elapsed it will recall the user defined routines
which will recall INPUT.CHAR, which after the wait time has elapsed will
recall the user defined routines, which ......

Bear in mind that if a key is pressed, that key MUST not be "gobbled up" but
must be passed back to the next process. For this reason an INPUT X,-1
should be used (not the INPUT statement) and the character should be put
onto the data stack IE

<code>
     IF X THEN @DATA := X
</code>

Further be aware that the user might simply have left the keyboard
unattended in the middle of a capture script. If this is the case, the
keystroke must also be included in the capture script. To see if a capture
script is active check @CAPTURE.

<code>
     IF X THEN
        IF @CAPTURE THEN
           @SCRIPT :=  X
        END
        @DATA := X
     END
</code>

(Volume 2, Issue 10, Page 4)