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

@FGWIN[]

Discussion in 'Plugins' started by vefatica, Aug 17, 2010.

  1. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    I'm working on an @FGWIN[] function for the SYSUTILS plugin. It will return info about the foreground window.

    Code:
    g:\projects\4sysutils\release> syshelp @fgwin
    @FGWIN[H(andle)|T(itle)|C(lass)|P(id)|M(odule)|PX(pos)|PY|SX(size)|SY]
    One problem is that the foreground window could change between calls to @FGWIN. I could make a "static" version of it (either @FGWINS[] or @FGWIN[option[,s]]) which would **not** re-determine the foreground window. This would make it more difficult to use but I can't think of another way around the difficulty.

    Any thoughts?
     
  2. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    Two ideas off the top of my head:

    1) Return an array of all values in either an array var or CSV list or
    ...(be careful that future implementations could exceed expected storage?)

    2) Have an additional call that would latch all values for future calls. I
    guess then you'd need a call to stop the latch and provide live data.

    On Tue, Aug 17, 2010 at 9:37 AM, vefatica <> wrote:




    --
    Jim Cook
    2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Monday.
     
  3. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | I'm working on an @FGWIN[] function for the SYSUTILS plugin. It
    | will return info about the foreground window.
    |
    |
    | Code:
    | ---------
    | g:\projects\4sysutils\release> syshelp @fgwin
    | @FGWIN[H(andle)|T(itle)|C(lass)|P(id)|M(odule)|PX(pos)|PY|SX(size)|SY]
    | ---------
    | One problem is that the foreground window could change between calls
    | to @FGWIN. I could make a "static" version of it (either @FGWINS[]
    | or @FGWIN[option[,s]]) which would **not** re-determine the
    | foreground window. This would make it more difficult to use but I
    | can't think of another way around the difficulty.
    |
    | Any thoughts?

    My guess is that the function parameter is used to specify the property
    of the FG window the function is to return. Two alternatives:
    - a unique internal variable for each property
    - a single internal variable which obtains all of the properties, and
    returns them as a commad-separated list, with string values in quotation
    marks
    Another alternative to the 2nd choice above is a function whose
    parameter is the list of properties to be returned as a comma-separated
    list, in the order the properties are specified; e.g.:

    echo %@FGWIN[C T M PX PY]

    BTW, I'd recommend:
    X Y position (always upper left corner) - does not require the P prefix
    W width
    H height
    R right edge
    B bottom edge

    H is a conflicting first character: handle, height. You'd need to come
    devise alternate words/codes. Single character codes make parsing simpler,
    and allow contracted representation, e.g. (for previous example):

    echo %@fgwin[ctmxy]
    --
    HTH, Steve
     
  4. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | 2) Have an additional call that would latch all values for future
    | calls. I guess then you'd need a call to stop the latch and provide
    | live data.

    This would be akin to @fileopen/@fileread/@fileclose, only slightly
    cumbersome.
    --
    Steve
     
  5. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    On Tue, 17 Aug 2010 12:57:50 -0400, you wrote:

    | Another alternative to the 2nd choice above is a function whose
    |parameter is the list of properties to be returned as a comma-separated
    |list, in the order the properties are specified; e.g.:
    |
    | echo %@FGWIN[C T M PX PY]

    [Thanks to Jim, too.] I like that. Originally I wanted to return all
    the info and not worry about the fgwin changing of being closed. With
    your idea, Steve, the user can specify what he wants (and then
    shouldn't feel too bar about having to parse it, say with @WORD (which
    should suffice if I quote the class and title)).
     
  6. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    On Tue, 17 Aug 2010 12:57:50 -0400, you wrote:

    |BTW, I'd recommend:
    |X Y position (always upper left corner) - does not require the P prefix
    |W width
    |H height
    |R right edge
    |B bottom edge
    |
    |H is a conflicting first character: handle, height. You'd need to come
    |devise alternate words/codes. Single character codes make parsing simpler,
    |and allow contracted representation, e.g. (for previous example):
    |
    | echo %@fgwin[ctmxy]

    Agreed. I could just leave out H(andle). There's nothing you can do
    with it in TCC anyway.
     
  7. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | On Tue, 17 Aug 2010 12:57:50 -0400, you wrote:
    |
    || BTW, I'd recommend:
    || X Y position (always upper left corner) - does not require the P
    || prefix
    || W width
    || H height
    || R right edge
    || B bottom edge
    ||
    || H is a conflicting first character: handle, height. You'd need to
    || come devise alternate words/codes. Single character codes make
    || parsing simpler, and allow contracted representation, e.g. (for
    || previous example):
    ||
    || echo %@fgwin[ctmxy]
    |
    | Agreed. I could just leave out H(andle). There's nothing you can do
    | with it in TCC anyway.

    Any activity since?

    BTW, I'd like the following features in your various plugins:

    4console - CONSIZE command:
    /Q act as afteraction report, allowing to combine it with actions
    /X to override all other actions and maximize current console to whole
    usable area (if toolbar is always displayed only above toolbar)

    SYSUTILS
    WAITWIN
    - does "/EXEC command" make it effectively an "ON WAITWIN"?
    - other window events:
    becoming FG
    becoming BG
    content change
    receiving keystroke or click
    --
    Steve
     
  8. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    On Sat, 25 Sep 2010 08:41:49 -0400, you wrote:

    |Any activity since?

    I did take "handle" out of @FGWIN.

    |BTW, I'd like the following features in your various plugins:
    |
    |4console - CONSIZE command:
    | /Q act as afteraction report, allowing to combine it with actions
    | /X to override all other actions and maximize current console to whole
    |usable area (if toolbar is always displayed only above toolbar)

    Do you mean taskbar? CONSIZE is a monster already, very complicated (not the
    best example of my programming). I'm not inclined to mess with it.

    The first above you can do with little trouble and the second with a little more
    trouble.

    The Windows API has GetLargestConsoleWindowSize() which does not work perfectly.
    My routine is a little better but still not perfect. Without the user doing
    some testing, maximizing the console (as above) can fail and I'd rather not
    build that into CONSIZE. I will consider _MAXCONX and _MAXCONY (as CONSIZE
    computes them). They'd make it easier do do what you want.

    |SYSUTILS
    |WAITWIN
    |- does "/EXEC command" make it effectively an "ON WAITWIN"?

    If I understand you correctly, no. WAITWIN always waits.

    |- other window events:
    | becoming FG
    | becoming BG
    | content change
    | receiving keystroke or click

    WAITWIN uses a WinEventHook which can't do 3 amd 4 above. It does receive
    EVENT_SYSTEM_FOREGROUND which should allow 1 and 2 above. I vaguely recall
    EVENT_SYSTEM_FOREGROUND not being reliable for some reason. When I get time
    I'll experiment more.
     
  9. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | Do you mean taskbar? CONSIZE is a monster already, very complicated
    | (not the best example of my programming). I'm not inclined to mess
    | with it.
    Yes, I meant taskbar.
    |
    | The first above you can do with little trouble and the second with a
    | little more trouble.

    OK.

    || SYSUTILS
    || WAITWIN
    || - does "/EXEC command" make it effectively an "ON WAITWIN"?
    |
    | If I understand you correctly, no. WAITWIN always waits.

    Too bad. For example at times the event awaited is either a new popup (e.g.
    "You won") or the closing of the window, and currently I can only determine
    which, if either, condition occurred by a polling loop (which is less
    accurate in timing if that's what I wanted to do, and uses more resources).

    || - other window events:
    || becoming FG
    || becoming BG
    || content change
    || receiving keystroke or click
    |
    | WAITWIN uses a WinEventHook which can't do 3 amd 4 above. It does
    | receive EVENT_SYSTEM_FOREGROUND which should allow 1 and 2 above. I
    | vaguely recall EVENT_SYSTEM_FOREGROUND not being reliable for some
    | reason. When I get time I'll experiment more.

    Thanks.
    --
    Steve
     
  10. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    The waiting is the whole point of WAITWIN (hence the name). Maybe Rex will add WINDOWMONITOR in v13. FYI, the "/EXEC command" option went away a long time ago but still appears in the help. I figure the user can test the return code (0 = wait satisfied) and act accordingly.

    Do you think waiting for move_start/move_end is useful? I don't. I'm thinking of replacing them with /F(oreground) and /B(ackground) but either of those will only be triggered when there's a **change** in the foreground window (I'm not sure they'll be useful either).

    Maybe a better idea would be an ONFOREGROUND function (with /G(ain), /L(oss), /C(ancel, /EXEC ... ) options) which would run in the background and do something whenever the console (or specified???) window gained/lost the foreground.
     
  11. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    P.S. Is there (built-in or plugin) a variable to tell whether the console window is in the foreground? You could figure it out with @FGWIN, but something simple like _FGCONSOLE = 0 | 1 would be easier.
     

Share This Page