On Fri, 30 Jul 2010 10:24:09 -0400, you wrote:
|| Suppose I have a lingering app running started by TCC in the same
|| console; a packet-sniffer is a good example. And suppose I want
|| notification (a beep of vbeep, say) if that app writes to the
|| console. I imagine a plugin command, say, ALERT, which the user
|| would call just before starting the forementioned app, say ALERT &
|| SNIFFIT. ALERT would start a thread which polled the console for
|| its cursor position, alerting the user upon a change. Will this
| Your concept is fully in harmony with a basic UI principle I realized
|decades ago: use audible notification when user attention is desired, e.g.,
|when an action completes after taking longer than a normal human attention
|span. In interactive TCC operations I implemented this using PRE_EXEC and
|POST_EXEC: the former saves _WINTICKS, the latter executes BEEP if the time
|elapsed is more then 30s.
| I think you could use the ON CONDITION command for your situation,
|exactly as you described:
| ON CONDITION %_column NE %savedcol .OR. %_row NE %savedrow ...
I'm talking about running a console app (windump (tcpdump) in
particular) in the same console as TCC. It won't have its own window
and if it's started (as usual) from the command line I won't have easy
access to its PID. TCC's main thread will be waiting for it to
finish. I don't want to wait for it to finish. Rather, I want to
provide notification whenever it produces output. In my own thread, I
could check for a change in cursor position more efficiently than with
TCC's internal variables.
I like Scott's idea of simply piping the app through my plugin which
would just reproduce its output (and would certainly know, with no
additional effort, when there is output). But there's a speed
consideration. At high volume, windump's output can't keep up with
the arrival of information. I rarely lose packets because of the lack
of buffering but I wouldn't want to exacerbate the situation by my
also processing the output before it's displayed.
|| I'm also wondering it there's a way that thread might know when the
|| app has terminated (so it might terminate itself). I suppose a
|| keyhandler function could tell when TCC issues its next prompt (the
|| app terminated) but I'm hoping for something easier.
|Once again I think you could use "ON CONDITION NOT ISWINDOW ...", or a test
|based on PID, or a test using your WHICHWIN, ...