TPU 'setTimeout()' Function

[Robert Atkinson]

I've read through the TPU manuals pretty rigorously, but I've never come across a function to add a timer to the TPU editor.

Basically, I want a routine called every n seconds, regardless. I'm actually trying to emulate the 'READ /TIMEOUT' command within TPU, but TPU seems to require some kind of keyboard input before it will do anything.

The closest I've seen is SET (TIMER), but this isn't really what I want.

Anyone thing of any workarounds or hacks?

Rob.

[John Gillings]

Rob,

You can always use a TPU Callout. You write code in any language you like, bundle it into a shareable image, and call it with CALL_USER.

There's an example in the TPU manual.

[Robert Atkinson]

Thanks John.

I'm already using one to set some DCL symbols in the same session, but as far as I can see, it can only be invoked with some kind of action from the user.

Even if it can be programmed, I lack the skills to undertake that level of C coding.

Rob.

[John Gillings]

Rob,

> it can only be invoked with some kind of
>action from the user.

You can code a call to call_user in your initialisation files. The routine takes an integer and a string as input, and returns a string. You can use the integer to implement multiple functions.

I may be missing something in your description? I'd have thought a read/timeout would be implemented like:

input=call_user(seconds,prompt);

so no need for polling.

Could you be more specific about exactly what you're trying to do?

>Even if it can be programmed, I lack the
>skills to undertake that level of C coding.

Don't sell yourself short! If you don't have a C compiler, use MACRO32. It's not rocket science.

[Robert Atkinson]

John, the application is perhaps best described with it's own help file :-

"CHOICE is an interactive menu system driven by a text file containing text and
options. Each option is defined using the '^' (carrot) character. The text file
can be created beforehand, or typed in when the CHOICE utility is run.

The utility can be run in two modes - either MENU mode or SCROLL mode.

When run in MENU mode, the user is able to move around the screen selecting any
available options. When an option is selected, the option number selected is
returned. When run in SCROLL mode, the whole line is returned."


All of the actions above are basically the TPU editor capturing all keystrokes, mostly cursor movement, and then running a function to update the screen. CALL_USER is then run when the user actually selects an option, setting a DCL symbol. (Code attached)

By it's very nature, the TPU editor sits there fairly dumb until the user presses a key. Only then can it interpret the key and actually do something.

My guess is that I'd have to ask HP to add new functionality to TPU, some sort of timer function.

If I called CALL_USER on initialisation and at every key press to setup a timer, how would it interact with TPU once control has returned back to TPU. Is there any way it could send a signal back to TPU?

Rob.

[Hoff]

TPU wasn't designed for writing applications, and it's just not very good at this task. It also seems unlikely that HP will make any particular effort to extend and enhance TPU, given that the current TPU reference manual is from 2001.

That there's effectively no debugger, no libraries, no installed base of code, no base of staff knowledge, and no portability all tends to dissuade all but the bravest of folks from using TPU for new development.

Java, Macro32, Bliss, Perl, php, Python and other languages are available for OpenVMS, and free, and I can offer Lua licenses here. (Lua is probably the closest in spirit to TPU in original intent of any of these languages; both are expressly intended to be embedded, and to extend applications for text-processing tasks.) Capabilities and debugging support and such vary in these languages, though all are far more widespread than TPU.

Regardless, my hat is off to you for accepting and for moving forward on this project using this TPU implementation. You're one crazy-brave fellow. (Raises a virtual toast to a particularly daring comrade.)

[John Gillings]

Rob,

hmmm, sounds like a very complex way to create a menu system! I'm not sure, what you want to happen on the timeout, but if it's either "abort" or "exit with current selection", there may be a way...

Assuming you can do some stuff with CALL_USER - use the integer to select different functions.

Instead of trying to timeout an I/O operation, have a timer thread that periodically checks some state variables to see if the timeout has expired.

When you start up, in your LOCAL_INIT call a routine that starts a timer AST thread. It will need variables for the current selection, and the last time something happened.

When the timer fires, check the delta from the last event. If it exceeds your threshold, exit (perhaps first setting your symbol). If the threshold has not been reached, just reschedule the timer. This is a very simple $SETIMR call.

Each time a key is pressed, use a diferent CALL_USER function to update the current selection and the last event. So, for example, your zscroll_status_line will need to CALL_USER to update the last event, as will all your other action routines.

This is a fairly radical architectural change, but it shouldn't be too difficult.

Other than that... maybe select a different language?

[Robert Atkinson]

Thanks for your help on this guys.

You're both probably right - I really shouldn't be using TPU to write something that is a screen management task. But, I'm just a bit too long in the tooth to sit and get my head round DEC-C. I'm actually rather lazy, and prefer the simpler syntaxes of languages like PHP.

I'll continue to develop the application, but it will just have to be within the bounds of what TPU can deliver and what my skills allow me to do within that environment.

Thanks again, Rob.