Re: WATCHWIN added to 4THREADS plugin (test)

[Steve Fabian]

Vincent Fatica wrote:
| Steve (and others), I added WATCHWIN to the 4THREADS plugin. It'll
| watch for the creation of windows meeting specified class/caption
| (regex) requirements. Watching for the destruction of windows is
| pretty useless since you after getting EVENT_OBJECT_DESTROY you can't
| find out anything about the (just destroyed) object.

I have a use for watching for wndow destruction. I create the window with
the TCC command "START", but cannot use /WAIT, because after the window is
created, I use ACTIVATE to change its title. The program has nothing to do
until the window is closed.

I suppose I could change my logic to use WATCHWIN for the creation of the
window, and have it issue the ACTIVATE command; this would allow START /WAIT
(of course, the WATCHWIN would have to be issued first).

What happens if the TCC instant which used WATCHWIN to create a thread is
terminated without using WATCHWIN to kill that thread?
--
Steve

 

[vefatica]

On Wed, 27 Aug 2008 13:25:54 -0500, Steve Fábián <> wrote:

>Vincent Fatica wrote:
>| Steve (and others), I added WATCHWIN to the 4THREADS plugin. It'll
>| watch for the creation of windows meeting specified class/caption
>| (regex) requirements. Watching for the destruction of windows is
>| pretty useless since you after getting EVENT_OBJECT_DESTROY you can't
>| find out anything about the (just destroyed) object.
>
>I have a use for watching for wndow destruction. I create the window with
>the TCC command "START", but cannot use /WAIT, because after the window is
>created, I use ACTIVATE to change its title. The program has nothing to do
>until the window is closed.

The problem is that **I** can't get any info on what's been destroyed so I can't
figure out if it's one you're watching.

>
>I suppose I could change my logic to use WATCHWIN for the creation of the
>window, and have it issue the ACTIVATE command; this would allow START /WAIT
>(of course, the WATCHWIN would have to be issued first).
>
>What happens if the TCC instant which used WATCHWIN to create a thread is
>terminated without using WATCHWIN to kill that thread?

In general, when an app terminates, all it's threads end. WATCHWIN doesn't
create threads.

 

[vefatica]

Steve, if you think you can make this new syntax work to advantage, try 4threadsexp.zip (usual location).

v:\> watchwin /?
WATCHWIN id command [class_regex [caption_regex]] (creation)
WATCHWIN id command 0xXXXXXXXX (destruction)
WATCHWIN /L(ist) [id_regex]
WATCHWIN /K(ill) [id_regex]
Default regex: "."; quote args with spaces; \" = literal quote
Transient variables: %%WW_CAPTION, %%WW_CLASS, %%WW_HANDLE, %%WW_ACTION
%%WW_ACTION = CREATE or DESTROY(*) (* %%WW_CAPTION, %%WW_CLASS not set)
​

P.S. "Destroy" watches automatically kill themselves when satisfied.

 

[vefatica]

Steve (or anyone else interested). I had an idea for an addition to SYSUTILS.

WAITWIN /C|/D [/R(egex)] [CaptionFilter [ClassFilter]]

/C | /D - wait for creation|destruction
/R - use regex filters (default wildcards)
default filters "*" | "."
​

Do you think it would be useful ... have any suggestions?

 

[Steve Fabian]

vefatica wrote:
| Steve (or anyone else interested). I had an idea for an addition to
| SYSUTILS. WAITWIN /C|/D [/R(egex)] [CaptionFilter [ClassFilter]]
|
| /C | /D - wait for creation|destruction
| /R - use regex filters (default wildcards)
| default filters "*" | "."
|
| Do you think it would be useful ... have any suggestions?

Yes, it would be useful. I currently have several calls to my batch files
that wait for creation or destruction of a window with a specific title.

It would be useful to be able to specify multiple window properties, esp.
"visible".

In all commands that wait for an event there ought to be an option to time
out after a user-speciable delay.

Another command that would be useful is a combination of "activate" and
"keystack", i.e., a command issued by the batch program that delivers
keystrokes to the specified window. An alternate to delivering keystrokes
could be to preload the clipboard and paste into the window. In some
situations I need to deliver multiple sets of keystrokes.
--
TIA, Steve

 

[vefatica]

On Sat, 30 Aug 2008 09:37:17 -0500, Steve Fábián <> wrote:

>vefatica wrote:
>| Steve (or anyone else interested). I had an idea for an addition to
>| SYSUTILS. WAITWIN /C|/D [/R(egex)] [CaptionFilter [ClassFilter]]
>|
>| /C | /D - wait for creation|destruction
>| /R - use regex filters (default wildcards)
>| default filters "*" | "."
>|
>| Do you think it would be useful ... have any suggestions?
>
>Yes, it would be useful. I currently have several calls to my batch files
>that wait for creation or destruction of a window with a specific title.

I have a working skeleton.

Are regexes necessary; would wildcards suffice?

>It would be useful to be able to specify multiple window properties, esp.
>"visible".

I suppose I could do that. But how well it would work would depend on whether
the window's creator made it visible at creation time (it's common *not* to do
so). I suppose WAITWIN would be used in familiar situations, where the user
knows if a delay might be necessary after window creation and before ACTIVATE,
KEYSTACK, et c.

>In all commands that wait for an event there ought to be an option to time
>out after a user-speciable delay.

That's planned.

What about <Ctrl-C> (et al.)? In addition to cancelling the wait, should it be
passed to a higher level?

>Another command that would be useful is a combination of "activate" and
>"keystack", i.e., a command issued by the batch program that delivers
>keystrokes to the specified window. An alternate to delivering keystrokes
>could be to preload the clipboard and paste into the window. In some
>situations I need to deliver multiple sets of keystrokes.

The user can already do those things.

 

[vefatica]

Re WAITWIN, this is what I have so far:

WAITWIN [/D|/S] [/R] [/CLASS expr] [/CAPTION expr] [/TIMEOUT sec]

/D - wait for window destruction (*default: creation)
/S - wait for window show (*)
/R - expressions are regexes (default: wildcard)
The default expressions match all
​

The "/S" option should take care of requiring the window to be visible. Control signals *are* passed on to TCC after cancelling a wait (so the default or "ON BREAK" behavior will follow).

 

[Steve Fabian]

vefatica wrote:
| Re WAITWIN, this is what I have so far:
| WAITWIN [/D|/S] [/R] [/CLASS expr] [/CAPTION expr] [/TIMEOUT sec]
|
| /D - wait for window destruction (*default: creation)
| /S - wait for window show (*)
| /R - expressions are regexes (default: wildcard)
| The default expressions match all
|
| The "/S" option should take care of requiring the window to be
| visible. Control signals *are* passed on to TCC after cancelling a
| wait (so the default or "ON BREAK" behavior will follow).

Sounds good. BTW, for me simple wildcards (same as in DIR) would be
sufficient.
--
Steve

 

[vefatica]

Re WAITWIN, this is what I have so far:

WAITWIN [/D|/S] [/R] [/CLASS expr] [/CAPTION expr] [/TIMEOUT sec]

/D - wait for window destruction (*default: creation)
/S - wait for window show (*)
/R - expressions are regexes (default: wildcard)
The default expressions match all
​

The "/S" option should take care of requiring the window to be visible. Control signals *are* passed on to TCC after cancelling a wait (so the default or "ON BREAK" behavior will follow).

What should happen, when waiting for creation/show, if a window matching the specs already exists?

 

[vefatica]

I had asked: "What should happen, when waiting for creation/show, if a window matching the specs already exists?"

I'm going to add an option to control this. Which behavior should be the default for WAITWIN/CREATE and WAITWIN/SHOW (and which the optional behavior) ...

1. return immediately if an existing window satisfies the criteria

2. ignore existing windows

 

[Steve Fabian]

vefatica wrote:
| I had asked: "What should happen, when waiting for creation/show, if
| a window matching the specs already exists?"

Sorry, my "barely teenager" son had the computer most of the day.

| I'm going to add an option to control this. Which behavior should be
| the default for WAITWIN/CREATE and WAITWIN/SHOW (and which the
| optional behavior) ...
|
| 1. return immediately if an existing window satisfies the criteria
|
| 2. ignore existing windows

I assume WAITWIN is a command that delays the current TCC execution until
the specified event occurs. This requires that the TCC command causing the
event must be issued before WAITWIN. If that previous command starts a new
Windows process. e.g., "START firefox.exe -url xxx" the WAITWIN command may
be executed either before or after the creation of the new window, dependent
upon system speed. If /C[REATION] ignores windows that already exist, but
/S[HOWN] accepts them, the user has full control when the next command is
executed. Thus I think /C should use option 2, and /S use option 1 above.
Undoubtedly /D would return immediately if no matching window exists at the
time WAITWIN is issued.
--
TIA, Steve

 

[vefatica]

On Sun, 31 Aug 2008 07:08:54 -0500, Steve Fábián <> wrote:

>| I'm going to add an option to control this. Which behavior should be
>| the default for WAITWIN/CREATE and WAITWIN/SHOW (and which the
>| optional behavior) ...
>|
>| 1. return immediately if an existing window satisfies the criteria
>|
>| 2. ignore existing windows
>
>I assume WAITWIN is a command that delays the current TCC execution until
>the specified event occurs. This requires that the TCC command causing the
>event must be issued before WAITWIN. If that previous command starts a new
>Windows process. e.g., "START firefox.exe -url xxx" the WAITWIN command may
>be executed either before or after the creation of the new window, dependent
>upon system speed. If /C[REATION] ignores windows that already exist, but
>/S[HOWN] accepts them, the user has full control when the next command is
>executed. Thus I think /C should use option 2, and /S use option 1 above.
>Undoubtedly /D would return immediately if no matching window exists at the
>time WAITWIN is issued.

I agree 100% and could adjust the default behaviors as you suggest while adding
a single option to use the other behavior. It'd be a tad complicated for users.

I suspect waiting for a window to be shown would be the most used option. Maybe
it should be the default (with /C(reate) and /D(estroy) as options). Eh?

 

[vefatica]

This is what I've got.

WAITWIN [/C|/D] [/i] [/T N] [/CLASS expr] [/CAPTION expr] [/EXEC command]

/C wait for window CREATE (*default: wait for SHOW)
/D wait for window DESTROY (*)
/I include existing windows (CREATE, SHOW)
/T timeout, N = seconds
expr wildcard expression, default: *, quote exprs with spaces
/EXEC must be last, no surrounding quotes; execute command
when watch has been established
​

/EXEC is a convenient way to avoid starting a program and *then* looking for its window (possibly after it has been created/shown). /EXEC will execute the command after the watch mechanism has been established. So, for example, instead of

firefox
waitwin /caption *firefox*
​

you can

waitwin /caption *firefox* /EXEC firefox
​

and it will be guaranteed that WAITWIN will be watching when the firefox window is shown.

If you want to try it get

ftp://lucky.syr.edu/4plugins/sysutils-exp.zip
​