T.R | Title | User | Personal Name | Date | Lines |
---|
517.1 | A couple of ideas | CSC32::HAGERTY | Dave Hagerty, TSC, Colorado Springs | Sat Jul 25 1987 02:34 | 10 |
| You could lib$spawn yourself a subprocess and put the output into
either a mailbox or a file, then smg$put_with_scroll that data into
a virtual display. If you want to do it all in the context of the
same process, you will have to write some special code to do it.
I have done this with a condition handler in which I used either
$getmsg or $Putmsg with an action routine, built the string from
the arguments passed to the condition handler, then
smg$put_with_scroll'ed that string.
Dave()
|
517.2 | Try CLT::SMG and V5.0 SMG kit | UBEAUT::MACKAY | Don Mackay | Sat Jul 25 1987 19:55 | 5 |
| Try also the CLT::SMG notes file, especially the V5.0 SMG kit as
that has SMG$CREATE_SUBPROCESS, SMG$DELETE_SUBPROCESS AND
SMG$EXECUTE_COMMAND procedures that work with virtual displays.
Don
|
517.3 | Hooks in $PUTMSG for this (?) | SMAUG::MENDEL | | Wed Jul 29 1987 13:40 | 14 |
| (The following is theory ... that is, I've never actually tried
it.)
By using $PUTMSG, an Action Routine can be specified, and this
action routine is called with a descriptor of the message text.
In the action routine, you can look at (and do something with)
the text that gets written. The, by returning a failure status
in the action routine, the message is not printed.
In this way, you can catch the message before it is written and
pass it to SMG.
Kevin Mendel
|
517.4 | | SQM::RICO | | Thu Jul 30 1987 13:31 | 7 |
| Re .3
It works. I have an application that uses $PUTMSG extensively,
where all output actually goes to a mailbox instead of
SYS$OUTPUT/SYS$ERROR, using the technique you describe.
Rico
|