In order for this site to work correctly, and for us to improve the site, we need to store a small file (called a cookie) on your computer.
By continuing to use this website, you agree to our cookies and privacy policy.
  
Home page Home page Home page Home page
Pixel
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel
Pixel

Creating Your Own Background Processes

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


0001       IF X THEN @DATA := X

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.


0001       IF X THEN
0002          IF @CAPTURE THEN
0003             @SCRIPT :=  X
0004          END
0005          @DATA := X
0006       END

(Volume 2, Issue 10, Page 4)
Pixel
Pixel Footer R1 C1 Pixel
Pixel
Pixel
Pixel