On Feb 16, 8:08*am, sh <sham... (AT) prupipe (DOT) com> wrote:
Three ways.

One character input, as has been suggested above.
Accuterm which has VB scripting built in, replaces your entire process
from dirt to shirt including launching the Pick application.

Third, the POKE command forces Input to wake up.

On 2/17/2011 11:47 AM, wjhonson wrote:
POKE works nicely.

On Feb 18, 1:31*am, sh <sham... (AT) prupipe (DOT) com> wrote:
Very light on resources .... IN either gets a character of input OR
times out in 10 seconds and, if nothing else to do, just goes back
looking for a single character input again. We bypass the IN if we are
running a keystroke macro, biut that is another story

On Feb 16, 11:08*am, sh <sham... (AT) prupipe (DOT) com> wrote:
Absolutely and I've done it many times in D3/Linux, for different
purposes. This solution will work on any platform, though. One of the
main uses was for a shipping scale input that queries a socket for
live weight values and also responds to keyboard input while that's
happening. It's pretty nifty watching the numbers change as you affect
the scale, but you can still hit "M" to force a manual entry or <ESC>
to bail the input at any time.

If you have input control in the prompt routine then loop around the
SYSTEM(14) variable until either a trigger file is seen or SYSTEM(14)
returns a value. If SYSTEM(14) has a value then you switch to your
normal keyboard buffer input code and redraw the input mask if needed.
If your prompt routine accepts stacked input from DATA statements then
you'll want to also check for SYSTEM(10) to see if a stack is active
each pass. Stack data does not appear in SYSTEM(14) IIRC so you need
to check both in that case.

LOOP UNTIL EXIT = 1 DO
IF SYSTEM(14) THEN
* CALL YOUR INPUT CODE TO PULL FROM KB BUFFER
END
IF SYSTEM(10) THEN
INPUT STACKED.INPUT.DATA
* RETURN THE STACKED INPUT TO CALLING PROGRAM
END
* SCAN FOR A FILE
* RETURN DATA TO CALLING PROGRAM OR CONTINUE LOOPING
DUMMY=SYSTEM(13) (TIME SLICE RELEASE TO AVOID SPINNING PROCESSES)
REPEAT

GlenB

On Feb 22, 10:16*pm, GlenB <batch... (AT) bellsouth (DOT) net> wrote:

I take that back. You don't need to loop on SYSTEM(10). I don't
think there is a way to stack onto the call once it's active. You only
need to check SYSTEM(10) for an active stack condition at the initial
start-up. If you POKE data to the port the input routine is running on
it will show up in the input buffer under SYSTEM(14).

** removed SYSTE(10) check ***

GlenB

If you want to poll something and allow input the easiest way is to
use SYSTEM(14) input buffer character buffer count.
So instead of sitting at INPUT sit in a loop checking for the two
circumstances that you want. If the operator enters anything
SYSTEM(14) will be greater than zero so simply GO/RETURN to your INPUT
command however if one of your telephone records turns up load a DATA
statement and GO/RETURN to your INPUT statement.
Peter McMurray

Sholom,
You have several issues to tackle:
1) You vant to know that some event happened.
2) You want to make the operators aware that an event is pending while
the operator does something unrelated and sits at input prompt.
3) You want to assign the event handling to one operator only.

One possible solution is as follows:
1) Have a phantom that SELECTs the directory in question every so
often, let's say once every 5 seconds.
When an event takes place, set a system LOCK.
2) Broadcast a message to all available operators (ports) using MSG.
3) As soon as an operator starts the responding program, the program
should check for the system lock and continue by clearing it if is set
or othewise stop (if is no longer set that means somebody else took
the call).

Note: When an operator becomes available the program writes the port
number to a file pooled by the phantom.
The phantom then sends messages only to ports shown in this file. Of
course once a call is taken, the program should remove the port number
from the file. The same can be done with system locks if you have
enough available.

Lucian