Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

4CONSOLE.DLL

May
3,515
5
Vince:

1/ One often wants a console window to be located with either the left side or the top (or both) at a negative coordinate value. The CONSIZE command does not permit this. Even if the /P option reserves negative values for special purposes, there is no reason why the /R option could not be used for the purpose. Currently you do not permit that, so even if the window had a negative coordinate before CONSIZE /R it will move it to nonnegative coordinates. To make the change fully backward compatible you could use a new option character.

2/ If moving or resizing fails, CONSIZE just reports the original information, with no failure indication. IMHO it would be useful if a failed CONSIZE operation would return a failure indication WITHOUT the full information display. This could be made an option thus making it wholly backward compatible.
--
Steve
 
On Mon, 07 Feb 2011 14:47:36 -0500, you wrote:

|Vince:
|
|1/ One often wants a console window to be located with either the left side or the top (or both) at a negative coordinate value. The CONSIZE command does not permit this. Even if the /P option reserves negative values for special purposes, there is no reason why the /R option could not be used for the purpose. Currently you do not permit that, so even if the window had a negative coordinate before CONSIZE /R it will move it to nonnegative coordinates. To make the change fully backward compatible you could use a new option character.
|
|2/ If moving or resizing fails, CONSIZE just reports the original information, with no failure indication. IMHO it would be useful if a failed CONSIZE operation would return a failure indication WITHOUT the full information display. This could be made an option thus making it wholly backward compatible.

Didn't we discuss this (at least 1 above) recently? CONSIZE is extremely
complicated (alas, poorly-designed from the beginning). What you ask would
require a significant revamping (which I want). That will take a big chunk of
time. When I get the leisure, I'll do it.

You may consider the output of information when you didn't ask for it an
indication of failure. I believe it returns 1 (in _?) in that case (whereas it
returns 0 when it's successful).
 
---- Original Message ----
From: vefatica
To: [email protected]
Sent: Tuesday, 2011. February 8. 11:55
Subject: RE: [Plugins-t-2586] 4CONSOLE.DLL

| On Mon, 07 Feb 2011 14:47:36 -0500, you wrote:
|
|| Vince:
||
|| 1/ One often wants a console window to be located with either the
|| left side or the top (or both) at a negative coordinate value. The
|| CONSIZE command does not permit this. Even if the /P option reserves
|| negative values for special purposes, there is no reason why the /R
|| option could not be used for the purpose. Currently you do not
|| permit that, so even if the window had a negative coordinate before
|| CONSIZE /R it will move it to nonnegative coordinates. To make the
|| change fully backward compatible you could use a new option
|| character.
||
|| 2/ If moving or resizing fails, CONSIZE just reports the original
|| information, with no failure indication. IMHO it would be useful if
|| a failed CONSIZE operation would return a failure indication WITHOUT
|| the full information display. This could be made an option thus
|| making it wholly backward compatible.
|
| Didn't we discuss this (at least 1 above) recently? CONSIZE is
| extremely complicated (alas, poorly-designed from the beginning).
| What you ask would require a significant revamping (which I want).
| That will take a big chunk of time. When I get the leisure, I'll do it.

I don't recall discussing it. I'll appreciate whenever you can do it.

| You may consider the output of information when you didn't ask for it
| an indication of failure. I believe it returns 1 (in _?) in that case
| (whereas it returns 0 when it's successful).

Yes, but I can't seem to be able to suppress the "failure" message (which one would not like in an alias or batch program), nor do I seem to be able to access the exit code within an alias. The latter, however, may be due to attempting to redirect STDOUT and STDERR to NUL:. Maybe I should use the || or && method?
--
Steve
 
On Mon, 07 Feb 2011 14:47:36 -0500, you wrote:

|1/ One often wants a console window to be located with either the left side or the top (or both) at a negative coordinate value. The CONSIZE command does not permit this. Even if the /P option reserves negative values for special purposes, there is no reason why the /R option could not be used for the purpose. Currently you do not permit that, so even if the window had a negative coordinate before CONSIZE /R it will move it to nonnegative coordinates. To make the change fully backward compatible you could use a new option character.

Steve, I sat down to work on CONSIZE (whew!). It's very complicated. The only
way I could reasonably do that is to simply remove the special meaning of
negative position coordinates (and some of the sanity-checking) and simply (try
to) move it to where the user said. I suppose I could change the /C(enter)
option to /Cn (n=1 to 9) to move the window to one of none canonical positions
according to the grid
123
456
789
(or something like that).
 
I suppose I could change the /C(enter) option to /Cn (n=1 to 9) to move the window to one of none canonical positions according to the grid
123
456
789
(or something like that).

With multiple monitors, you'd have more than nine.... Perhaps one digit 1-9 for the position, and a second (optional) to specify the monitor?
 
With multiple monitors, you'd have more than nine.... Perhaps one digit 1-9 for the position, and a second (optional) to specify the monitor?

Or retain your existing syntax, and add an option /M to select a monitor?
 
On Sun, 13 Mar 2011 14:38:22 -0400, you wrote:

|---Quote (Originally by vefatica)---
|I suppose I could change the /C(enter) option to /Cn (n=1 to 9) to move the window to one of none canonical positions according to the grid
|123
|456
|789
|(or something like that).
|---End Quote---
|With multiple monitors, you'd have more than nine.... Perhaps one digit 1-9 for the position, and a second (optional) to specify the monitor?

I'll have to work on that one. When you ask for the work area, it doesn't
include a second monitor. The easy way out would be to allow both /C and /R and
let the user add enough to the (relative) position to move it to a second
monitor. :-)
 
On Sun, 13 Mar 2011 14:43:16 -0400, you wrote:

|Or retain your existing syntax, and add an option /M to select a monitor?

Yeah, that would be easy but I don't know how to figure out if there's a second
monitor (and what its offset is). Rex ... anyone ... ?
 
On Sun, 13 Mar 2011 14:43:16 -0400, you wrote:
Yeah, that would be easy but I don't know how to figure out if there's a second monitor (and what its offset is). Rex ... anyone ... ?

I've never done it, but I suspect that GetSystemMetrics() is the place to start. Several of the items it returns relate to multi-monitor virtual desktop setups.
 
On Sun, 13 Mar 2011 15:27:22 -0400, you wrote:

|I've never done it, but I suspect that GetSystemMetrics() is the place to start. Several of the items it returns relate to multi-monitor virtual desktop setups.

Hmmm! GSM() will tell you how many monitors there are, and X and Y for the
virtual desktop, but that's it. It doesn't say where the second monitor is
(possibly with negative virtual coordinates). I suspect most uses of CONSIZE
will be automated (e.g., with an alias) so it won't be a continuing effort to
combine /R(elative) with /P(osition) or /C(anonical) to get to another monitor.

Right now I have this. Negative positions are allowed (Steve) and no
sanity-checking is done

Code:
CONSIZE ...

 Options: /W(indow)   X Y  (characters)
          /B(uffer)   X Y  (characters)
          /P(osition) X Y  (upper-left corner
     (or) /C(anonical)  N  (N=1-9, various centered positions)
          /R(elative) X Y  (pixels [+/-] from current position)
                           (after /P or /C to get to second monitor)
          /Q(uery)

 /W, /B: the one spec'd first is enforced; the other
 is enforced within the limits imposed by the first.

 If /W is missing or X (Y) is 0 the (specific) window dimension
 remains unchanged or is minimally decreased to match the buffer.

 If /B is missing or X (Y) is 0 the (specific) buffer dimension
 remains unchanged or is minimally increased to match the window.

 /B: X (Y) equal to -1 eliminates scrolling in that direction and
 forces precedence of the window specification.

I have a second monitor on the right. This provides an interesting demo of 18
canonical positions.

Code:
do i=1 to 9 (do j in /L 0 1280 (consize /c %i /r %j 0 & delay 1))

A new one will be in place in a couple of minutes if anyone wants to beat on it.
 
On Mon, 07 Feb 2011 14:47:36 -0500, you wrote:

|Vince:
|
|1/ One often wants a console window to be located with either the left side or the top (or both) at a negative coordinate value. The CONSIZE command does not permit this. Even if the /P option reserves negative values for special purposes, there is no reason why the /R option could not be used for the purpose. Currently you do not permit that, so even if the window had a negative coordinate before CONSIZE /R it will move it to nonnegative coordinates. To make the change fully backward compatible you could use a new option character.

The latest allows negative (and any off-the-screen) coordinates.

|2/ If moving or resizing fails, CONSIZE just reports the original information, with no failure indication. IMHO it would be useful if a failed CONSIZE operation would return a failure indication WITHOUT the full information display. This could be made an option thus making it wholly backward compatible.

If I actually checked GetLastError() after SetConsoleWindowInfo() and
SetConsoleScreenBufferSize() about all I could get is "Invalid parameter" or
something else equally uninformative. If you get the /Q(uery) message when you
expected CONSIZE to do something, it's because CONSIZE anticipated failure (and
didn't even attempt anything). The /Q(uery) message is a reminder of what's
reasonable to ask for.
 
---- Original Message ----
From: vefatica
To: [email protected]
Sent: Tuesday, 2011. March 15. 16:58
Subject: RE: [Plugins-t-2586] 4CONSOLE.DLL

| On Mon, 07 Feb 2011 14:47:36 -0500, you wrote:
|
|| Vince:
||
|| 1/ One often wants a console window to be located with either the
|| left side or the top (or both) at a negative coordinate value. The
|| CONSIZE command does not permit this. Even if the /P option reserves
|| negative values for special purposes, there is no reason why the /R
|| option could not be used for the purpose. Currently you do not
|| permit that, so even if the window had a negative coordinate before
|| CONSIZE /R it will move it to nonnegative coordinates. To make the
|| change fully backward compatible you could use a new option
|| character.
|
| The latest allows negative (and any off-the-screen) coordinates.

Thanks!

|
|| 2/ If moving or resizing fails, CONSIZE just reports the original
|| information, with no failure indication. IMHO it would be useful if
|| a failed CONSIZE operation would return a failure indication WITHOUT
|| the full information display. This could be made an option thus
|| making it wholly backward compatible.
|
| If I actually checked GetLastError() after SetConsoleWindowInfo() and
| SetConsoleScreenBufferSize() about all I could get is "Invalid
| parameter" or something else equally uninformative. If you get the /Q(uery) message
| when you expected CONSIZE to do something, it's because CONSIZE anticipated
| failure (and didn't even attempt anything). The /Q(uery) message is a reminder of
| what's reasonable to ask for.



When CONSIZE is used interactively, the results are immediately visible, so a verbose report of "no action" is superfluous. If it is used in a batch program, the result is screen pollution (unless I redirect STDERR). Considering these, I think the /Q(uery) message should be reserved to those occasions when explicitly requested. Or at least, an equivalent of the /Ne (no error report) option of many TCC commands should be available. In a batch environment one could test whether or not the changes requested by the CONSIZE command were made by checking the screen coordinates or the window and buffer sizes, using the internal variables of CONSIZE.DLL, though an explicit setting of _? would be useful. BTW, it is typically irrelevant WHY the command failed, or how your code determined that the request is invalid (i.e., whether or not it attempted to perform SetConsoleWindowInfo()), only success vs. failure is of interest.
--
Steve
 
On Tue, 15 Mar 2011 19:18:13 -0400, you wrote:

|| If I actually checked GetLastError() after SetConsoleWindowInfo() and
|| SetConsoleScreenBufferSize() about all I could get is "Invalid
|| parameter" or something else equally uninformative. If you get the /Q(uery) message
|| when you expected CONSIZE to do something, it's because CONSIZE anticipated
|| failure (and didn't even attempt anything). The /Q(uery) message is a reminder of
|| what's reasonable to ask for.
|
|
|
|When CONSIZE is used interactively, the results are immediately visible, so a verbose report of "no action" is superfluous. If it is used in a batch program, the result is screen pollution (unless I redirect STDERR). Considering these, I think the /Q(uery) message should be reserved to those occasions when explicitly requested. Or at least, an equivalent of the /Ne (no error report) option of many TCC commands should be available. In a batch environment one could test whether or not the changes requested by the CONSIZE command were made by checking the screen coordinates or the window and buffer sizes, using the internal variables of CONSIZE.DLL, though an explicit setting of _? would be useful. BTW, it is typically irrelevant WHY the command failed, or how your code determined that the request is invalid (i.e., whether or not it attempted to perform SetConsoleWindowInfo()), only success vs. failure is of interest.

The only condition for seeing the /Q(uery) info is

Code:
( srNewWin.Right >= cdMaxCon.X || srNewWin.Bottom >= cdMaxCon.Y )

CONSIZE uses a dummy srNewWin when you actually use "/Q". I'll change it so you
only get the info if you ask for it. Would you prefer no error message when you
ask for a window too big? I could just set _? to something other than 0.
 
I just uploaded new ones. You only get the info screen if you ask for it. If
SetConsoleWindowInfo(), SetConsoleScreenBufferSize(), or MoveWindow() fails,
CONSIZE aborts, you get (stderr) a "TCC: (Sys)" error message based on
GetLastError(), and CONSIZE returns 1. CONSIZE no longer checks for an OOB
request; such will result in the behavior mentioned above. On bad syntax, it
returns 2. Otherwise it returns 0.

(Maximally) CONSIZE has to (consecutively) resize the window and the buffer (in
some order) in the horizontal direction, do the same in the vertical direction,
then move the window. On failure, already accomplished changes won't be undone.
It has always been that way.
 
I again uploaded new ones. I also removed CONSIZE's restriction about being run
with redirected stdout. This required a change from
GetStdHandle(STD_OUTPUT_HANDLE) (which can be redirected) to
CreateFile(L"CONOUT$") (which always gives the console). I also made the same
change in many other places in the 4CONSOLE plugin.
 

Similar threads

Back
Top