2019-05-03 00:29:04 +02:00
|
|
|
/*++
|
|
|
|
|
|
|
|
Copyright (c) Microsoft Corporation.
|
|
|
|
Licensed under the MIT license.
|
|
|
|
|
|
|
|
Module Name:
|
|
|
|
- CommonState.hpp
|
|
|
|
|
|
|
|
Abstract:
|
|
|
|
- This represents common boilerplate state setup required for unit tests to run
|
|
|
|
|
|
|
|
Author(s):
|
|
|
|
- Michael Niksa (miniksa) 18-Jun-2014
|
|
|
|
- Paul Campbell (paulcam) 18-Jun-2014
|
|
|
|
|
|
|
|
Revision History:
|
2020-02-10 21:40:01 +01:00
|
|
|
- Transformed to header-only class so it can be included by multiple
|
2019-05-03 00:29:04 +02:00
|
|
|
unit testing projects in the codebase without a bunch of overhead.
|
|
|
|
--*/
|
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
|
|
|
#define VERIFY_SUCCESS_NTSTATUS(x) VERIFY_IS_TRUE(NT_SUCCESS(x))
|
|
|
|
|
|
|
|
#include "../host/globals.h"
|
|
|
|
#include "../host/inputReadHandleData.h"
|
|
|
|
#include "../buffer/out/CharRow.hpp"
|
|
|
|
#include "../interactivity/inc/ServiceLocator.hpp"
|
|
|
|
|
|
|
|
class CommonState
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
static const SHORT s_csWindowWidth = 80;
|
|
|
|
static const SHORT s_csWindowHeight = 80;
|
|
|
|
static const SHORT s_csBufferWidth = 80;
|
|
|
|
static const SHORT s_csBufferHeight = 300;
|
|
|
|
|
|
|
|
CommonState() :
|
|
|
|
m_heap(GetProcessHeap()),
|
Create tests that roundtrip output through a conpty to a Terminal (#4213)
## Summary of the Pull Request
This PR adds two tests:
* First, I started by writing a test where I could write output to the console host and inspect what output came out of conpty. This is the `ConptyOutputTests` in the host unit tests.
* Then I got crazy and thought _"what if I could take that output and dump it straight into the `Terminal`"_? Hence, the `ConptyRoundtripTests` were born, into the TerminalCore unit tests.
## References
Done in pursuit of #4200, but I felt this warranted it's own atomic PR
## PR Checklist
* [x] Doesn't close anything on it's own.
* [x] I work here
* [x] you better believe this adds tests
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
From the comment in `ConptyRoundtripTests`:
> This test class creates an in-proc conpty host as well as a Terminal, to
> validate that strings written to the conpty create the same resopnse on the
> terminal end. Tests can be written that validate both the contents of the
> host buffer as well as the terminal buffer. Everytime that
> `renderer.PaintFrame()` is called, the tests will validate the expected
> output, and then flush the output of the VtEngine straight to th
Also, some other bits had to be updated:
* The renderer needed to be able to survive without a thread, so I hadded a simple check that it actually had a thread before calling `pThread->NotifyPaint`
* Bits in `CommonState` used `NTSTATUS_FROM_HRESULT` which did _not_ work outside the host project. Since the `NTSTATUS` didn't seem that important, I replaced that with a `HRESULT`
* `CommonState` likes to initialize the console to some _weird_ defaults. I added an optional param to let us just use the defaults.
2020-01-17 17:40:12 +01:00
|
|
|
m_hrTextBufferInfo(E_FAIL),
|
2019-05-03 00:29:04 +02:00
|
|
|
m_pFontInfo(nullptr),
|
|
|
|
m_backupTextBufferInfo(),
|
|
|
|
m_readHandle(nullptr)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
~CommonState()
|
|
|
|
{
|
|
|
|
m_heap = nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
void InitEvents()
|
|
|
|
{
|
2019-05-30 20:14:21 +02:00
|
|
|
Microsoft::Console::Interactivity::ServiceLocator::LocateGlobals().hInputEvent.create(wil::EventOptions::ManualReset);
|
2019-05-03 00:29:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void PrepareReadHandle()
|
|
|
|
{
|
|
|
|
m_readHandle = std::make_unique<INPUT_READ_HANDLE_DATA>();
|
|
|
|
}
|
|
|
|
|
|
|
|
void CleanupReadHandle()
|
|
|
|
{
|
|
|
|
m_readHandle.reset(nullptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
void PrepareGlobalFont()
|
|
|
|
{
|
|
|
|
COORD coordFontSize;
|
|
|
|
coordFontSize.X = 8;
|
|
|
|
coordFontSize.Y = 12;
|
|
|
|
m_pFontInfo = new FontInfo(L"Consolas", 0, 0, coordFontSize, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
void CleanupGlobalFont()
|
|
|
|
{
|
|
|
|
if (m_pFontInfo != nullptr)
|
|
|
|
{
|
|
|
|
delete m_pFontInfo;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-01-29 17:33:06 +01:00
|
|
|
void PrepareGlobalScreenBuffer(const short viewWidth = s_csWindowWidth,
|
|
|
|
const short viewHeight = s_csWindowHeight,
|
|
|
|
const short bufferWidth = s_csBufferWidth,
|
|
|
|
const short bufferHeight = s_csBufferHeight)
|
2019-05-03 00:29:04 +02:00
|
|
|
{
|
2019-05-30 20:14:21 +02:00
|
|
|
CONSOLE_INFORMATION& gci = Microsoft::Console::Interactivity::ServiceLocator::LocateGlobals().getConsoleInformation();
|
2019-05-03 00:29:04 +02:00
|
|
|
COORD coordWindowSize;
|
2020-01-29 17:33:06 +01:00
|
|
|
coordWindowSize.X = viewWidth;
|
|
|
|
coordWindowSize.Y = viewHeight;
|
2019-05-03 00:29:04 +02:00
|
|
|
|
|
|
|
COORD coordScreenBufferSize;
|
2020-01-29 17:33:06 +01:00
|
|
|
coordScreenBufferSize.X = bufferWidth;
|
|
|
|
coordScreenBufferSize.Y = bufferHeight;
|
2019-05-03 00:29:04 +02:00
|
|
|
|
|
|
|
UINT uiCursorSize = 12;
|
|
|
|
|
|
|
|
THROW_IF_FAILED(SCREEN_INFORMATION::CreateInstance(coordWindowSize,
|
|
|
|
*m_pFontInfo,
|
|
|
|
coordScreenBufferSize,
|
Improve conpty rendering of default colors in legacy apps (#6698)
Essentially what this does is map the default legacy foreground and
background attributes (typically white on black) to the `IsDefault`
color type in the `TextColor` class. As a result, we can now initialize
the buffer for "legacy" shells (like PowerShell and cmd.exe) with
default colors, instead of white on black. This fixes the startup
rendering in conpty clients, which expect an initial default background
color. It also makes these colors update appropriately when the default
palette values change.
One complication in getting this to work, is that the console permits
users to change which color indices are designated as defaults, so we
can't assume they'll always be white on black. This means that the
legacy-to-`TextAttribute` conversion will need access to those default
values.
Unfortunately the defaults are stored in the conhost `Settings` class
(the `_wFillAttribute` field), which isn't easily accessible to all the
code that needs to construct a `TextAttribute` from a legacy value. The
`OutputCellIterator` is particularly problematic, because some iterator
types need to generate a new `TextAttribute` on every iteration.
So after trying a couple of different approaches, I decided that the
least worst option would be to add a pair of static properties for the
legacy defaults in the `TextAttribute` class itself, then refresh those
values from the `Settings` class whenever the defaults changed (this
only happens on startup, or when the conhost _Properties_ dialog is
edited).
And once the `TextAttribute` class had access to those defaults, it was
fairly easy to adapt the constructor to handle the conversion of default
values to the `IsDefault` color type. I could also then simplify the
`TextAttribute::GetLegacyAttributes` method which does the reverse
mapping, and which previously required the default values to be passed
in as a parameter
VALIDATION
I had to make one small change to the `TestRoundtripExhaustive` unit
test which assumed that all legacy attributes would convert to legacy
color types, which is no longer the case, but otherwise all the existing
tests passed as is. I added a new unit test verifying that the default
legacy attributes correctly mapped to default color types, and the
default color types were mapped back to the correct legacy attributes.
I've manually confirmed that this fixed the issue raised in #5952,
namely that the conhost screen is cleared with the correct default
colors, and also that it is correctly refreshed when changing the
palette from the properties dialog. And I've combined this PR with
#6506, and confirmed that the PowerShell and the cmd shell renderings in
Windows Terminal are at least improved, if not always perfect.
This is a prerequisite for PR #6506
Closes #5952
2020-07-01 20:08:30 +02:00
|
|
|
TextAttribute{},
|
2019-05-03 00:29:04 +02:00
|
|
|
TextAttribute{ FOREGROUND_BLUE | FOREGROUND_INTENSITY | BACKGROUND_RED },
|
|
|
|
uiCursorSize,
|
|
|
|
&gci.pCurrentScreenBuffer));
|
|
|
|
}
|
|
|
|
|
|
|
|
void CleanupGlobalScreenBuffer()
|
|
|
|
{
|
2019-05-30 20:14:21 +02:00
|
|
|
const CONSOLE_INFORMATION& gci = Microsoft::Console::Interactivity::ServiceLocator::LocateGlobals().getConsoleInformation();
|
2019-05-03 00:29:04 +02:00
|
|
|
delete gci.pCurrentScreenBuffer;
|
|
|
|
}
|
|
|
|
|
|
|
|
void PrepareGlobalInputBuffer()
|
|
|
|
{
|
2019-05-30 20:14:21 +02:00
|
|
|
CONSOLE_INFORMATION& gci = Microsoft::Console::Interactivity::ServiceLocator::LocateGlobals().getConsoleInformation();
|
2019-05-03 00:29:04 +02:00
|
|
|
gci.pInputBuffer = new InputBuffer();
|
|
|
|
}
|
|
|
|
|
|
|
|
void CleanupGlobalInputBuffer()
|
|
|
|
{
|
2019-05-30 20:14:21 +02:00
|
|
|
const CONSOLE_INFORMATION& gci = Microsoft::Console::Interactivity::ServiceLocator::LocateGlobals().getConsoleInformation();
|
2019-05-03 00:29:04 +02:00
|
|
|
delete gci.pInputBuffer;
|
|
|
|
}
|
|
|
|
|
Hide the commandline on a resize to prevent a crash when snapping the window (#5620)
Hide any commandline (cooked read) we have before we begin a resize, and
show it again after the resize.
## References
* I found #5618 while I was working on this.
## PR Checklist
* [x] Closes #1856
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
Basically, during a resize, we try to restore the viewport position
correctly, and part of that checks where the current commandline ends.
However, when we do that, the commandline's _current_ state still
reflects the _old_ buffer size, so resizing to be smaller can cause us
to throw an exception, when we find that the commandline doesn't fit in
the new viewport cleanly.
By hiding it, then redrawing it, we avoid this problem entirely. We
don't need to perform the check on the old commandline contents (since
they'll be empty), and we'll redraw it just fine for the new buffer size
## Validation Steps Performed
* ran tests
* checked resizing, snapping in conhost with a cooked read
* checked resizing, snapping in the Terminal with a cooked read
2020-04-30 01:47:56 +02:00
|
|
|
void PrepareCookedReadData(const std::string_view initialData = {})
|
2019-05-03 00:29:04 +02:00
|
|
|
{
|
2019-05-30 20:14:21 +02:00
|
|
|
CONSOLE_INFORMATION& gci = Microsoft::Console::Interactivity::ServiceLocator::LocateGlobals().getConsoleInformation();
|
2019-05-03 00:29:04 +02:00
|
|
|
auto* readData = new COOKED_READ_DATA(gci.pInputBuffer,
|
|
|
|
m_readHandle.get(),
|
|
|
|
gci.GetActiveOutputBuffer(),
|
|
|
|
0,
|
|
|
|
nullptr,
|
|
|
|
0,
|
|
|
|
L"",
|
2021-07-22 15:39:34 +02:00
|
|
|
initialData,
|
|
|
|
nullptr);
|
2019-05-03 00:29:04 +02:00
|
|
|
gci.SetCookedReadData(readData);
|
|
|
|
}
|
|
|
|
|
|
|
|
void CleanupCookedReadData()
|
|
|
|
{
|
2019-05-30 20:14:21 +02:00
|
|
|
CONSOLE_INFORMATION& gci = Microsoft::Console::Interactivity::ServiceLocator::LocateGlobals().getConsoleInformation();
|
2019-05-03 00:29:04 +02:00
|
|
|
delete &gci.CookedReadData();
|
|
|
|
gci.SetCookedReadData(nullptr);
|
|
|
|
}
|
|
|
|
|
2020-01-29 17:33:06 +01:00
|
|
|
void PrepareNewTextBufferInfo(const bool useDefaultAttributes = false,
|
|
|
|
const short bufferWidth = s_csBufferWidth,
|
|
|
|
const short bufferHeight = s_csBufferHeight)
|
2019-05-03 00:29:04 +02:00
|
|
|
{
|
2019-05-30 20:14:21 +02:00
|
|
|
CONSOLE_INFORMATION& gci = Microsoft::Console::Interactivity::ServiceLocator::LocateGlobals().getConsoleInformation();
|
2019-05-03 00:29:04 +02:00
|
|
|
COORD coordScreenBufferSize;
|
2020-01-29 17:33:06 +01:00
|
|
|
coordScreenBufferSize.X = bufferWidth;
|
|
|
|
coordScreenBufferSize.Y = bufferHeight;
|
2019-05-03 00:29:04 +02:00
|
|
|
|
|
|
|
UINT uiCursorSize = 12;
|
|
|
|
|
Improve conpty rendering of default colors in legacy apps (#6698)
Essentially what this does is map the default legacy foreground and
background attributes (typically white on black) to the `IsDefault`
color type in the `TextColor` class. As a result, we can now initialize
the buffer for "legacy" shells (like PowerShell and cmd.exe) with
default colors, instead of white on black. This fixes the startup
rendering in conpty clients, which expect an initial default background
color. It also makes these colors update appropriately when the default
palette values change.
One complication in getting this to work, is that the console permits
users to change which color indices are designated as defaults, so we
can't assume they'll always be white on black. This means that the
legacy-to-`TextAttribute` conversion will need access to those default
values.
Unfortunately the defaults are stored in the conhost `Settings` class
(the `_wFillAttribute` field), which isn't easily accessible to all the
code that needs to construct a `TextAttribute` from a legacy value. The
`OutputCellIterator` is particularly problematic, because some iterator
types need to generate a new `TextAttribute` on every iteration.
So after trying a couple of different approaches, I decided that the
least worst option would be to add a pair of static properties for the
legacy defaults in the `TextAttribute` class itself, then refresh those
values from the `Settings` class whenever the defaults changed (this
only happens on startup, or when the conhost _Properties_ dialog is
edited).
And once the `TextAttribute` class had access to those defaults, it was
fairly easy to adapt the constructor to handle the conversion of default
values to the `IsDefault` color type. I could also then simplify the
`TextAttribute::GetLegacyAttributes` method which does the reverse
mapping, and which previously required the default values to be passed
in as a parameter
VALIDATION
I had to make one small change to the `TestRoundtripExhaustive` unit
test which assumed that all legacy attributes would convert to legacy
color types, which is no longer the case, but otherwise all the existing
tests passed as is. I added a new unit test verifying that the default
legacy attributes correctly mapped to default color types, and the
default color types were mapped back to the correct legacy attributes.
I've manually confirmed that this fixed the issue raised in #5952,
namely that the conhost screen is cleared with the correct default
colors, and also that it is correctly refreshed when changing the
palette from the properties dialog. And I've combined this PR with
#6506, and confirmed that the PowerShell and the cmd shell renderings in
Windows Terminal are at least improved, if not always perfect.
This is a prerequisite for PR #6506
Closes #5952
2020-07-01 20:08:30 +02:00
|
|
|
auto initialAttributes = useDefaultAttributes ? TextAttribute{} :
|
Create tests that roundtrip output through a conpty to a Terminal (#4213)
## Summary of the Pull Request
This PR adds two tests:
* First, I started by writing a test where I could write output to the console host and inspect what output came out of conpty. This is the `ConptyOutputTests` in the host unit tests.
* Then I got crazy and thought _"what if I could take that output and dump it straight into the `Terminal`"_? Hence, the `ConptyRoundtripTests` were born, into the TerminalCore unit tests.
## References
Done in pursuit of #4200, but I felt this warranted it's own atomic PR
## PR Checklist
* [x] Doesn't close anything on it's own.
* [x] I work here
* [x] you better believe this adds tests
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
From the comment in `ConptyRoundtripTests`:
> This test class creates an in-proc conpty host as well as a Terminal, to
> validate that strings written to the conpty create the same resopnse on the
> terminal end. Tests can be written that validate both the contents of the
> host buffer as well as the terminal buffer. Everytime that
> `renderer.PaintFrame()` is called, the tests will validate the expected
> output, and then flush the output of the VtEngine straight to th
Also, some other bits had to be updated:
* The renderer needed to be able to survive without a thread, so I hadded a simple check that it actually had a thread before calling `pThread->NotifyPaint`
* Bits in `CommonState` used `NTSTATUS_FROM_HRESULT` which did _not_ work outside the host project. Since the `NTSTATUS` didn't seem that important, I replaced that with a `HRESULT`
* `CommonState` likes to initialize the console to some _weird_ defaults. I added an optional param to let us just use the defaults.
2020-01-17 17:40:12 +01:00
|
|
|
TextAttribute{ FOREGROUND_BLUE | FOREGROUND_GREEN | BACKGROUND_RED | BACKGROUND_INTENSITY };
|
|
|
|
|
2019-05-03 00:29:04 +02:00
|
|
|
m_backupTextBufferInfo.swap(gci.pCurrentScreenBuffer->_textBuffer);
|
|
|
|
try
|
|
|
|
{
|
|
|
|
std::unique_ptr<TextBuffer> textBuffer = std::make_unique<TextBuffer>(coordScreenBufferSize,
|
Create tests that roundtrip output through a conpty to a Terminal (#4213)
## Summary of the Pull Request
This PR adds two tests:
* First, I started by writing a test where I could write output to the console host and inspect what output came out of conpty. This is the `ConptyOutputTests` in the host unit tests.
* Then I got crazy and thought _"what if I could take that output and dump it straight into the `Terminal`"_? Hence, the `ConptyRoundtripTests` were born, into the TerminalCore unit tests.
## References
Done in pursuit of #4200, but I felt this warranted it's own atomic PR
## PR Checklist
* [x] Doesn't close anything on it's own.
* [x] I work here
* [x] you better believe this adds tests
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
From the comment in `ConptyRoundtripTests`:
> This test class creates an in-proc conpty host as well as a Terminal, to
> validate that strings written to the conpty create the same resopnse on the
> terminal end. Tests can be written that validate both the contents of the
> host buffer as well as the terminal buffer. Everytime that
> `renderer.PaintFrame()` is called, the tests will validate the expected
> output, and then flush the output of the VtEngine straight to th
Also, some other bits had to be updated:
* The renderer needed to be able to survive without a thread, so I hadded a simple check that it actually had a thread before calling `pThread->NotifyPaint`
* Bits in `CommonState` used `NTSTATUS_FROM_HRESULT` which did _not_ work outside the host project. Since the `NTSTATUS` didn't seem that important, I replaced that with a `HRESULT`
* `CommonState` likes to initialize the console to some _weird_ defaults. I added an optional param to let us just use the defaults.
2020-01-17 17:40:12 +01:00
|
|
|
initialAttributes,
|
2019-05-03 00:29:04 +02:00
|
|
|
uiCursorSize,
|
|
|
|
gci.pCurrentScreenBuffer->GetRenderTarget());
|
|
|
|
if (textBuffer.get() == nullptr)
|
|
|
|
{
|
Create tests that roundtrip output through a conpty to a Terminal (#4213)
## Summary of the Pull Request
This PR adds two tests:
* First, I started by writing a test where I could write output to the console host and inspect what output came out of conpty. This is the `ConptyOutputTests` in the host unit tests.
* Then I got crazy and thought _"what if I could take that output and dump it straight into the `Terminal`"_? Hence, the `ConptyRoundtripTests` were born, into the TerminalCore unit tests.
## References
Done in pursuit of #4200, but I felt this warranted it's own atomic PR
## PR Checklist
* [x] Doesn't close anything on it's own.
* [x] I work here
* [x] you better believe this adds tests
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
From the comment in `ConptyRoundtripTests`:
> This test class creates an in-proc conpty host as well as a Terminal, to
> validate that strings written to the conpty create the same resopnse on the
> terminal end. Tests can be written that validate both the contents of the
> host buffer as well as the terminal buffer. Everytime that
> `renderer.PaintFrame()` is called, the tests will validate the expected
> output, and then flush the output of the VtEngine straight to th
Also, some other bits had to be updated:
* The renderer needed to be able to survive without a thread, so I hadded a simple check that it actually had a thread before calling `pThread->NotifyPaint`
* Bits in `CommonState` used `NTSTATUS_FROM_HRESULT` which did _not_ work outside the host project. Since the `NTSTATUS` didn't seem that important, I replaced that with a `HRESULT`
* `CommonState` likes to initialize the console to some _weird_ defaults. I added an optional param to let us just use the defaults.
2020-01-17 17:40:12 +01:00
|
|
|
m_hrTextBufferInfo = E_OUTOFMEMORY;
|
2019-05-03 00:29:04 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
Create tests that roundtrip output through a conpty to a Terminal (#4213)
## Summary of the Pull Request
This PR adds two tests:
* First, I started by writing a test where I could write output to the console host and inspect what output came out of conpty. This is the `ConptyOutputTests` in the host unit tests.
* Then I got crazy and thought _"what if I could take that output and dump it straight into the `Terminal`"_? Hence, the `ConptyRoundtripTests` were born, into the TerminalCore unit tests.
## References
Done in pursuit of #4200, but I felt this warranted it's own atomic PR
## PR Checklist
* [x] Doesn't close anything on it's own.
* [x] I work here
* [x] you better believe this adds tests
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
From the comment in `ConptyRoundtripTests`:
> This test class creates an in-proc conpty host as well as a Terminal, to
> validate that strings written to the conpty create the same resopnse on the
> terminal end. Tests can be written that validate both the contents of the
> host buffer as well as the terminal buffer. Everytime that
> `renderer.PaintFrame()` is called, the tests will validate the expected
> output, and then flush the output of the VtEngine straight to th
Also, some other bits had to be updated:
* The renderer needed to be able to survive without a thread, so I hadded a simple check that it actually had a thread before calling `pThread->NotifyPaint`
* Bits in `CommonState` used `NTSTATUS_FROM_HRESULT` which did _not_ work outside the host project. Since the `NTSTATUS` didn't seem that important, I replaced that with a `HRESULT`
* `CommonState` likes to initialize the console to some _weird_ defaults. I added an optional param to let us just use the defaults.
2020-01-17 17:40:12 +01:00
|
|
|
m_hrTextBufferInfo = S_OK;
|
2019-05-03 00:29:04 +02:00
|
|
|
}
|
|
|
|
gci.pCurrentScreenBuffer->_textBuffer.swap(textBuffer);
|
|
|
|
}
|
|
|
|
catch (...)
|
|
|
|
{
|
Create tests that roundtrip output through a conpty to a Terminal (#4213)
## Summary of the Pull Request
This PR adds two tests:
* First, I started by writing a test where I could write output to the console host and inspect what output came out of conpty. This is the `ConptyOutputTests` in the host unit tests.
* Then I got crazy and thought _"what if I could take that output and dump it straight into the `Terminal`"_? Hence, the `ConptyRoundtripTests` were born, into the TerminalCore unit tests.
## References
Done in pursuit of #4200, but I felt this warranted it's own atomic PR
## PR Checklist
* [x] Doesn't close anything on it's own.
* [x] I work here
* [x] you better believe this adds tests
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
From the comment in `ConptyRoundtripTests`:
> This test class creates an in-proc conpty host as well as a Terminal, to
> validate that strings written to the conpty create the same resopnse on the
> terminal end. Tests can be written that validate both the contents of the
> host buffer as well as the terminal buffer. Everytime that
> `renderer.PaintFrame()` is called, the tests will validate the expected
> output, and then flush the output of the VtEngine straight to th
Also, some other bits had to be updated:
* The renderer needed to be able to survive without a thread, so I hadded a simple check that it actually had a thread before calling `pThread->NotifyPaint`
* Bits in `CommonState` used `NTSTATUS_FROM_HRESULT` which did _not_ work outside the host project. Since the `NTSTATUS` didn't seem that important, I replaced that with a `HRESULT`
* `CommonState` likes to initialize the console to some _weird_ defaults. I added an optional param to let us just use the defaults.
2020-01-17 17:40:12 +01:00
|
|
|
m_hrTextBufferInfo = wil::ResultFromCaughtException();
|
2019-05-03 00:29:04 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void CleanupNewTextBufferInfo()
|
|
|
|
{
|
2019-05-30 20:14:21 +02:00
|
|
|
CONSOLE_INFORMATION& gci = Microsoft::Console::Interactivity::ServiceLocator::LocateGlobals().getConsoleInformation();
|
2019-05-03 00:29:04 +02:00
|
|
|
VERIFY_IS_TRUE(gci.HasActiveOutputBuffer());
|
|
|
|
|
|
|
|
gci.pCurrentScreenBuffer->_textBuffer.swap(m_backupTextBufferInfo);
|
|
|
|
}
|
|
|
|
|
|
|
|
void FillTextBuffer()
|
|
|
|
{
|
2019-05-30 20:14:21 +02:00
|
|
|
CONSOLE_INFORMATION& gci = Microsoft::Console::Interactivity::ServiceLocator::LocateGlobals().getConsoleInformation();
|
2019-05-03 00:29:04 +02:00
|
|
|
// fill with some assorted text that doesn't consume the whole row
|
|
|
|
const SHORT cRowsToFill = 4;
|
|
|
|
|
|
|
|
VERIFY_IS_TRUE(gci.HasActiveOutputBuffer());
|
|
|
|
|
|
|
|
TextBuffer& textBuffer = gci.GetActiveOutputBuffer().GetTextBuffer();
|
|
|
|
|
|
|
|
for (SHORT iRow = 0; iRow < cRowsToFill; iRow++)
|
|
|
|
{
|
|
|
|
ROW& row = textBuffer.GetRowByOffset(iRow);
|
|
|
|
FillRow(&row);
|
|
|
|
}
|
|
|
|
|
|
|
|
textBuffer.GetCursor().SetYPosition(cRowsToFill);
|
|
|
|
}
|
|
|
|
|
|
|
|
void FillTextBufferBisect()
|
|
|
|
{
|
2019-05-30 20:14:21 +02:00
|
|
|
CONSOLE_INFORMATION& gci = Microsoft::Console::Interactivity::ServiceLocator::LocateGlobals().getConsoleInformation();
|
2019-05-03 00:29:04 +02:00
|
|
|
// fill with some text that fills the whole row and has bisecting double byte characters
|
|
|
|
const SHORT cRowsToFill = s_csBufferHeight;
|
|
|
|
|
|
|
|
VERIFY_IS_TRUE(gci.HasActiveOutputBuffer());
|
|
|
|
|
|
|
|
TextBuffer& textBuffer = gci.GetActiveOutputBuffer().GetTextBuffer();
|
|
|
|
|
|
|
|
for (SHORT iRow = 0; iRow < cRowsToFill; iRow++)
|
|
|
|
{
|
|
|
|
ROW& row = textBuffer.GetRowByOffset(iRow);
|
|
|
|
FillBisect(&row);
|
|
|
|
}
|
|
|
|
|
|
|
|
textBuffer.GetCursor().SetYPosition(cRowsToFill);
|
|
|
|
}
|
|
|
|
|
Create tests that roundtrip output through a conpty to a Terminal (#4213)
## Summary of the Pull Request
This PR adds two tests:
* First, I started by writing a test where I could write output to the console host and inspect what output came out of conpty. This is the `ConptyOutputTests` in the host unit tests.
* Then I got crazy and thought _"what if I could take that output and dump it straight into the `Terminal`"_? Hence, the `ConptyRoundtripTests` were born, into the TerminalCore unit tests.
## References
Done in pursuit of #4200, but I felt this warranted it's own atomic PR
## PR Checklist
* [x] Doesn't close anything on it's own.
* [x] I work here
* [x] you better believe this adds tests
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
From the comment in `ConptyRoundtripTests`:
> This test class creates an in-proc conpty host as well as a Terminal, to
> validate that strings written to the conpty create the same resopnse on the
> terminal end. Tests can be written that validate both the contents of the
> host buffer as well as the terminal buffer. Everytime that
> `renderer.PaintFrame()` is called, the tests will validate the expected
> output, and then flush the output of the VtEngine straight to th
Also, some other bits had to be updated:
* The renderer needed to be able to survive without a thread, so I hadded a simple check that it actually had a thread before calling `pThread->NotifyPaint`
* Bits in `CommonState` used `NTSTATUS_FROM_HRESULT` which did _not_ work outside the host project. Since the `NTSTATUS` didn't seem that important, I replaced that with a `HRESULT`
* `CommonState` likes to initialize the console to some _weird_ defaults. I added an optional param to let us just use the defaults.
2020-01-17 17:40:12 +01:00
|
|
|
[[nodiscard]] HRESULT GetTextBufferInfoInitResult()
|
2019-05-03 00:29:04 +02:00
|
|
|
{
|
Create tests that roundtrip output through a conpty to a Terminal (#4213)
## Summary of the Pull Request
This PR adds two tests:
* First, I started by writing a test where I could write output to the console host and inspect what output came out of conpty. This is the `ConptyOutputTests` in the host unit tests.
* Then I got crazy and thought _"what if I could take that output and dump it straight into the `Terminal`"_? Hence, the `ConptyRoundtripTests` were born, into the TerminalCore unit tests.
## References
Done in pursuit of #4200, but I felt this warranted it's own atomic PR
## PR Checklist
* [x] Doesn't close anything on it's own.
* [x] I work here
* [x] you better believe this adds tests
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
From the comment in `ConptyRoundtripTests`:
> This test class creates an in-proc conpty host as well as a Terminal, to
> validate that strings written to the conpty create the same resopnse on the
> terminal end. Tests can be written that validate both the contents of the
> host buffer as well as the terminal buffer. Everytime that
> `renderer.PaintFrame()` is called, the tests will validate the expected
> output, and then flush the output of the VtEngine straight to th
Also, some other bits had to be updated:
* The renderer needed to be able to survive without a thread, so I hadded a simple check that it actually had a thread before calling `pThread->NotifyPaint`
* Bits in `CommonState` used `NTSTATUS_FROM_HRESULT` which did _not_ work outside the host project. Since the `NTSTATUS` didn't seem that important, I replaced that with a `HRESULT`
* `CommonState` likes to initialize the console to some _weird_ defaults. I added an optional param to let us just use the defaults.
2020-01-17 17:40:12 +01:00
|
|
|
return m_hrTextBufferInfo;
|
2019-05-03 00:29:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
HANDLE m_heap;
|
Create tests that roundtrip output through a conpty to a Terminal (#4213)
## Summary of the Pull Request
This PR adds two tests:
* First, I started by writing a test where I could write output to the console host and inspect what output came out of conpty. This is the `ConptyOutputTests` in the host unit tests.
* Then I got crazy and thought _"what if I could take that output and dump it straight into the `Terminal`"_? Hence, the `ConptyRoundtripTests` were born, into the TerminalCore unit tests.
## References
Done in pursuit of #4200, but I felt this warranted it's own atomic PR
## PR Checklist
* [x] Doesn't close anything on it's own.
* [x] I work here
* [x] you better believe this adds tests
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
From the comment in `ConptyRoundtripTests`:
> This test class creates an in-proc conpty host as well as a Terminal, to
> validate that strings written to the conpty create the same resopnse on the
> terminal end. Tests can be written that validate both the contents of the
> host buffer as well as the terminal buffer. Everytime that
> `renderer.PaintFrame()` is called, the tests will validate the expected
> output, and then flush the output of the VtEngine straight to th
Also, some other bits had to be updated:
* The renderer needed to be able to survive without a thread, so I hadded a simple check that it actually had a thread before calling `pThread->NotifyPaint`
* Bits in `CommonState` used `NTSTATUS_FROM_HRESULT` which did _not_ work outside the host project. Since the `NTSTATUS` didn't seem that important, I replaced that with a `HRESULT`
* `CommonState` likes to initialize the console to some _weird_ defaults. I added an optional param to let us just use the defaults.
2020-01-17 17:40:12 +01:00
|
|
|
HRESULT m_hrTextBufferInfo;
|
2019-05-03 00:29:04 +02:00
|
|
|
FontInfo* m_pFontInfo;
|
|
|
|
std::unique_ptr<TextBuffer> m_backupTextBufferInfo;
|
|
|
|
std::unique_ptr<INPUT_READ_HANDLE_DATA> m_readHandle;
|
|
|
|
|
|
|
|
void FillRow(ROW* pRow)
|
|
|
|
{
|
|
|
|
// fill a row
|
|
|
|
// 9 characters, 6 spaces. 15 total
|
|
|
|
// か = \x304b
|
|
|
|
// き = \x304d
|
2019-06-11 22:27:09 +02:00
|
|
|
const PCWSTR pwszText = L"AB"
|
|
|
|
L"\x304b\x304b"
|
|
|
|
L"C"
|
|
|
|
L"\x304d\x304d"
|
|
|
|
L"DE ";
|
2019-05-03 00:29:04 +02:00
|
|
|
const size_t length = wcslen(pwszText);
|
|
|
|
|
|
|
|
std::vector<DbcsAttribute> attrs(length, DbcsAttribute());
|
|
|
|
// set double-byte/double-width attributes
|
|
|
|
attrs[2].SetLeading();
|
|
|
|
attrs[3].SetTrailing();
|
|
|
|
attrs[5].SetLeading();
|
|
|
|
attrs[6].SetTrailing();
|
|
|
|
|
|
|
|
CharRow& charRow = pRow->GetCharRow();
|
|
|
|
OverwriteColumns(pwszText, pwszText + length, attrs.cbegin(), charRow.begin());
|
|
|
|
|
|
|
|
// set some colors
|
|
|
|
TextAttribute Attr = TextAttribute(0);
|
|
|
|
pRow->GetAttrRow().Reset(Attr);
|
|
|
|
// A = bright red on dark gray
|
|
|
|
// This string starts at index 0
|
|
|
|
Attr = TextAttribute(FOREGROUND_RED | FOREGROUND_INTENSITY | BACKGROUND_INTENSITY);
|
|
|
|
pRow->GetAttrRow().SetAttrToEnd(0, Attr);
|
|
|
|
|
|
|
|
// BかC = dark gold on bright blue
|
|
|
|
// This string starts at index 1
|
|
|
|
Attr = TextAttribute(FOREGROUND_RED | FOREGROUND_GREEN | BACKGROUND_BLUE | BACKGROUND_INTENSITY);
|
|
|
|
pRow->GetAttrRow().SetAttrToEnd(1, Attr);
|
|
|
|
|
|
|
|
// き = bright white on dark purple
|
|
|
|
// This string starts at index 5
|
|
|
|
Attr = TextAttribute(FOREGROUND_RED | FOREGROUND_GREEN | FOREGROUND_BLUE | FOREGROUND_INTENSITY | BACKGROUND_RED | BACKGROUND_BLUE);
|
|
|
|
pRow->GetAttrRow().SetAttrToEnd(5, Attr);
|
|
|
|
|
|
|
|
// DE = black on dark green
|
|
|
|
// This string starts at index 7
|
|
|
|
Attr = TextAttribute(BACKGROUND_GREEN);
|
|
|
|
pRow->GetAttrRow().SetAttrToEnd(7, Attr);
|
|
|
|
|
|
|
|
// odd rows forced a wrap
|
|
|
|
if (pRow->GetId() % 2 != 0)
|
|
|
|
{
|
2021-01-20 22:16:56 +01:00
|
|
|
pRow->SetWrapForced(true);
|
2019-05-03 00:29:04 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2021-01-20 22:16:56 +01:00
|
|
|
pRow->SetWrapForced(false);
|
2019-05-03 00:29:04 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-06-11 22:27:09 +02:00
|
|
|
void FillBisect(ROW* pRow)
|
2019-05-03 00:29:04 +02:00
|
|
|
{
|
2019-05-30 20:14:21 +02:00
|
|
|
const CONSOLE_INFORMATION& gci = Microsoft::Console::Interactivity::ServiceLocator::LocateGlobals().getConsoleInformation();
|
2019-05-03 00:29:04 +02:00
|
|
|
// length 80 string of text with bisecting characters at the beginning and end.
|
|
|
|
// positions of き(\x304d) are at 0, 27-28, 39-40, 67-68, 79
|
2020-08-07 16:46:52 +02:00
|
|
|
auto pwszText =
|
2019-05-03 00:29:04 +02:00
|
|
|
L"\x304d"
|
|
|
|
L"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
|
|
|
|
L"\x304d\x304d"
|
|
|
|
L"0123456789"
|
|
|
|
L"\x304d\x304d"
|
|
|
|
L"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
|
|
|
|
L"\x304d\x304d"
|
|
|
|
L"0123456789"
|
|
|
|
L"\x304d";
|
|
|
|
const size_t length = wcslen(pwszText);
|
|
|
|
|
|
|
|
std::vector<DbcsAttribute> attrs(length, DbcsAttribute());
|
|
|
|
// set double-byte/double-width attributes
|
|
|
|
attrs[0].SetTrailing();
|
|
|
|
attrs[27].SetLeading();
|
|
|
|
attrs[28].SetTrailing();
|
|
|
|
attrs[39].SetLeading();
|
|
|
|
attrs[40].SetTrailing();
|
|
|
|
attrs[67].SetLeading();
|
|
|
|
attrs[68].SetTrailing();
|
|
|
|
attrs[79].SetLeading();
|
|
|
|
|
|
|
|
CharRow& charRow = pRow->GetCharRow();
|
|
|
|
OverwriteColumns(pwszText, pwszText + length, attrs.cbegin(), charRow.begin());
|
|
|
|
|
|
|
|
// everything gets default attributes
|
|
|
|
pRow->GetAttrRow().Reset(gci.GetActiveOutputBuffer().GetAttributes());
|
|
|
|
|
2021-01-20 22:16:56 +01:00
|
|
|
pRow->SetWrapForced(true);
|
2019-05-03 00:29:04 +02:00
|
|
|
}
|
|
|
|
};
|