colortool.exe shrinks window size by one column - every time it is called

[Gavin-Holt]

Hi

I am running colortool.exe in cmd.exe (Microsoft Windows [Version 6.3.9600] Win 8.1 64bit OS) and every time I run it the Window Size reduces by one column (the rows and the Sceen Buffer Size stay the same).

Is this an "off by one" error?

It is important to me as I would like to call colortool from Textadept-curses.exe; once at load and once at quit.

Please accept apologies if this is a known bug.

Kind Regards Gavin

[zadjii-msft]

I'm so glad someone else finally reported this. I've seen this intermittently with colortool in the past, but never consistently enough to be able to file a real report on it. This helps me feel like I'm not going crazy.

We definitely shouldn't be shrinking by one char each call. Could you share a screenshot of the "options" tab of your console window's Properties dialog? It should look something like this:

Thanks!

[j4james]

I can reproduce this consistently now. You need to disable the Wrap text output on resize option, and then run colortool without the -x option, i.e. just something like colortool campbell.ini.

[Gavin-Holt]

Hi

As requested some screen shots for windows 8.1 and windows 10. Please note I am running ColorTool in the standard terminals not the "new" one.

Kind Regards Gavin

Settings

Before running the loop

After running the loop

[j4james]

This is really weird. It seems that the GetConsoleScreenBufferInfoEx API uses a different coordinate system to the SetConsoleScreenBufferInfoEx API. So if you take the output from the former, and pass it directly back to the latter, it'll shrink both the width and height of the viewport by one character. I couldn't see this documented anywhere, but it seems to work that way in the legacy console too - haven't tried on older versions of Windows.

The reason you don't see the height shrinking in the colortool is because it already compensates for that (see here). And for most people, the Wrap text output on resize option would be enabled, in which case the viewport width wouldn't have any effect (it's tied to the buffer width).

The bottom line is this can easily be fixed by incrementing the Right offset the same way we're incrementing the Bottom offset. But it would be nice to have some confirmation that that is expected behaviour, and not actually a bug in the API that needs to be fixed.

[Gavin-Holt]

Hi

I am not expert, but the height only appears to be changing because of the scroll bar at the bottom.

Running the loop twice still leaves the Window size height at 24. Resetting and reducing the Windows size width to one less than the screen buffer width displays the h scroll bar, and then running the loop makes no change to the Window size height.

Kind Regards Gavin

PS The "loop" for testing at the command prompt

FOR %f IN (campbell-legacy.ini,campbell.ini,deuteranopia.itermcolors,OneHalfDark.itermcolors,OneHalfLight.itermcolors,solarized_dark.itermcolors,solarized_light.itermcolors,cmd-legacy-night.ini,cmd-legacy.ini) DO colorTool.exe -q %f

[j4james]

Running the loop twice still leaves the Window size height at 24.

Yes, that's to be expected. What I was saying was that the ColorTool utility specifically compensates for the height being off by 1, which is why it isn't affected. We would just need to do the same thing for the width to fix this.

[jantari]

I've also worked with the SetConsoleScreenBufferInfoEx API and can confirm this happens outside of colortool even on very simple calls.

Examples from an affected project of mine are here: https://github.com/jantari/poshwal/blob/master/poshwal.ps1#L820 and here: https://github.com/jantari/poshwal/blob/master/cpp_consoleattacher.cpp#L47