Will this work?

[vefatica]

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 work?

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.

 

[samintz]

Why not do something akin to the way TEE works?

SNIFFIT | ALERT

ALERT could echo stdin to stdout and monitor the stdin traffic directly.

-Scott

vefatica <> wrote on 07/29/2010 08:09:40 PM:

> 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 work?
>
> 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.
>
>
>
>

 

[vefatica]

That certainly solves the problem of knowing when the app finishes.

On Fri, 30 Jul 2010 09:42:21 -0400, you wrote:

|Why not do something akin to the way TEE works?
|
|SNIFFIT | ALERT
|
|ALERT could echo stdin to stdout and monitor the stdin traffic directly.
|
|-Scott
|
|vefatica <> wrote on 07/29/2010 08:09:40 PM:
|
|
|
|---Quote---
|> 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 work?
|>
|> 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.
|>
|>
|>
|>
|---End Quote---

 

[Steve Fabian]

| 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
| work?

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 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, ...
--
HTH, Steve

 

[vefatica]

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
|| work?
|
| 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, ...

 

[vefatica]

On Fri, 30 Jul 2010 10:24:09 -0400, you wrote:

|I implemented this using PRE_EXEC and
|POST_EXEC:

That brings up a question for Rex. Will the real (user-defined) alias
be executed if the plugin version of one of the three special aliases
disables itself by returning 0xFEDCBA98? It would be nice to be able
to turn it on/off like that so it could be used, for example, to tell
when TCC issues its prompt (but only when interested).

 

[samintz]

If you need to launch a separate thread to play the beep or PlaySound() or
whatever mechanism you use it shouldn't add any recognizable time.

-Scott

vefatica <> wrote on 07/30/2010 11:35:27 AM:

> On Fri, 30 Jul 2010 10:24:09 -0400, you wrote:
>
>
> 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.
>
>

 

[Steve Fabian]

| 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.

Suppose you use "ON" to start your own monitoring thread?

| 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.

In my experience piping is faster than on-screen display. You could also
provide additional buffering to avoid losing data.

||| 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, ...

If you allow updaing of window titles, "iswindow" will also detect
termination.
--
Steve

 

[samintz]

This might work for you as well:

foldermonitor . /i"foo.txt" created modified forever beep exclamation
sniffit | tee foo.txt

-Scott






vefatica <>
07/30/2010 11:35 AM
Please respond to



To
[email protected]
cc

Subject
RE: [Plugins-t-2219] Will this work?






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
|| work?
|
| 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, ...