starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

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

New Issue
Open
opened 2026-01-31 00:06:38 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 00:06:38 +00:00
Owner
Copy Link

Originally created by @Gavin-Holt on GitHub (Nov 26, 2019).

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

Originally created by @Gavin-Holt on GitHub (Nov 26, 2019). 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
claunia added the Product-ColortoolHelp WantedIssue-BugArea-Server labels 2026-01-31 00:06:38 +00:00
claunia commented 2026-01-31 00:06:39 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 26, 2019):

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:

image

Thanks!

@zadjii-msft commented on GitHub (Nov 26, 2019): 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: ![image](https://user-images.githubusercontent.com/18356694/69638975-5852ad80-1021-11ea-9bfc-749d87434dec.png) Thanks!
claunia commented 2026-01-31 00:06:39 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Nov 26, 2019):

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.

@j4james commented on GitHub (Nov 26, 2019): 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`.
claunia commented 2026-01-31 00:06:39 +00:00
Author
Owner
Copy Link

@Gavin-Holt commented on GitHub (Nov 26, 2019):

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

Settings8_1
Settings10

Before running the loop

Before8_1
Before10

After running the loop

After8_1
After10

@Gavin-Holt commented on GitHub (Nov 26, 2019): 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 ![Settings8_1](https://user-images.githubusercontent.com/5831149/69655281-24ea4000-106e-11ea-8914-19f2f3dae0f6.png) ![Settings10](https://user-images.githubusercontent.com/5831149/69655298-2a478a80-106e-11ea-9c37-9001259807fc.png) Before running the loop ![Before8_1](https://user-images.githubusercontent.com/5831149/69655308-2ddb1180-106e-11ea-9b9a-f09b7ba45313.png) ![Before10](https://user-images.githubusercontent.com/5831149/69655317-32072f00-106e-11ea-908d-a5fbbf5fac1a.png) After running the loop ![After8_1](https://user-images.githubusercontent.com/5831149/69655322-359ab600-106e-11ea-9e50-5bf795cc99e8.png) ![After10](https://user-images.githubusercontent.com/5831149/69655906-70e9b480-106f-11ea-921c-9b06d95097df.png)
claunia commented 2026-01-31 00:06:39 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Nov 26, 2019):

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.

@j4james commented on GitHub (Nov 26, 2019): 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](https://github.com/microsoft/terminal/blob/00bb050826ce15c092b915c3de24c263ce5dc031/src/tools/ColorTool/ColorTool/ConsoleTargets/CurrentConsoleTarget.cs#L26)). 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.
claunia commented 2026-01-31 00:06:40 +00:00
Author
Owner
Copy Link

@Gavin-Holt commented on GitHub (Nov 26, 2019):

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

@Gavin-Holt commented on GitHub (Nov 26, 2019): 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
claunia commented 2026-01-31 00:06:40 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Nov 26, 2019):

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.

@j4james commented on GitHub (Nov 26, 2019): > 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.
claunia commented 2026-01-31 00:06:40 +00:00
Author
Owner
Copy Link

@jantari commented on GitHub (Mar 2, 2020):

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

@jantari commented on GitHub (Mar 2, 2020): 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
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Server Help Wanted Issue-Bug Product-Colortool
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#5169
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?