@FGWIN[]

[vefatica]

I'm working on an @FGWIN[] function for the SYSUTILS plugin. It will return info about the foreground window.

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?

 

[Jim Cook]

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:

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

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

 

[Steve Fabian]

| 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

 

[Steve Fabian]

| 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

 

[vefatica]

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

 

[vefatica]

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.

 

[Steve Fabian]

| 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

 

[vefatica]

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.

 

[Steve Fabian]

| 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

 

[vefatica]

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

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.

 

[vefatica]

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.