1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Re: WATCHWIN added to 4THREADS plugin (test)

Discussion in 'Plugins' started by Steve Fabian, Aug 27, 2008.

  1. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    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
     
  2. vefatica

    Joined:
    May 20, 2008
    Messages:
    8,053
    Likes Received:
    30
    On Wed, 27 Aug 2008 13:25:54 -0500, Steve Fábián <> wrote:


    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.

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

    Joined:
    May 20, 2008
    Messages:
    8,053
    Likes Received:
    30
    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.
     
  4. vefatica

    Joined:
    May 20, 2008
    Messages:
    8,053
    Likes Received:
    30
    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?
     
  5. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    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
     
  6. vefatica

    Joined:
    May 20, 2008
    Messages:
    8,053
    Likes Received:
    30
    On Sat, 30 Aug 2008 09:37:17 -0500, Steve Fábián <> wrote:


    I have a working skeleton.

    Are regexes necessary; would wildcards suffice?


    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.


    That's planned.

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


    The user can already do those things.
     
  7. vefatica

    Joined:
    May 20, 2008
    Messages:
    8,053
    Likes Received:
    30
    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).
     
  8. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    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
     
  9. vefatica

    Joined:
    May 20, 2008
    Messages:
    8,053
    Likes Received:
    30
    What should happen, when waiting for creation/show, if a window matching the specs already exists?
     
  10. vefatica

    Joined:
    May 20, 2008
    Messages:
    8,053
    Likes Received:
    30
    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
     
  11. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    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
     
  12. vefatica

    Joined:
    May 20, 2008
    Messages:
    8,053
    Likes Received:
    30
    On Sun, 31 Aug 2008 07:08:54 -0500, Steve Fábián <> wrote:


    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?
     
  13. vefatica

    Joined:
    May 20, 2008
    Messages:
    8,053
    Likes Received:
    30
    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
     

Share This Page