WINDOW_BUFFER_SIZE_EVENT generated during window scrolling #415

@DHowett-MSFT commented on GitHub (Nov 21, 2018):

@oising The answer to that depends on how you're reading the console. I think that ENABLE_VIRTUAL_TERMINAL_INPUT | ENABLE_WINDOW_INPUT requires you to ReadConsoleInput. You'll get different types of INPUT_RECORD: key events containing the VT data, and window events containing the window data. You'll also be able to learn about focus events, mouse events and menu events.

@DHowett-MSFT commented on GitHub (Nov 21, 2018): @oising The answer to that depends on how you're reading the console. I think that `ENABLE_VIRTUAL_TERMINAL_INPUT | ENABLE_WINDOW_INPUT` requires you to [`ReadConsoleInput`](https://docs.microsoft.com/en-us/windows/console/readconsoleinput). You'll get different types of [`INPUT_RECORD`](https://docs.microsoft.com/en-us/windows/console/input-record-str): key events containing the VT data, and window events containing the window data. You'll also be able to learn about focus events, mouse events and menu events.

claunia commented

@oising commented on GitHub (Nov 21, 2018):

@DHowett-MSFT -- that's exactly what I'm doing, except I'm not seeing any events in the buffer. I'm testing by resizing the console window (dragging the corner) and also by adjusting from the control box (top left). Nothing in the input buffer.

@oising commented on GitHub (Nov 21, 2018): @DHowett-MSFT -- that's exactly what I'm doing, except I'm not seeing any events in the buffer. I'm testing by resizing the console window (dragging the corner) and also by adjusting from the control box (top left). Nothing in the input buffer.

claunia commented

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

Do you have a minimal repro sample code I could debug? What @DHowett-MSFT describes is how WSL does it, so I'm 99% sure that should be working for you.

@zadjii-msft commented on GitHub (Nov 26, 2018): Do you have a minimal repro sample code I could debug? What @DHowett-MSFT describes is how WSL does it, so I'm 99% sure that should be working for you.

claunia commented

@oising commented on GitHub (Nov 26, 2018):

@zadjii-msft I think the problem is that I had never really taken a good look at WINDOW_BUFFER_SIZE_EVENT before. I was expecting it to be emitted any time the console window was resized. It's only emitted when the console window is sized beyond the current buffer. It's never emitted when the window size is reduced (as the buffer won't shrink to match.) What I really wanted is a way to reliably monitor the viewport not the buffer.

@oising commented on GitHub (Nov 26, 2018): @zadjii-msft I think the problem is that I had never really taken a good look at `WINDOW_BUFFER_SIZE_EVENT` before. I was expecting it to be emitted any time the console window was resized. It's only emitted when the console window is sized beyond the current buffer. It's never emitted when the window size is reduced (as the buffer won't shrink to match.) What I really wanted is a way to reliably monitor the _viewport_ not the buffer.

claunia commented

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

@oising Yea, that's what I would have expected as well, but apparently whoever wrote that API originally hadn't considered that.

@zadjii-msft commented on GitHub (Nov 26, 2018): @oising Yea, that's what I would have expected as well, but apparently whoever wrote that API originally hadn't considered that.

claunia commented

@zadjii-msft commented on GitHub (Mar 7, 2019):

So for the record, sometime between RS2 and RS5, we changed the behavior of the console with respect to WINDOW_BUFFER_SIZE_EVENTs. We made the console send the events anytime the viewport size changed, not only the buffer size. However, we didn't change the actual values of the message, it still had the buffer size as the payload, not the viewport size. A client app can now use that message as a notification that the window might have changed size, and they could query the actual window size using GetConsoleScreenBufferInfo.

We haven't added more messages yet, nor have we changed the content of any messages, only increased the frequency of the messages.

I believe there were earlier builds where this change was scoped only to apps using VT input, but IIRC we changed it later to just send the events for all viewport changes regardless. This was probably a year ago, so I'm definitely hazy on the specifics.

@zadjii-msft commented on GitHub (Mar 7, 2019): So for the record, sometime between RS2 and RS5, we changed the behavior of the console with respect to WINDOW_BUFFER_SIZE_EVENTs. We made the console send the events anytime the viewport size changed, not only the buffer size. However, we didn't change the actual values of the message, it still had the buffer size as the payload, not the viewport size. A client app can now use that message as a notification that the window might have changed size, and they could query the actual window size using GetConsoleScreenBufferInfo. We haven't added more messages yet, nor have we changed the content of any messages, only increased the frequency of the messages. I believe there were earlier builds where this change was scoped only to apps using VT input, but IIRC we changed it later to just send the events for all viewport changes regardless. This was probably a year ago, so I'm definitely hazy on the specifics.

claunia commented

@oising commented on GitHub (Mar 7, 2019):

Thanks @zadjii-msft for the update. I'd still rather see a new event WINDOWS_VIEWPORT_SIZE_EVENT introduced rather than overload the buffer one, but I understand to ship is to choose. This will unblock a lot of people, but it would be nice to formalize it before it becomes a backcompat issue.

@oising commented on GitHub (Mar 7, 2019): Thanks @zadjii-msft for the update. I'd still rather see a new event `WINDOWS_VIEWPORT_SIZE_EVENT` introduced rather than overload the buffer one, but I understand to ship is to choose. This will unblock a lot of people, but it would be nice to formalize it before it becomes a backcompat issue.

claunia commented

@joaobzrr commented on GitHub (Jan 18, 2020):

So how do you sync UI update due to console resize and a subsequent resize? As far as I know there's no way to ask Windows to wait or postpone resizing the console.

@joaobzrr commented on GitHub (Jan 18, 2020): So how do you sync UI update due to console resize and a subsequent resize? As far as I know there's no way to ask Windows to wait or postpone resizing the console.

claunia commented

@zadjii-msft commented on GitHub (Mar 22, 2023):

/me necros thread

I believe there were earlier builds where this change was scoped only to apps using VT input, but IIRC we changed it later to just send the events for all viewport changes regardless. This was probably a year ago, so I'm definitely hazy on the specifics.

Well, if we meant to do this, we sure didn't. This works as expected for VT input, but not for apps that didn't ask for VT input.

I can still repro the behavior from OP even on Windows 11 (circa 1.15 conhost builds), so we haven't ever accidentally fixed the bug at the root of the OP, and we surely didn't get around to adding the WINDOW_VIEWPORT_SIZE_RECORD, which we considered the Good Thing To Do.

So I don't totally lose it: sample code for reproing this
https://gist.github.com/zadjii-msft/13d2f14e2125b674fdcb92525e2bde97

@zadjii-msft commented on GitHub (Mar 22, 2023): /me _necros thread_ > I believe there were earlier builds where this change was scoped only to apps using VT input, but IIRC we changed it later to just send the events for all viewport changes regardless. This was probably a year ago, so I'm definitely hazy on the specifics. Well, if we meant to do this, we sure _didn't_. This works as expected for VT input, but not for apps that didn't ask for VT input. I can still repro the behavior from OP even on Windows 11 (circa 1.15 conhost builds), so we haven't ever accidentally fixed the bug at the root of the OP, and we _surely_ didn't get around to adding the `WINDOW_VIEWPORT_SIZE_RECORD`, which we considered the **Good Thing To Do**. <hr> So I don't totally lose it: sample code for reproing this https://gist.github.com/zadjii-msft/13d2f14e2125b674fdcb92525e2bde97

claunia commented

@awsdert commented on GitHub (Jul 17, 2023):

I just mentioned it on issue #305 but I realised the best way to trigger the SIGWINCH manually is to catch an event like WM_ERASEBKGND from the console window and poll the sizes there, here's a snippet from my code (which I also posted on issue #305):

pawttyxy _pawsig_ttysize = {0};
pawld _pawsig_catch_PAWSIG_TTYSIZE( pawsig *sig, UINT msg, WPARAM wp, LPARAM lp )
{
	pawttyxy xy = {0};
	CONSOLE_SCREEN_BUFFER_INFO csbi = {{0}};
	if ( msg == WM_ERASEBKGND )
		return 0;
	GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &csbi);
	xy.x = csbi.dwSize.X;
	xy.y = csbi.dwSize.Y;
	/* Only trigger the event if at least one of limits have changed */
	if ( xy.x && _pawsig_ttysize.x && xy.y == _pawsig_ttysize.y )
		return 0;
	sig->signal = PAWSIG_TTYSIZE;
	sig->extinf.size = xy;
	return 1;
}

I'm looping through the few events that I catch of the window so ignore the return statements and the library specific stuff like pawsig (making an all round solution that should run on all systems with the same binaries - excluding libpaw at mininum).

@awsdert commented on GitHub (Jul 17, 2023): I just mentioned it on issue #305 but I realised the best way to trigger the SIGWINCH manually is to catch an event like WM_ERASEBKGND from the console window and poll the sizes there, here's a snippet from my code (which I also posted on issue #305): ``` pawttyxy _pawsig_ttysize = {0}; pawld _pawsig_catch_PAWSIG_TTYSIZE( pawsig *sig, UINT msg, WPARAM wp, LPARAM lp ) { pawttyxy xy = {0}; CONSOLE_SCREEN_BUFFER_INFO csbi = {{0}}; if ( msg == WM_ERASEBKGND ) return 0; GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &csbi); xy.x = csbi.dwSize.X; xy.y = csbi.dwSize.Y; /* Only trigger the event if at least one of limits have changed */ if ( xy.x && _pawsig_ttysize.x && xy.y == _pawsig_ttysize.y ) return 0; sig->signal = PAWSIG_TTYSIZE; sig->extinf.size = xy; return 1; } ``` I'm looping through the few events that I catch of the window so ignore the return statements and the library specific stuff like `pawsig` (making an all round solution that should run on all systems with the same binaries - excluding libpaw at mininum).

claunia commented

@determin1st commented on GitHub (Apr 22, 2024):

window buffer size.. to me, is a mixture of names by previous naming artist, SCROLL_EVENT sounds better oriented.

scroll event happens only with the terminal that has a scrollback buffer, which is defined by 4 parameters - columns, rows, left-offset, top-offset. terminal that is switched in alternate-screen-thing doesnt have a scroll so the scroll always equals to the screen size (aka equals to zero) and is not generated

a change of any of the above parameters made by the user or by sending certain ESC sequences cause the scroll event. the scroll is not related to SIGWINCH that nix terminals have

resize event or window size event or screen size event is a separate event, it may occur with the scroll or alone. it is similar to SIGWINCH

*fix: resize event absorbs (includes) scroll event, resize > scroll, so only one shall be generated

@determin1st commented on GitHub (Apr 22, 2024): window buffer size.. to me, is a mixture of names by previous naming artist, SCROLL_EVENT sounds better oriented. scroll event happens only with the terminal that has a scrollback buffer, which is defined by 4 parameters - `columns`, `rows`, `left-offset`, `top-offset`. terminal that is switched in `alternate-screen-thing` doesnt have a scroll so the scroll always equals to the screen size (aka equals to zero) and is not generated a change of any of the above parameters made by the user or by sending certain ESC sequences cause the scroll event. the scroll is not related to SIGWINCH that nix terminals have resize event or window size event or screen size event is a separate event, it may occur with the scroll or alone. it is similar to SIGWINCH *fix: resize event absorbs (includes) scroll event, resize > scroll, so only one shall be generated

claunia commented

@determin1st commented on GitHub (Apr 22, 2024):

@awsdert those msg == WM_ERASEBKGND would NOT execute down below, seem like a CPU=100% loop.. im not in a window manipulation for now, better shall have described the subscription mechanism. a polling could be implemented without this window magic

@determin1st commented on GitHub (Apr 22, 2024): @awsdert those `msg == WM_ERASEBKGND` would NOT execute down below, seem like a CPU=100% loop.. im not in a window manipulation for now, better shall have described the subscription mechanism. a polling could be implemented without this window magic

claunia commented