Commit graph

4 commits

Author SHA1 Message Date
Dustin L. Howett fc9a46dbbd
Remove all our path antics; force native projects to bin/, obj/ (#8062)
This commit fixes our longstanding build artifact output issues and
finally unifies all C++ project output into bin/ and obj/.

In light of that, I've removed NoOutputRedirection.

I've also updated WTU and U8U16Test to use our common build props and
fixed any warnings/compilation errors that popped out.

I validated this change by running repeated incremental builds after
changing individual .cpp files in many of our C++/WinRT projects.
2020-10-27 15:00:41 -07:00
Phil Nachreiner 62d7f11b4a Add a Windows.UI.Text.Core IME overlay to TerminalControl (#1919)
TerminalControl doesn't use any of the built in text input and edit
controls provided by XAML for text input, which means TermianlControl
needs to communicate with the Text Services Framework (TSF) in order to
provide Input Method Editor (IME) support.  Just like the rest of
Terminal we get to take advantage of newer APIs (Windows.UI.Text.Core)
namespace to provide support vs. the old TSF 1.0.

Windows.UI.Text.Core handles communication between a text edit control
and the text services primarily through a CoreTextEditContext object.

This change introduces a new UserControl TSFInputControl which is a
custom EditControl similar to the CustomEditControl sample[1].

TSFInputControl is similar (overlay with IME text) to how old console
(conimeinfo) handled IME. 

# Details
TSFInputControl is a Windows.UI.Xaml.Controls.UserControl

TSFInputControl contains a Canvas control for absolution positioning a
TextBlock control within its containing control (TerminalControl).

The TextBlock control is used for displaying candidate text from the
IME.  When the user makes a choice in the IME the TextBlock is cleared
and the text is written to the Terminal buffer like normal text.

TSFInputControl creates an instance of the CoreTextEditContext and
attaches appropriate event handlers to CoreTextEditContext in order to
interact with the IME.

A good write-up on how to interact with CoreTextEditContext can be found
here[2].

## Text Updates
Text updates from the IME come in on the TextUpdating event handler,
text updates are stored in an internal buffer (_inputBuffer).

## Completed Text
Once a user selects a text in the IME, the CompositionCompleted handler
is invoked.  The input buffer (_inputBuffer) is written to the Terminal
buffer, _inputBuffer is cleared and Canvas and TextBlock controls are
hidden until the user starts a composition session again.

## Positioning
Telling the IME where to properly position itself was the hardest part
of this change.  The IME expects to know it's location in screen
coordinates as supposed to client coordinates.  This is pretty easy if
you are a pure UWP, but since we are hosted inside a XAMLIsland the
client to screen coordinate translation is a little harder.  

### Calculating Screen Coordinates
1. Obtaining the Window position in Screen coordinates.
2. Determining the Client coordinate of the cursor.
3. Converting the Client coordinate of the cursor to Screen coordinates.
4. Offsetting the X and Y coordinate of the cursor by the position of
   the TerminalControl within the window (tabs if present, margins, etc..).
5. Applying any scale factor of the display.

Once we have the right position in screen coordinates, this is supplied
in the LayoutBounds of the CoreTextLayoutRequestedEventArgs which lets
the IME know where to position itself on the Screen.

## Font Information/Cursor/Writing to Terminal
3 events were added to the TSFInputControl to create a loosely-coupled
implementation between the TerminalControl and the TSFInputControl.
These events are used for obtaining Font information from the
TerminalControl, getting the Cursor position and writing to the terminal
buffer.

## Known Issues

- Width of TextBlock is hardcoded to 200 pixels and most likely should
  adjust to the available width of the current input line on the console
  (#3640)
- Entering text in the middle of an existing set of text has TextBlock
  render under existing text. Current Console behavior here isn't good
  experience either (writes over text)
- Text input at edges of window is clipped versus wrapping around to
  next line.  This isn't any worse than the original command line, but
  Terminal should be better (#3657)

## Future Considerations
Ideally, we'd be able to interact with the console buffer directly and
replace characters as the user types. 

## Validation
General steps to try functionality
- Open Console
- Switch to Simplified Chinese (Shortcut: Windows+Spacebar)
- Switch to Chinese mode on language bar

Scenarios validated:
- As user types unformatted candidates appear on command line and IME
  renders in correct position under unformatted characters.
- User can dismiss IME and text doesn't appear on command line 
- Switch back to English mode, functions like normal
- New tab has proper behavior
- Switching between tabs has proper behavior
- Switching away from Terminal Window with IME present causes IME to
  disappear

[1]: https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/CustomEditControl
[2]: https://docs.microsoft.com/en-us/windows/uwp/design/input/custom-text-input

Closes #459
Closes #2213
Closes #3641
2019-11-21 16:25:50 -08:00
Dustin L. Howett (MSFT) 9dc922fc37
Unify and clean up the common build properties (#3429)
This commit cleans up and deduplicates all of the common build
preamble/postamble across exe, dll, lib and c++/winrt projects.

The following specific changes have been made:
* All projects now define their ConfigurationType
* All projects now set all their properties *before* including a common
  build file (or any other build files)
* cppwinrt.pre and cppwinrt.post now delegate most of their
  configuration to common.pre and common.post
* (becuase of the above,) all build options are conserved between
  console and c++/winrt components, including specific warnings and
  preprocessor definitions.
* More properties that are configurable per-project are now
  conditioned so the common props don't override them.
* The exe, dll, exe.or.dll, and lib postincludes have been merged into
  pre or post and switched based on condition as required
* Shared items (-shared, -common) are now explicitly vcxitems instead of
  vcxproj files.
* The link line is now manipulated after Microsoft.Cpp sets it, so the
  libraries we specify "win". All console things link first against
  onecore_apiset.lib.
* Fix all compilation errors caused by build unification
* Move CascadiaPackage's resources into a separate item file

Fixes #922.
2019-11-05 14:29:11 -08:00
Dustin L. Howett (MSFT) 15505337d8
Introduce a WinRT utils library and "checked resources" (#3350)
This commit introduces a C++/WinRT utility library and moves
ScopedResourceLoader into it. I decided to get uppity and introduce
something I like to call "checked resources." The idea is that every
resource reference from a library is knowable at compile time, and we
should be able to statically ensure that all resources exist.

This is a system that lets us immediately failfast (on launch) when a
library makes a static reference to a resource that doesn't exist at
runtime.

It exposes two new (preprocessor) APIs:
* `RS_(wchar_t)`: loads a localizable string resource by name.
* `USES_RESOURCE(wchar_t)`: marks a resource key as used, but is intended
  for loading images or passing static resource keys as parameters to
  functions that will look them up later.

Resource checking relies on diligent use of `USES_RESOURCE()` and `RS_()`
(which uses `USES_RESOURCE`), but can make sure we don't ship something
that'll blow up at runtime.

It works like this:

**IN DEBUG MODE**
- All resource names referenced through `USES_RESOURCE()` are emitted
  alongside their referencing filenames and line numbers into a static
  section of the binary.
  That section is named `.util$res$m`.

- We emit two sentinel values into two different sections, `.util$res$a`
  and `.util$res$z`.

- The linker sorts all sections alphabetically before crushing them
  together into the final binary.

- When we first construct a library's scoped resource loader, we
  iterate over every resource reference between `$a` and `$z` and check
  residency.

**IN RELEASE MODE**
- All checked resource code is compiled out.

Fixes #2146.

Macros are the only way to do something this cool, incidentally.

## Validation Steps Performed
Made references to a bunch of bad resources, tried to break it a lot.

It looks like this when it fails:

### App.cpp
```
36  static const std::array<std::wstring_view, 2> settingsLoadErrorsLabels {
37      USES_RESOURCE(L"NoProfilesText"),
38      USES_RESOURCE(L"AllProfilesHiddenText_HA_JUST_KIDDING")
39  };
```

```
WinRTUtils\LibraryResources.cpp(68)\TerminalApp.dll:
    FailFast(1) tid(1034) 8000FFFF Catastrophic failure
    Msg:[Resource AllProfilesHiddenText_HA_JUST_KIDDING not found in
      scope TerminalApp/Resources (App.cpp:38)] [EnsureAllResourcesArePresent]
```
2019-11-01 15:47:05 -07:00