Open Gavin-Holt opened 4 years ago
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!
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
.
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
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.
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
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.
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
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