Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

At 01 MAY 1998 05:44:54PM Roy Drummond wrote:

I am trying to run a program from the Replace Background Process for our non-indexer users in our network. The program will execute once based on the Delay Before Indexing prompt, but will never execute the program based on the Time Between Index Checks prompt. In other words, program will execute after 10 seconds based on the Delay prompt, but never execute a second time based on the Time Between prompt, which is set for 1 second. If I do anything in the system the Delay will execute the program 10 seconds later.

Is this an "undocumented feature" or am I doing something wrong? :-)

TIA,

Roy


At 01 MAY 1998 06:03PM Roy Drummond wrote:

I just read Mark Caldwell's thread from 4/16-25/98. We seem to have a similar, if not identical, problem. I can't seen to get the second hit on my program when there is no activity.


At 03 MAY 1998 11:13AM Aaron Kaplan wrote:

Replace processes can be tricky. When they are called, they have to be a subroutine. Also, a replace process does not have a post process. The standard indexing routine has a post process, but not the replace. Since you are replacing the process, you have to add in your own timing loops to call the post process. it might sound muddy, but think about it and it will make sense.

For the replace itself, you need to have the program as a subroutine, with a return. You can't have STOP or ABORT calls. If it still does not want to continue, at the end of the routine, place a non-affecting character into @DATA, like Ctrl-Z.

apk@sprezzatura.com

Sprezzatura, Inc.

www.sprezzatura.com_zz.jpg


At 03 MAY 1998 11:31AM Andrew P McAuley wrote:

Well trawling RevMedia FKB came up with this from the year dot…

amcauley@sprezzatura.com

Sprezzatura Ltd

World Leaders in all things RevSoft

Version 2

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 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. IF X THEN &#9;IF @CAPTURE THEN &#9;&#9; @SCRIPT := X &#9;END &#9;@DATA := X END Copyright Sprezzatura Ltd - REVMEDIA (Volume 2, Issue 10, Page 4) [/b][/size] </QUOTE> —- === At 04 MAY 1998 11:13AM Roy Drummond wrote: === <QUOTE>Anderw & Aaron, 1000 pardons… I have had the RevMedia FKB disk since I first found out about it. It is great and everyone should get one. (Unsolicited endorcement) Unfortunately, I forgot to check it. :-( I have been investigating the situation more, thanks to both of your suggestions, and have gotten the process to work and now better understand HOW it works. The setting of @DATA did the trick, fake left arrow keystroke works in menus and windows, so the Delay Before Indexing (@INDEX.TIME) value is being used. Now correct me if I am wrong, Time Between Index Checks (@BACKGROUND.TIME) is NEVER used beacuse it is accessed from INDEX.CONTROL and I do not call this because I do not want the stations to update the indexes in the background. I found the following in RTI Tech Bullitin (KB version) R49 that lead to this conclusion. "Second, INDEX.CONTROL attempts to update an index. Upon completion it waits for a keystroke. If no keystroke is found in a specified period of time, it attempts to update another index. (This second delay is the time specified in the prompt Time between index checks.) INDEX.CONTROL will continue to process index transactions until the user presses a key. If an update is in progress, it finishes. Keyboard control is then returned to the user." I hope this info will be of help to others. Thanks for your help, Roy </QUOTE> View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/f84cf6655df10150852565f7007777a2.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1