## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/9787
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already.
## Validation Steps Performed
* [x] single click = no selection
* [x] single click and drag = selection starting from first point
* [x] single click in unfocused pane and drag = focus pane, selection starting from first point
* [x] double-click = selects a whole word
* [x] triple-click = selects a whole line
* [x] double-click and drag = selects a whole word, drag selects whole words
* [x] triple-click and drag = selects a whole line, drag selects whole lines
* [x] Shift single-click = defines start point
* [x] second Shift single-click = defines end point
* [x] Shift double-click = selects entire word
* [x] Shift triple-click = selects entire line
* [x] Shift double-click and drag = selects entire word, drag selects whole words
* [x] Mouse mode: Shift single-click = defines start point
* [x] Mouse mode: second Shift single-click = defines end point
* [x] Mouse mode: Shift double-click = selects entire word
* [x] Mouse mode: Shift triple-click = selects entire line
* [x] Mouse mode: Shift double-click and drag = selects entire word, drag selects whole words
* [x] With existing selection: single-click outside the selection and drag = establishes a new selection starting from the click point
* [x] Click-drag to set selection, shift-click-drag outside of selection = extend selection while dragging
This is required to maintain the modality of the dialogs, which we lost
when we moved from Pickers to IFileDialog. The HWND hosting Window API
we dreamed up is incompatible with IModalDialog, because IModalDialog
requires the HWND immediately upon `Show`. We're smuggling it in a
uint64, as is tradition.
zadjii-msft noticed this in #9760.
"ctrl+numpad_plus" command now increases font size and
"ctrl+numpad_minus" command now decreases font size.
Before this only "ctrl+=" and "ctrl+-" controlled font size. Increase in
font size follows previous convention where zooms in arbitrarily large,
but decrease in font size is capped.
## Validation Steps Performed
I first ran "ctrl+=" and "ctrl+-" in my terminal to verify its behavior,
then compared that against "ctrl+numpad_plus" and "ctrl+"numpad_minus".
Both increased and decreased the font size by the same amount, and both
appeared to have a cap for how small they could get, but did not appear
to have a cap for how big they could get.
Closes#7518
The red close button animation fades to gray then to transparent, when
standard behavior skips the gray part. I manually tested in light/dark/high
contrast mode.
Closes#9762
Using Pickers from an elevated application yields an
ERROR_ACCESS_DENIED. Of course it does: it was designed for the modern
app platform.
Using the common dialog infrastructure has some downsides¹, but it
doesn't crash and is just as flexible.
I've added some fun templated functions that help us with the
complexity.
Fixes#8957
¹You've got to use raw COM, and it runs in-proc instead of out-of-proc.
## Validation Steps Performed
I tested every picker.
It will be a different color than the background, so it will look less
weird when it's unfocused. It also fixes the bug where the navigation
menu is transparent when acrylic is disabled systemwide.
Fixes#9337
This pull request adds an appearance configuration object to our
settings model and app lib, allowing the control to be rendered
differently depending on its state, and then uses it to add support for
an "unfocused" appearance that the terminal will use when it's not in
focus.
To accomplish this, we isolated the appearance-related settings from
Profile (into AppearanceConfig) and TerminalSettings (into the
IControlAppearance and ICoreAppearance interfaces). A bunch of work was
done to make inheritance work.
The unfocused appearance inherits from the focused one _for that
profile_. This is important: If you define a
defaults.unfocusedAppearance, it will apply all of defaults' settings to
any leaf profile when a terminal in that profile is out of focus.
Specified in #8345Closes#3062Closes#2316
Reduce instances of font fallback dialog through package font loading,
basic name trimming, and revised fallback test
- Adjusts the font dialog to only show when we attempt last-chance
resolution from our hardcoded list of font names with a flag instead
of with a string comparison by name
- Adds a resolution step to trim the font name by word from the end and
retry to attempt to resolve a proper font that just has a weight
suffix
- Adds a second font collection to font loading that will attempt to
locate all TTF files sitting next to our binary, like in our package
- [x] Wrote my font preference in the JSON as `Cascadia Code Heavy` and
watched it quietly resolve to just `Cascadia Code` without the dialog.
- [x] Put a font that isn't registered with the system into the layout
directory for the package, set it as my desired font in Terminal, and
watched it load just fine.
- [x] Try a font name with different casing and see if dialog doesn't
pop anymore
- [x] Try a font with different (localized) names like ＭＳ ゴシック and
see if dialog doesn't pop anymore
- [x] Check Win7 with WPF target
Closes#9375
## Summary of the Pull Request
Make sure that the window renamer and other toasts follow the requested app theme. We accomplish this by doing something similar to what we do with ContentDialogs. Since TeachingTips aren't in the same XAML root, we have to traverse the entire tree upwards setting RequestedTheme. If we don't, then we'll update the background color of the TeachingTip, but not the text inside it.
## References
* Added in #9662 and #9523
## PR Checklist
* [x] Closes#9717
* [x] I work here
* [n/a] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
Tested with system theme light & dark, and `theme` set to `light, dark, and unset, and verified that they worked as expected.
## Summary of the Pull Request
Huh, I guess I missed making the window renamer light-dismissable. This is a oneline fix for that.
Light dismissing is treated as a _cancel_, not as a commit.
## References
* Added in #9662
## PR Checklist
* [x] Closes#9718
* [x] I work here
* [n/a] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
This feels right.
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/9725
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already.
## Validation Steps Performed
* [x] single click = no selection
* [x] single click and drag = selection starting from first point
* [x] single click in unfocused pane and drag = focus pane, selection starting from first point
* [x] double-click = selects a whole word
* [x] triple-click = selects a whole line
* [x] double-click and drag = selects a whole word, drag selects whole words
* [x] triple-click and drag = selects a whole line, drag selects whole lines
* [x] Shift single-click = defines start point
* [x] second Shift single-click = defines end point
* [x] Shift double-click = selects entire word
* [x] Shift triple-click = selects entire line
* [x] Shift double-click and drag = selects entire word, drag selects whole words
* [x] Mouse mode: Shift single-click = defines start point
* [x] Mouse mode: second Shift single-click = defines end point
* [x] Mouse mode: Shift double-click = selects entire word
* [x] Mouse mode: Shift triple-click = selects entire line
* [x] Mouse mode: Shift double-click and drag = selects entire word, drag selects whole words
* [x] With existing selection: single-click outside the selection and drag = establishes a new selection starting from the click point
## Summary of the Pull Request
In exactly the same fashion as the tab renamer, handle <kbd>Enter</kbd> for committing the rename, and <kbd>Escape</kbd> for dismissing the rename.
## References
* Added in #9662
## PR Checklist
* [x] Closes#9720
* [x] I work here
* [n/a] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
Played with it - this feels good.
## Summary of the Pull Request
ThrottledFunc previously created a DispatcherTimer whose Tick callback holds a strong reference to the DispatcherTimer itself.
This causes a reference cycle, inadvertently leaking timer instances.
## PR Checklist
* [x] Closes#7710
* [x] I work here
## Detailed Description of the Pull Request / Additional comments
I've initially wanted to remove the `ThrottledFunc<>` optimization, but it turns out that this causes a 3% slowdown. That's definitely not a lot, but enough that we can just keep the optimization for the time being.
I've moved the implementation from the .cpp file into the header regardless since the two implementations are extremely similar and it's easier that way to keep them in line.
## Validation Steps Performed
I've ensured that the scrollbar still updates its length when I add new lines to a newly created tab.
Does what it says on the can.
This is a follow up to #9472. Now that we have a control .lib, we can add tests for it.
Unfortunately, the `TermControl` itself is a horrible mess. So this new unittest lib is empty for now. I'm working on actual tests as a part of #6842, but this PR is here to keep the diffs smaller.
Also, apparently `server.vcxproj` had the wrong GUID in it.
* [x] I work here
* [x] Adds tests
## Summary of the Pull Request
This PR adds support for renaming windows.
It does so through two new actions:
* `renameWindow` takes a `name` parameter, and attempts to set the window's name
to the provided name. This is useful if you always want to hit <kbd>F3</kbd>
and rename a window to "foo" (READ: probably not that useful)
* `openWindowRenamer` is more interesting: it opens a `TeachingTip` with a
`TextBox`. When the user hits Ok, it'll request a rename for the provided
value. This lets the user pick a new name for the window at runtime.
In both cases, if there's already a window with that name, then the monarch will
reject the rename, and pop a `Toast` in the window informing the user that the
rename failed. Nifty!
## References
* Builds on the toasts from #9523
* #5000 - process model megathread
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/projects/5#card-50771747
* [x] I work here
* [x] Tests addded (and pass with the help of #9660)
* [ ] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
I'm sending this PR while finishing up the tests. I figured I'll have time to sneak them in before I get the necessary reviews.
> PAIN: We can't immediately focus the textbox in the TeachingTip. It's
> not technically focusable until it is opened. However, it doesn't
> provide an even tto tell us when it is opened. That's tracked in
> microsoft/microsoft-ui-xaml#1607. So for now, the user _needs_ to
> click on the text box manually.
> We're also not using a ContentDialog for this, because in Xaml
> Islands a text box in a ContentDialog won't recieve _any_ keypresses.
> Fun!
## Validation Steps Performed
I've been playing with
```json
{ "keys": "f1", "command": "identifyWindow" },
{ "keys": "f2", "command": "identifyWindows" },
{ "keys": "f3", "command": "openWindowRenamer" },
{ "keys": "f4", "command": { "action": "renameWindow", "name": "foo" } },
{ "keys": "f5", "command": { "action": "renameWindow", "name": "bar" } },
```
and they seem to work as expected
**Summary of the Pull Request**
This PR adds an X Macro for defining our ShortcutActions. This means that you can add the action in one place, and have the macro synthesize all sorts of boilerplate for you!
From the `AllShortcutActions.h` file:
> For a clearer explanation of how this file should be used, see:
> https://en.wikipedia.org/wiki/X_Macro
>
> Include this file to be able to quickly define some code in the exact same
> way for _every single shortcut action_. To use:
>
> 1. Include this file
> 2. Define the ON_ALL_ACTIONS macro with what you want each action to show up
> as. Ex:
>
> #define ON_ALL_ACTIONS(action) void action##Handler();
>
> 3. Then, use the ALL_SHORTCUT_ACTIONS macro to get the ON_ALL_ACTIONS marcro
> repeated once for every ShortcutAction
>
> This is used in KeyMapping.idl, ShortcutAction.*, TerminalPage.*, etc. to
> reduce the number of places where we must copy-paste boiler-plate code for
> each action. This is _NOT_ something that should be used when any individual
> case should be customized.
**PR Checklist**
* [x] Scratches an itch
* [x] I work here
* [x] Tests passed
* [n/a] Requires documentation to be updated
**Detailed Description of the Pull Request / Additional comments**
Originally I had this blocked as a follow up to #9662. However, I've grown tired after a month of merging main into this branch, and I'm just shipping it separately. It will inevitably conflict with anyone who has actions in flight currently.
**Validation Steps Performed**
The code still builds exactly as before!
Broadly, the tests were broken by #7489 because there were no `_startupActions`. They relied on the removed codepath that assumed `wt.exe` always set actions, or `AppCommandlineArgs::ValidateStartupCommands` created one by default.
* [x] fixes#9659
* [x] I work here
* [x] the tests pass again
This pull request introduces Microsoft.Terminal.Core.Color as an
alternative to both Windows.UI.Color and uint32_t/COLORREF in the
TerminalCore, ...Control, ...SettingsModel and ...SettingsEditor layers.
M.T.C.Color is trivially convertible to/from til::color and therefore
to/from COLORREF, W.U.Color, and any other color representation we might
need².
I've replaced almost every use of W.U.Color and uint32_t-as-color in the
above layers, with minor exception¹.
The need for this work is twofold.
First: We cannot bear a dependency from TerminalCore (which should,
on paper, be Windows 7 compatible) on Windows.UI or any other WinRT
namespace.
This work removes one big dependency on Windows.UI, but it does not go
all the way.
Second: TerminalCore chose to communicate mostly in packed uint32s
(COLORREF), which was inherently lossy and dangerous.
¹ The UI layers (TerminalControl, TerminalApp) still use
Windows.UI.Color as they are intimately connected to the UWP XAML UI.
² In the future, we might even be able to *use* the alpha channel...
## PR Checklist
* [x] I ran into the need for this when I introduced cursor inversion
* [X] Fixes a longstanding itch
## Validation Steps Performed
Built and ran all tests for the impacted layers, even the local ones!
## Summary of the Pull Request
This is a follow up to #9300. Now that we have names on our windows, it would be nice to see who is named what. So this adds two actions:
* `identifyWindow`: This action will pop up a little toast (#8592) displaying the name and ID of the window, and is bound by default.
* `identifyWindows`: This action will request that ALL windows pop up that toast. This is meant to feel like the "Identify" button on the Windows display settings. However, sometimes, it's wonky.
That's being tracked upstream on https://github.com/microsoft/microsoft-ui-xaml/issues/4382
Because it's so wonky, we won't bind that by default. Maybe if we get that fixed, then we'll change the default binding from `identifyWindow` to `identifyWindows`
## References
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/projects/5#card-51431492
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
You may note that there are some macros to make interacting with lots and lots of actions easier. There's a lot of boilerplate whenever you need to make a new action, so I thought: "Can we make that easier?"
Turns out you can make it a _LOT_ easier, but that work is still behind another PR after this one. Get excited
## Summary of the Pull Request
Currently, both when the tab is already closed, and when there is a
request to close a tab (might be rejected), we go through the same flow
in TerminalPage.
This might leave the system in inconsistent state, as the side-effects
of closing will persist even if the closing was aborted.
This PR separates between the two flows, by introducing a CloseRequested
event to the TabBase.
This event is used to inform the upper tier (the terminal page) about
the request and to trigger the same logic that happens when the tab is
closed directly from the terminal page (e.g., by clicking close on the
tab view).
The Closed event will be used only to handle the actual closing of the
tab. It will ensure that the tab gets removed from the terminal page if
required.
As a result, it a read-only pane will be closed non-interactively (aka
connection exits), the tab closed flow will be invoked, and no user
prompt will be shown.
## References
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/9572
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already.
Removes base layer (aka profiles.defaults) from the Settings UI. `SettingContainer` was also updated to not present a revert arrow when overriding a base layer value.
The new experience is now as follows:
- The revert arrow will only appear if you are overriding a value from a fragment extension.
- Users are still able to fully interact with `profiles.defaults` in their settings.json. Doing so still propagates those changes to their profiles as normal. In this case, the Settings UI presents the base layer value as the one that you selected.
#6800 - Settings UI Epic
Closes#9539
Change TAEF nuget package to use new Microsoft.Taef name; Update to 10.58 release build version.
## PR Checklist
* [x] Closes email from Phil letting us know TAEF has a new release build and a rename.
* [x] Closes annoying duplicate TAEF import warning in `Parser.UnitTests.vcxproj`
* [x] I work here.
* [ ] Need to see the tests run off CI to confirm this is fine for those environments and Helix
## Validation Steps Performed
* [x] Build/run tests locally
* [ ] Build/run unit and feature tests in CI
* [ ] Build/run Helix-lab tests in CI
This adds [`XamlStyler.Console`] to our solution, and calls it when we
format the code, to also format
our .xaml files.
* `XamlStyler.Console` is a dotnet tool so it needs to be restored with
`dotnet tool restore`
* I've added a set of rules to approximately follow [@cmaneu's XAML guidelines].
Those guidelines also recommend things based on the code-behind, which
this tool can't figure out, but also _don't matter that much_.
* There's an extra step to strip BOMs from the output, since Xaml Styler
adds a BOM by default. Some had them before and others didn't. BOMs
have been nothing but trouble though.
[`XamlStyler.Console`]: https://github.com/Xavalon/XamlStyler
[@cmaneu's XAML guidelines]: https://github.com/cmaneu/xaml-coding-guidelines
This is entirely self-serving. In my go-to config, I like having some of
the panes for a given profile in a different color scheme. This will let
a user pass `--colorScheme <scheme name>` to manually override the
scheme for that profile. Neat!
I think we can all agree that `TerminalPage.cpp` is an unruly beast of a
file. It's got everything. It does everything. It can sometimes be a bit
hard to work with, because of simply how big it is. This PR tries to
alleviate this by making `TerminalPage.cpp` just a little smaller. It
does so by moving pretty much everything related to tab management into
its own file, `TabManagement.cpp`. These methods that have moved are all
the same as they were before, and they're still members of
`TerminalPage`. But now they're all in one place.
I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but
there's still a few that I left behind. Mostly because I felt that
moving those would be too gnarly a code change for an otherwise simple
cut&paste PR.
There are a few new methods I introduced:
* `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before,
promoted to full methods.
* `_DismissTabContextMenus`: Remove all the right-click context menus
from the tabs
* `_FocusCurrentTab`: This one's a bit trickier, we were actually doing
this in a few different places, so I tried consolidating.
* `_HasMultipleTabs`: This doesn't need explaining.
* `_RemoveAllTabs`: Really, just encapsulation for the sake of removing
a `_tabs` from `TerminalPage.cpp`
* `_ResizeTabContent`: Really, just encapsulation for the sake of
removing a `_tabs` from `TerminalPage.cpp`
In the future, some enterprising young soul could try promoting that
file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it.
Probably would need to take a reference to TerminalPage's `_tabView` and
`_newTabButton`. I'm not doing that right now, because I already hate
the idea of the ...
> 920 additions and 847 deletions.
... I'm making you look at already.
## Other thoughts
Some of the calls might be a little arbitrary - `_OpenNewTab` and
`_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or
at least elements of those might need to get split up better. Similarly
`TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it
does a lot of the same work as `_CreateNewTabFromSettings`. I'm not
saying this is the definitive places for these methods - it's code we're
working with, not stone ☺️
We have been seeing some crashes (#9410) originating from a
use-after-free or a double-free in the renderer. The renderer is
iterating over the dirty rects from the render engine¹ and the rect list
is being freed out from under it.
Things like this are usually the result of somebody manipulating the
renderer's state outside of lock.
Therefore, this pull request introduces some targeted locking fixes
around manipulation of the pattern buffer (which, in turn, changes the
renderer state.)
¹ This was not a problem until #8621, which made the renderer return a
span instead of a copy for the list of dirty rects.
## Validation
I ran Terminal under App Verifier, and introduced a manul delay (under
lock) in the renderer such that the invalid map would definitely have
been invalidated between the renderer taking the lock and the renderer
handling the frame. AppVerif failed us without these locking changes,
and did not do so once they were introduced.
Closes#9410.
- Implements the default application behavior and handoff mechanisms
between console and terminal. The inbox portion is done already. This
adds the ability for our OpenConsole.exe to accept the incoming server
connection from the Windows OS, stand up a PTY session, start the
Windows Terminal as a listener for an incoming connection, and then
send it the incoming PTY connection for it to launch a tab.
- The tab is launched with default settings at the moment.
- You must configure the default application using the `conhost.exe`
propsheet or with the registry keys. Finishing the setting inside
Windows Terminal will be a todo after this is complete. The OS
Settings panel work to surface this setting is a dependency delivered
by another team and you will not see it here.
## Validation Steps Performed
- [x] Manual adjust of registry keys to the delegation conhost/terminal
behavior
- [x] Adjustment of the delegation options with the propsheet
- [x] Launching things from the run box manually and watching them show
in Terminal
- [x] Launching things from shortcuts and watching them show in the
Terminal
Documentation on how it works will be a TODO post completion in #9462
References #7414 - Default Terminal spec
Closes#492
The PlaySound functions were removed from OneCoreUAP_apiset.Lib in Windows 10 SDK 19041 because they did not actually belong there. Link to WinMM.Lib for PlaySoundW.
### Validation Steps Performed
* Built for x64 from repository root with: `MSBuild.exe -property:TargetPlatformVersion=10.0.19041.0`
* Installed CascadiaPackage_0.0.1.0_x64_Debug.msix and launched on 19042.867
There seems to be a bug in WinUI (see microsoft/microsoft-ui-xaml#2121)
that results in heterogeneous `ModernCollectionBasePanel` configured
with `DataTemplateSelector` and virtualization enabled to recycle a
container even if its `ContentTemplate` is wrong.
I considered few options of handling this:
* Disabling virtualization (by replacing item container template with
some non-virtualizing panel (e.g., `StackPanel`,
`VirtualizingStackPanel` with `VirtualizationMode`=`Standard`)
* Replacing `DataTemplateSelector` approach with `ChoosingItemContainer`
event handling approach, which allows you to manage the item container
(`ListViewItem`) allocation process.
I have chosen the last one, as it should limit the amount of
allocations, and might allow optimizations in the future.
The solution introduces:
* A container for `ListViewItem`s in the form of a map of sets:
* The key of this map is a data template (e.g., `TabItemDataTemplate`)
* The value in the set is the container
* `ChoosingItemContainer` event handler that looks for available item in
the container or creates a new one
* `ContainerContentChanging` event handler that returns the recycled
item to the container
Closes#9288
## Summary of the Pull Request
Currently, when the MRU is enabled we lose the keybinding allowing us to
go forward/backward (aka right/left in LTR) in the tab view.
To fix that, this PR introduces "tabSwitcherMode" optional parameter to
the prevTab / nextTab commands.
If it is not provided the global setting will be used.
So if you want to go to adjacent tabs, even if MRU is enabled on the
system level you can use:
```
{ "command": { "action": "prevTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f2"}
```
or even
```
{"command": { "action": "prevTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f2"}
```
if you don't want tab switcher to show up
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/9330
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated - not yet. Waiting for approval.
* [x] Schema updated.
* [ ] I've discussed this with core contributors already.
This commit introduces a few different announcements to the command
palette.
When you delete the `>`, it will announce that you have entered
"command-line mode". When you reintroduce the `>`, it will announce that
you are in "action search mode."
When you enter a nested command, it will announce that you are looking
at "more options for new tab..." or "more options for select color
scheme...".
When you search and find nothing, it will announce that there were no
matching commands (or tabs!)
Related to #7907.
## Summary of the Pull Request
Currently a repeated attempt to close a read-only tab from context menu,
will bring the terminal into invalid state if user dismisses close action.
There are two root causes for this:
1. The tab close menu triggers the closing of the root pane
(rather than invoking close tab flow in the Terminal Page).
2. Currently panes are not aware that the closing was canceled,
and thus they trigger the Closed event, putting the system in a weird state,
where the Closed handlers were invoked, but the Pane remains.
This PR mitigates #9502, by addressing the first root cause
(the fix is trivial and hopefully can be serviced).
Moreover, it addresses the only existing UI flow that can trigger the issue.
The remaining problematic flow will occur when the connection is closed.
I have created a separate Issue to track it:
https://github.com/microsoft/terminal/issues/9572
as I guess the PR for it might be more complex.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/9502
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already.
Currently dismissing "are you sure you wish to close read-only tab or pane"
dialog by pressing `ESC` will not abort tab closing
(aka the tab will be closed!)
The reason for this, is that we cancel, only if the "Cancel" is pressed
(aka result=PrimaryButton, while ESC returns result=None).
This PR fixes this, by doing what we usually do:
* Putting Cancel in the CloseButton (which is also triggered by ESC)
* Aborting the action if the result is not a Primary Button
However, since we want Cancel to be a default action,
we set CloseButton to be the DefaultButton in XAML
This is a small refactor on my way to much bigger, more painful refactors. This PR does five things:
* `TermControl.*` has historically had all the control-relevant EventArgs defined in the same file as TermControl. That's just added clutter to the files, clutter that could have been in it's own place. We'll move all those event arg to their own files.
* We'll also move `IDirectKeyListener` to its own file while we're at it.
* We'll update some of `TermControl`'s old `DEFINE`/`DECLARE_TYPED_EVENT` macros to the newer `TYPED_EVENT` macro, which is a bit nicer.
* We'll change `TermControl.TitleChanged` to a typed event. I needed that for a future PR, so let's just do it here
* While we're updating `TYPED_EVENT` macros, let's do `TerminalPage` too.
### checklist
* [x] I work here
* [x] This is work for #1256, but we've got a long way to go before that works.
TIL that the `<None Include="Foo.def" />` line in our projects is
actually totally meaningless. The important line is the one that's in
`cppwinrt.build.pre.props`, where we declare
```xml
<ModuleDefinitionFile Condition="Exists('$(ProjectName).def')">$(ProjectName).def</ModuleDefinitionFile>
```
So if you change a project's name, and not the `.def` file, then the
linker will just _not use the `.def` file at all_.
More importantly, this seemingly doesn't matter in debug builds. In a
Debug build, the linker will happily still include `WINRT_CanUnloadNow`
and `WINRT_GetActivationFactory` in the exports from the dll, even
without the `.def`. But in a Release build, the linker is much more
agressive about pruning symbols that aren't referenced, and without
those two, NONE of the symbols are eventually referenced.
This PR fixes `Microsoft.Terminal.Control` by renaming the `.def`, and
makes it marginally harder for someone to make the same mistake in the
future.
## References
* Regressed in #9472
## PR Checklist
* [x] Closes#9529
* [x] I work here
