Commit graph

5 commits

Author SHA1 Message Date
Mike Griese 3323dc5724
Auto-format our XAML files and enforce in CI (#9589)
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
2021-03-29 17:09:38 -05:00
Dustin L. Howett d944d9f181
wpf: target netcoreapp3.1, clean up test project path (#8491)
There were some minor annoyances with the WPF projects.

1. WpfTerminalTestNetCore was in an unnecessary same-named subdirectory
2. The build started throwing deprecation warnings because `netcoreapp3.0` is not LTS and is going away.
2020-12-04 18:17:25 +00:00
Mike Griese db518c0b06
Fix 3 different bugs in the WPF control (#6464)
* [wpf] WM_KEYUP crashes on x64 #6444
  - Turns out that doing the `(uint)lParam` cast worked fine for the
    keydowns, because the value of lParam usually didn't have super
    high-order bits set. That's not the case for keyups, where the 30th
    bit is _always_ set. This is fixed by explicitly getting the byte
    with the scancode in it.
* [wpf] WM_KEYUP generates wrong value in Win32 input mode #6445
  - This was fixed by basically the same thing as the above.
* [wpf] WPF control crashes on startup trying to render cursor #6446
  - This was a regression from #6337. I forgot to initialize the brush
    used to paint the cursor, because the UWP version always uses color
    (but the WPF one relies on the text foreground color).
* Also adds a minor change to the WPF test app, so that the user can
  actually exit `win32-input-mode`.

* #6337 regressed #6446 
* #6309 regressed the other two.

Closes #6444
Closes #6445
Closes #6446
2020-06-11 18:05:43 +00:00
Dustin L. Howett 8dcfd61278
WpfTest: Add an x86/Win32 build, make DPI aware (#6455)
This matches more closely how Visual Studio uses the WPF control.
It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 21:08:16 +00:00
Dustin L. Howett 48b99faed1
wpf: add a .NET Core WPF Test project for the WPF Control (#6441)
This commit introduces a new project that lets you F5 a working instance
of the Wpf Terminal Control.

To make the experience as seamless as possible, I've introduced another
solution platform called "DotNet_x64Test". It is set to build the WPF
projects for "Any CPU" and every project that PublicTerminalCore
requires (including itself) for "x64". This is the only way to ensure
that when you press F5, all of the native and managed dependencies get
updated.

It's all quite cool when it works.
2020-06-09 13:41:42 -07:00