mirror of
https://github.com/chylex/.NET-Community-Toolkit.git
synced 2026-08-15 11:31:22 +02:00
main
48
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 msftbot[bot]andGitHub
|
e3a9464c4b |
Fixed generated properties within regions (#4227)
<!-- 🚨 Please Do Not skip any instructions and information mentioned below as they are all required and essential to evaluate and test the PR. By fulfilling all the required information you will be able to reduce the volume of questions and most likely help merge the PR faster 🚨 --> <!-- 👉 It is imperative to resolve ONE ISSUE PER PR and avoid making multiple changes unless the changes interrelate with each other --> <!-- 📝 Please always keep the "☑️ Allow edits by maintainers" button checked in the Pull Request Template as it increases collaboration with the Toolkit maintainers by permitting commits to your PR branch (only) created from your fork. This can let us quickly make fixes for minor typos or forgotten StyleCop issues during review without needing to wait on you doing extra work. Let us help you help us! 🎉 --> ## Fixes #4225 <!-- Add the relevant issue number after the word "Fixes" mentioned above (for ex: "## Fixes #1234") which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more options below that apply to this PR. --> - Bugfix <!-- - Feature --> <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? Compilation fails If the Microsoft MVVM Toolkit source generator attribute `[ObservableProperty]` is in a `#region` block. <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> ## What is the new behavior? The generated code is now correct when regions are used. <!-- Describe how was this issue resolved or changed? --> ## PR Checklist Please check if your PR fulfills the following requirements: <!-- and remove the ones that are not applicable to the current PR --> - [X] Tested code with current [supported SDKs](../#supported) - [X] New component - [X] Pull Request has been submitted to the documentation repository [instructions](../blob/main/Contributing.md#docs). Link: <!-- docs PR link --> - [X] Added description of major feature to project description for NuGet package (4000 total character limit, so don't push entire description over that) - [X] If control, added to Visual Studio Design project - [X] Sample in sample app has been added / updated (for bug fixes / features) - [X] Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/CommunityToolkit/WindowsCommunityToolkit-design-assets) - [X] New major technical changes in the toolkit have or will be added to the [Wiki](https://github.com/CommunityToolkit/WindowsCommunityToolkit/wiki) e.g. build changes, source generators, testing infrastructure, sample creation changes, etc... - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run _build/UpdateHeaders.bat_) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
aeeb669319 |
Attached Shadows (Composition and Win2D + Animations) (#4179)
## Fixes #3122 #3607 #3516 _Also implements #3693 for the new DropShadow._ FYI @seanocali as this is a different implementation approach (which is simpler to use outside of the DropShadowPanel we've been working on) but should hopefully achieve the same result. This PR adds attached shadows which can easily be attached to any FrameworkElement without needing to modify the layout like DropShadowPanel does today. They can also be shared using a resource, added to the style of an element, and animated! All the things! 🎉 ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more options below that apply to this PR. --> <!-- - Bugfix --> - Feature by @Ryken100 and integrated/extended by @michael-hawker <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? DropShadowPanel is clunky and requires modifying how you layout your app. ## What is the new behavior? Just attach a shadow and be done! (DropShadowPanel is deprecated.) ## PR Checklist - [x] Composition Only Shadow Support? (with Target) - [x] Add XML Docs - [x] Animation Support to Explicit Animation System? - [x] Bug can't use `AttachedCardShadow` directly with `Border`? Please check if your PR fulfills the following requirements: <!-- and remove the ones that are not applicable to the current PR --> - [ ] Tested code with current [supported SDKs](../#supported) - [ ] Pull Request has been submitted to the documentation repository [instructions](../blob/main/Contributing.md#docs). Link: <!-- docs PR link --> - [ ] Sample in sample app has been added / updated (for bug fixes / features) - [ ] Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/CommunityToolkit/WindowsCommunityToolkit-design-assets) - [ ] New major technical changes in the toolkit have or will be added to the [Wiki](https://github.com/CommunityToolkit/WindowsCommunityToolkit/wiki) e.g. build changes, source generators, testing infrastructure, sample creation changes, etc... - [ ] Tests for the changes have been added (for bug fixes / features) (if applicable) - [ ] Header has been added to all new source files (run _build/UpdateHeaders.bat_) - [ ] Contains **NO** breaking changes <!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below. Please note that breaking changes are likely to be rejected within minor release cycles or held until major versions. --> ## Other information <!-- Please add any other information that might be helpful to reviewers. --> |
||
|
msftbot[bot]andGitHub
|
f24528f894 |
Add WinUI 2.6 Dependency to UnitTests.UWP App (#4156)
## Related to #3650 Splitting out the upgrade to WinUI 2.6 in the Unit Tests project to help try and isolate what might be going on. Noticed some our other NuGet dependencies have updates as well, so if this works as-is, will try and update those as well. Then we can check this in, and rebase #3650 to try and determine what else might be going on or pull in others to help investigate. FYI @huynhsontung @azchohfi ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more options below that apply to this PR. --> <!-- - Bugfix --> <!-- - Feature --> <!-- - Code style update (formatting) --> - Refactoring (no functional changes, no api changes) <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? WinUI 2.6 not included when we run unit tests ## What is the new behavior? WinUI 2.6 is now included when we run unit tests. ## PR Checklist Please check if your PR fulfills the following requirements: - [ ] Tested code with current [supported SDKs](../readme.md#supported) - [ ] Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link --> - [ ] Sample in sample app has been added / updated (for bug fixes / features) - [ ] Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/CommunityToolkit/WindowsCommunityToolkit-design-assets) - [ ] New major technical changes in the toolkit have or will be added to the [Wiki](https://github.com/CommunityToolkit/WindowsCommunityToolkit/wiki) e.g. build changes, source generators, testing infrastructure, sample creation changes, etc... - [ ] Tests for the changes have been added (for bug fixes / features) (if applicable) - [ ] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [ ] Contains **NO** breaking changes <!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below. Please note that breaking changes are likely to be rejected within minor release cycles or held until major versions. --> ## Other information |
||
|
msftbot[bot]andGitHub
|
94a6edcae3 |
Fix warnings in HighPerformance/Mvvm unit tests (#4142)
## Fixes https://github.com/CommunityToolkit/WindowsCommunityToolkit/pull/4102#issuecomment-888964962 <!-- Add the relevant issue number after the "#" mentioned above (for ex: "## Fixes #1234") which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more options below that apply to this PR. --> - Maintenance <!-- - Bugfix --> <!-- - Feature --> <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> Some HighPerformance/Mvvm unit tests produce warnings when the projects are built. ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> No more warnings 🙌 ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [X] Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link --> - [X] Sample in sample app has been added / updated (for bug fixes / features) - [X] Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/CommunityToolkit/WindowsCommunityToolkit-design-assets) - [X] New major technical changes in the toolkit have or will be added to the [Wiki](https://github.com/CommunityToolkit/WindowsCommunityToolkit/wiki) e.g. build changes, source generators, testing infrastructure, sample creation changes, etc... - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
87c1d68a26 |
ObjectStorage enhancements (#4102)
<!-- 🚨 Please Do Not skip any instructions and information mentioned below as they are all required and essential to evaluate and test the PR. By fulfilling all the required information you will be able to reduce the volume of questions and most likely help merge the PR faster 🚨 --> <!-- 👉 It is imperative to resolve ONE ISSUE PER PR and avoid making multiple changes unless the changes interrelate with each other --> <!-- 📝 Please always keep the "☑️ Allow edits by maintainers" button checked in the Pull Request Template as it increases collaboration with the Toolkit maintainers by permitting commits to your PR branch (only) created from your fork. This can let us quickly make fixes for minor typos or forgotten StyleCop issues during review without needing to wait on you doing extra work. Let us help you help us! 🎉 --> ## Fixes #3903 <!-- Add the relevant issue number after the "#" mentioned above (for ex: "## Fixes #1234") which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more options below that apply to this PR. --> <!-- - Bugfix --> - Feature <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> The ObjectStorage helper interfaces and implementations currently live in the `*.Uwp` package. This means that they are not consumable from NetStandard projects, such as the `CommunityToolkit.Graph` package. In addition, the `IObjectStorageHelper` is a mixture of support for both dictionary style settings storage, with some file storage features as well. Currently, supporting both file and folder scenarios is odd/difficult for storage endpoints that don't operate in a similar manner to `Windows.Storage.ApplicationData`. Lastly, the support for file storage in `IObjectStorageHelper` is not complete and missing some basic CRUD operations that can make it difficult to work with in real-world application scenarios. ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> I've done a few things: 1. Deprecated the existing structures in the `Microsoft.Toolkit.Uwp/Helpers/ObjectStorage` folder: - `BaseObjectStorageHelper` - `IObjectSerializer` - `IObjectStorageHelper` - `LocalObjectStorageHelper` - `SystemSerializer` 2. Migrated some of the previous structures up into the `Microsoft.Toolkit/Helpers/ObjectStorage` folder so that they are consumable from NetStandard: - `IObjectSerializer` - `SystemSerializer` 3. Created new interfaces to replace the functionality defined in the now defunct `IObjectStorageHelper`: - `ISettingsStorageHelper` - Interop with values as key/value pairs, like a dictionary. - `IFileStorageHelper` - Interop with a file system to store values in files and folders. 4. Replaced the functionality provided by `BaseObjectStorageHelper` and `LocalObjectStorageHelper` with an implementation of `ISettingsStorageHelper` and `IFileStorageHelper`: - `ApplicationDataStorageHelper` - Interop with local settings and files through `Windows.Storage.ApplicationData`. Use it like so: ``` ApplicationDataStorageHelper appDataStorageHelper = ApplicationDataStorageHelper.GetCurrent(new Toolkit.Helpers.SystemSerializer()); // Save and Read simple objects string keySimpleObject = "simple"; appDataStorageHelper.Save(keySimpleObject, 42); appDataStorageHelper.TryRead<string>(keySimpleObject, out string result); // Save and Read complex objects string complexObjectKey = "complexObject"; await appDataStorageHelper.SaveFileAsync(complexObjectKey, new MyComplexObject()); var complexObject = await appDataStorageHelper.ReadFileAsync<MyComplexObject>(complexObjectKey); // Complex object example public class MyComplexObject { public string MyContent { get; set; } public List<string> MyContents { get; set; } public List<MyComplexObject> MyObjects { get; set; } } ``` Altogether, this provides a transition path from the previous ObjectStorage constructs to a more granular set of interfaces with identical signatures plus enhanced support for file and folder CRUD operations. ## PR Checklist Please check if your PR fulfills the following requirements: - [x] Tested code with current [supported SDKs](../readme.md#supported) - [ ] Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link --> - [x] Sample in sample app has been added / updated (for bug fixes / features) - [x] Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets) - [x] New major technical changes in the toolkit have or will be added to the [Wiki](https://github.com/windows-toolkit/WindowsCommunityToolkit/wiki) e.g. build changes, source generators, testing infrastructure, sample creation changes, etc... - [x] Tests for the changes have been added (for bug fixes / features) (if applicable) - [x] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [x] Contains **NO** breaking changes <!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below. Please note that breaking changes are likely to be rejected within minor release cycles or held until major versions. --> ## Other information Looking for feedback! |
||
|
msftbot[bot]andGitHub
|
5e02bea36d |
Expose public indexer and length properties on RefEnumerable<T> and ReadOnlyRefEnumerable<T> (#4047)
## Closes #4043 ## PR Type What kind of change does this PR introduce? - Feature ## What is the current behavior? Currently, `RefEnumerable<T>` (and its read-only variant) do not expose an indexer or their length. This can make it difficult to implement certain APIs against them, such as a function to reverse their data. ## What is the new behavior? This PR exposes public length and indexer properties (for both `int` and `System.Index`) on both `RefEnumerable<T>` and `ReadOnlyRefEnumerable<T>`. ```diff public partial readonly ref struct RefEnumerable<T> { + public int Length { get; } + public ref T this[int index] { get; } + public ref T this[Index index] { get; } } public partial readonly ref struct ReadOnlyRefEnumerable<T> { + public int Length { get; } + public ref readonly T this[int index] { get; } + public ref readonly T this[Index index] { get; } } ``` ## PR Checklist Please check if your PR fulfills the following requirements: - [x] Tested code with current [supported SDKs](../readme.md#supported) - [ ] Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link --> - [ ] ~Sample in sample app has been added / updated (for bug fixes / features)~ - [ ] ~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~ - [ ] ~New major technical changes in the toolkit have or will be added to the [Wiki](https://github.com/windows-toolkit/WindowsCommunityToolkit/wiki) e.g. build changes, source generators, testing infrastructure, sample creation changes, etc...~ - [x] Tests for the changes have been added (for bug fixes / features) (if applicable) - [ ] ~Header has been added to all new source files (run *build/UpdateHeaders.bat*)~ - [x] Contains **NO** breaking changes ## Other information It may be worthwhile to additionally expose the `Step` field and the newly-added `DangerousGetReference`/`DangerousGetReferenceAt` methods. This would allow for an implementation of `Reverse` that avoids bounds-checking. |
||
|
msftbot[bot]andGitHub
|
2c136db739 |
Fix register/unregister issues of WeakReferenceMessenger (#4082)
<!-- 🚨 Please Do Not skip any instructions and information mentioned below as they are all required and essential to evaluate and test the PR. By fulfilling all the required information you will be able to reduce the volume of questions and most likely help merge the PR faster 🚨 --> <!-- 👉 It is imperative to resolve ONE ISSUE PER PR and avoid making multiple changes unless the changes interrelate with each other --> <!-- 📝 Please always keep the "☑️ Allow edits by maintainers" button checked in the Pull Request Template as it increases collaboration with the Toolkit maintainers by permitting commits to your PR branch (only) created from your fork. This can let us quickly make fixes for minor typos or forgotten StyleCop issues during review without needing to wait on you doing extra work. Let us help you help us! 🎉 --> ## Fixes #4081 <!-- Add the relevant issue number after the "#" mentioned above (for ex: "## Fixes #1234") which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more options below that apply to this PR. --> Bugfix <!-- - Feature --> <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> The attached message handlers of a WeakReferenceMessenger do not get called anymore correctly for all registered objects after unregistering one of them. ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> The attached message handlers get called for all registered objects. There was an issue with the enumerator of the ConditionalWeakTable. The linked list nodes were not iterated correctly when a key gets removed while enumerating. In this case the "Next"-property of the node was set to null and the while loop stopped immediately (without checking the remaining nodes). As a fix the next node is now kept as a locale variable so that it does not get lost when removing the key. ## PR Checklist Please check if your PR fulfills the following requirements: - [x] Tested code with current [supported SDKs](../readme.md#supported) - [ ] Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link --> - [ ] Sample in sample app has been added / updated (for bug fixes / features) - [ ] Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets) - [ ] New major technical changes in the toolkit have or will be added to the [Wiki](https://github.com/windows-toolkit/WindowsCommunityToolkit/wiki) e.g. build changes, source generators, testing infrastructure, sample creation changes, etc... - [x] Tests for the changes have been added (for bug fixes / features) (if applicable) - [ ] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [x] Contains **NO** breaking changes <!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below. Please note that breaking changes are likely to be rejected within minor release cycles or held until major versions. --> ## Other information |
||
|
msftbot[bot]andGitHub
|
ab4ba75f1d |
Fix [ReadOnly]Span2D<T>.TryGetSpan on legacy frameworks (#3948)
## Fixes #3947 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - Bugfix <!-- - Feature --> <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> `[ReadOnly]Span2D<T>.TryGetSpan` throws an exception when wrapping a `T[]` instance on legacy frameworks. ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> `[ReadOnly]Span2D<T>.TryGetSpan` works correctly on legacy frameworks. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] New major technical changes in the toolkit have or will be added to the [Wiki](https://github.com/windows-toolkit/WindowsCommunityToolkit/wiki) e.g. build changes, source generators, testing infrastructure, sample creation changes, etc... - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
13ef1d7ec8 |
Fixed ReadOnlySpan2D<T>.Slice parameters order (#3951)
## Fixup for #3353 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - Bugfix <!-- - Feature --> <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## Overview <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> `ReadOnlySpan2D<T>.Slice` has the incorrect ordering for the `height` and `width` parameters, which is inverted with respect to those in `Span2D<T>.Slice`. This is an oversight from a refactor in the original PR, and as a result it also causes the `ReadOnlySpan2D<T>.this[Range, Range]` indexer to fail for `ReadOnlySpan2D<T>`. This PR fixes both issues and adds a new series of tests for the two indexers as well. We probably didn't notice this before since those indexers are not available on UWP 🤔 > **NOTE:** this PR technically introduces a breaking change (swapped parameters in the `.Slice` method, but as that's an issue and not intended, and also because they're in the right order in `Span2D<T>`, it's more of a fix than an actual breaking change. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] New major technical changes in the toolkit have or will be added to the [Wiki](https://github.com/windows-toolkit/WindowsCommunityToolkit/wiki) e.g. build changes, source generators, testing infrastructure, sample creation changes, etc... - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [ ] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
3b6b3de3b9 |
Enabled correct WeakReferenceMessenger path on .NET 5 (#3932)
## Follow up for #3424 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - Bugfix-ish <!-- - Feature --> <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## Overview <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> The .NET 5 target currently uses the .NET Standard 2.0 code path within `WeakReferenceMessenger`. Not technically a bug since the implementation does work, but it can be greatly simplified like on .NET Standard 2.1. This should also make the code add slightly less GC pressure over time due to less additional data structures in use. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] New major technical changes in the toolkit have or will be added to the [Wiki](https://github.com/windows-toolkit/WindowsCommunityToolkit/wiki) e.g. build changes, source generators, testing infrastructure, sample creation changes, etc... - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
e99e7cfd89 |
Fix few typos in comments (#3923)
## Fixes
Fix few typos in the code base. Note that only comments are impacted by this change.
## PR Type
What kind of change does this PR introduce?
- Documentation content changes
## What is the current behavior?
N/A
## What is the new behavior?
N/A
## PR Checklist
Please check if your PR fulfills the following requirements:
- [x] Tested code with current [supported SDKs](../readme.md#supported)
- [ ] Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->
- [ ] Sample in sample app has been added / updated (for bug fixes / features)
- [ ] Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)
- [ ] New major technical changes in the toolkit have or will be added to the [Wiki](https://github.com/windows-toolkit/WindowsCommunityToolkit/wiki) e.g. build changes, source generators, testing infrastructure, sample creation changes, etc...
- [ ] Tests for the changes have been added (for bug fixes / features) (if applicable)
- [ ] Header has been added to all new source files (run *build/UpdateHeaders.bat*)
- [x] Contains **NO** breaking changes
## Other information
|
||
|
msftbot[bot]andGitHub
|
94b6098b1a |
Add NullableHelper (#3389)
cc @Sergio0694 Introduce a `NullableHelper` type with `GetValueOrDefaultRef` which returns a `ref T` which points to a value that is equivalent to `GetValueOrDefault` TODO add tests |
||
|
msftbot[bot]andGitHub
|
2e99c2b445 |
Refactor namespaces for extension types (#3743)
## Related to #3422 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> <!-- - Bugfix --> <!-- - Feature --> <!-- - Code style update (formatting) --> - Refactoring <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> Quoting from https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3422#issuecomment-774484219, we have the current situation with respect to extension methods in the Toolkit: > On a related note - lately I've been thinking a bit about the various extensions in the toolkit in particular. @mrlacey already pointed this out in the first post in this issue, and I agree that that inconsistency is a bit weird, especially now that newer packages have started to just place them in their respective root namespaces. Basically we have the following situation: > > - `Microsoft.Toolkit.Extensions` (from `Microsoft.Toolkit`)❌ > - `Microsoft.Toolkit.Extensions` (from `Microsoft.Toolkit.Diagnostics`*) ❌ > - `Microsoft.Toolkit.HighPerformance.Extensions` ❌ > - `Microsoft.Toolkit.Mvvm.Messaging` ✅ > - `Microsoft.Toolkit.Uwp.Extensions` ❌ > - `Microsoft.Toolkit.Uwp.UI.Extensions` ❌ > - `Microsoft.Toolkit.Uwp.UI.Animations` ✅ > - `Microsoft.Toolkit.Uwp.UI.Media`** ✅ ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> This PR moves all the extensions (including XAML markup extensions) to the root namespace of each package. It also fixes some related issues like inconsistent naming, incorrect method locations, etc. ## Open questions Some extension types now have a number of properties that are only relevant when grouped together, as they refer a specific feature. For instance, all the SurfaceDial properties in `TextBoxExtensions`, or the ones related to Regex. @michael-hawker mentioned the "option" pattern that the Graph Controls have been using, which would look something like this: ```xml <TextBox> <ui:TextBoxExtentions.SurfaceDial> <ui:SurfaceDialOptions MinValue="0" MaxValue="10" EnableHapticFeedback="True" ... /> </ui:TextBoxExtensions.SurfaceDial> </TextBox> ``` Do we want to make this change as well while we're at it? Thoughts? 🙂 ## Additional details Haven't fully tested all the samples in the sample app just yet, have just focused on ensuring everything built fine for now. Also, this PR is based on top of #3685, which needs to be merged before this one. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] New major technical changes in the toolkit have or will be added to the [Wiki](https://github.com/windows-toolkit/WindowsCommunityToolkit/wiki) e.g. build changes, source generators, testing infrastructure, sample creation changes, etc... - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [ ] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
df6dba5da0 |
Bug fixes to ObservableValidator (#3764)
## Fixes #3763 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - Bugfix <!-- - Feature --> <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> - Incorrect loading of display names for validated properties - Repeated error messages after validation ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> Fixed the errors above. Opening as a draft to have the CI run, but I'm still investigating the second issue from the list above. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] New major technical changes in the toolkit have or will be added to the [Wiki](https://github.com/windows-toolkit/WindowsCommunityToolkit/wiki) e.g. build changes, source generators, testing infrastructure, sample creation changes, etc... - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
0198299b4f |
Move Deferred helpers to Microsoft.Toolkit (#3762)
## Fixes #3707 Moves the Deferred Event Helpers to the main .NET package and leaves the Uwp specific extensions in the Microsoft.Toolkit.Uwp package. ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> <!-- - Bugfix --> <!-- - Feature --> <!-- - Code style update (formatting) --> - Refactoring (no functional changes, no api changes) <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? Deferred events pattern only available in UWP. ## What is the new behavior? Deferred events pattern can be used in .NET ## PR Checklist Please check if your PR fulfills the following requirements: - [ ] Tested code with current [supported SDKs](../readme.md#supported) - [ ] Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link --> - [ ] Sample in sample app has been added / updated (for bug fixes / features) - [ ] Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets) - [ ] New major technical changes in the toolkit have or will be added to the [Wiki](https://github.com/windows-toolkit/WindowsCommunityToolkit/wiki) e.g. build changes, source generators, testing infrastructure, sample creation changes, etc... - [ ] Tests for the changes have been added (for bug fixes / features) (if applicable) - [ ] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [ ] Contains **NO** breaking changes <!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below. Please note that breaking changes are likely to be rejected within minor release cycles or held until major versions. --> ## Other information |
||
|
msftbot[bot]andGitHub
|
e184ee92c0 |
Upgrade to WinUI 2.5 and other Dependencies - Deprecate RadialProgressBar (#3758)
## Contributes to #3062 Adds deprecation message to the RadialProgressBar. Updates some of our dependencies. Few more to do, but will wait until we remove parsers and services packages. |
||
|
msftbot[bot]andGitHub
|
a8a3324955 |
[Feature] Microsoft.Toolkit.Mvvm package (Preview 5) (#3562)
## Follow up to #3428 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> This PR is for tracking all changes/fixes/improvements to the `Microsoft.Toolkit.Mvvm` package following the Preview 4. <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - Feature - Improvements <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## Overview This PR is used to track and implement new features and tweaks for the `Microsoft.Toolkit.Mvvm` package. See the linked issue for more info, and for a full list of changes included in this PR. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
43b79699a4 |
Simplified namespaces in HighPerformance package (#3687)
<!-- 🚨 Please Do Not skip any instructions and information mentioned below as they are all required and essential to evaluate and test the PR. By fulfilling all the required information you will be able to reduce the volume of questions and most likely help merge the PR faster 🚨 --> <!-- 📝 It is preferred if you keep the "☑️ Allow edits by maintainers" checked in the Pull Request Template as it increases collaboration with the Toolkit maintainers by permitting commits to your PR branch (only) created from your fork. This can let us quickly make fixes for minor typos or forgotten StyleCop issues during review without needing to wait on you doing extra work. Let us help you help us! 🎉 --> ## Related to #3422 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - Refactoring - Improvements <!-- - Bugfix --> <!-- - Feature --> <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## Overview Following the suggestion from @mrlacey for non-breaking changes, this PR moves the new `Span2D<T>` and `Memory2D<T>` types introduced in version 7.0 to the root `Microsoft.Toolkit.HighPerformance` namespace (instead of `.Memory`). This is simpler to use for consumers, it makes sense given that the root namespace already contains some other "primitive" types, and it's also more consistent to how the `Span<T>` and `Memory<T>` types are included in the `System.Memory` package, but are still located in the root `System` namespace. This PR also includes some minor codegen improvements to some other extensions, while I was at it 😄 ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] New major technical changes in the toolkit have or will be added to the [Wiki](https://github.com/windows-toolkit/WindowsCommunityToolkit/wiki) e.g. build changes, source generators, testing infrastructure, sample creation changes, etc... - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
814b174725 |
Split Microsoft.Toolkit.Diagnostics package (#3726)
### Related to #3594, working towards reducing footprint and increasing modularity <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> <!-- - Bugfix --> <!-- - Feature --> <!-- - Code style update (formatting) --> - Refactoring (no functional changes, no api changes) <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> The `Guard` and `ThrowHelper` APIs are part of the `Microsoft.Toolkit` package. This has a few downsides with respect to binary size for consuming package and overall API surface for consumers. The `Guard` and `ThrowHelper` APIs relied on a number of different NuGet packages that needed to be pulled in: - `System.Diagnostics.Contracts` - `System.ValueTuple` - `System.Memory` - `System.Runtime.CompilerServices.Unsafe` These packages are _only_ needed by those APIs, and yet with `Microsoft.Toolkit` being referenced by every other package in the whole Toolkit, every other package ended up having a dependency on those as well even when there was no use for them at all. This is not ideal both for final binary size, for the increased number of potentially unwanted APIs being imported by consumers, and due to the fact that many consumers want to minimize the number of NuGet dependencies in general. Furthermore, the `.Diagnostics` APIs can be very useful for all kinds of developers, especially those working in backend scenarios and with a particular focus on performance. It was not ideal to force those developers to also import APIs such as observable collections and other more UI-oriented APIs that were available in the base package (in fact I've spoken with a few devs that didn't like having to include anything other than just the `Guard` and `ThrowHelper` APIs when adding the package). For consumers on .NET 5 that don't use .NET Native, splitting the `Guard` and `ThrowHelper` APIs away means 80KB less in binary size (when not using IL trimming) when those APIs are not needed, which is effectively a 75% reduction on the base package. ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> The `Guard` and `ThrowHelper` APIs have now been moved to a new `Microsoft.Toolkit.Diagnostics` package. Splitting this package completely removes all those dependencies from all other packages too 🚀 This work will also make it easier in the future to introduce a `.Diagnostics` source-only package, if we wanted to. **Note:** marking as breaking change due to the APIs being moved to a different package, but this PR doesn't do any changes to the overall API surface across the various packages - the APIs are still all exactly the same, just modularized differently. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] New major technical changes in the toolkit have or will be added to the [Wiki](https://github.com/windows-toolkit/WindowsCommunityToolkit/wiki) e.g. build changes, source generators, testing infrastructure, sample creation changes, etc... - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [ ] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
cafb0a5054 |
Guard overloads for nint/nuint, codegen improvements (#3573)
## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> <!-- - Bugfix --> - Feature - Optimization <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> There are no `nint`/`nuint` overloads for the any `Guard` APIs. These types have been introduced with C# 9, so it makes sense to add proper support for them given that #3356 added full support for C# 9 and .NET 5 to these packages. Also there were some codegen bits in `Guard.IsCloseTo` that were not ideal. Additionally, the codegen for the `Guard` APIs didn't leverage compiler support properly. ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> ✅ Added new `nint`/`nuint` overloads to `Guard` APIs 🚀 Improved codegen in a number of `Guard.IsCloseTo` overloads 🚀 Improved codegen for faulting blocks ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link --> - [ ] Sample in sample app has been added / updated (for bug fixes / features) - [ ] Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets) - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
d210795043 |
Add lazy loading threshold for ImageEx control (#3483)
## Fixes <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> Add lazy loading threshold for ```ImageEx``` control and change the lazy loading implement that will be also fixed #3258 . <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - Bugfix - Feature <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> If enable lazy loading, only the ImageEx entered the viewport, the source will start to load. ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> Give a threshold for triggering the lazy loading behavior, the default value is 300 px. ## PR Checklist Please check if your PR fulfills the following requirements: - [x] Tested code with current [supported SDKs](../readme.md#supported) - [x] Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: https://github.com/MicrosoftDocs/WindowsCommunityToolkitDocs/pull/387<!-- docs PR link --> - [x] Sample in sample app has been added / updated (for bug fixes / features) - [ ] Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets) - [ ] Tests for the changes have been added (for bug fixes / features) (if applicable) - [ ] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [x] Contains **NO** breaking changes <!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below. Please note that breaking changes are likely to be rejected. --> ## Other information |
||
|
msftbot[bot]andGitHub
|
eeaddbbf8d |
Loop codegen improvements (#3632)
## PR Type
What kind of change does this PR introduce?
<!-- Please uncomment one or more that apply to this PR. -->
- Optimization
<!-- - Bugfix -->
<!-- - Feature -->
<!-- - Code style update (formatting) -->
<!-- - Refactoring (no functional changes, no api changes) -->
<!-- - Build or CI related changes -->
<!-- - Documentation content changes -->
<!-- - Sample app changes -->
<!-- - Other... Please describe: -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying, or link to a relevant issue. -->
Some `for` loops have unoptimal codegen involving the indexing at each iteration.
For instance, as a very simple test, this method simply sets all items in an input `Span<int>` to `0`:
```csharp
public static void M1(Span<int> span)
{
ref int r0 = ref MemoryMarshal.GetReference(span);
int length = span.Length;
for (int i = 0; i < length; i++)
{
Unsafe.Add(ref r0, i) = 0;
}
}
```
```asm
C.M1(System.Span`1<Int32>)
L0000: mov rax, [rcx]
L0003: mov edx, [rcx+8]
L0006: xor ecx, ecx
L0008: test edx, edx
L000a: jle short L001c
L000c: movsxd r8, ecx
L000f: xor r9d, r9d
L0012: mov [rax+r8*4], r9d
L0016: inc ecx
L0018: cmp ecx, edx
L001a: jl short L000c
L001c: ret
```
Here the loop starts at `L000c`, and at every iteration it takes the loop counter, extends it to native int, then uses it to index from the initial reference (that `[rax+r8*4]` offset calculation), and then writes to it. This is unnecessary logic, in cases such as this.
## What is the new behavior?
<!-- Describe how was this issue resolved or changed? -->
Refactored some loops to operate within a target address range, with all indexing out of the loop body.
```csharp
public static void M2(Span<int> span)
{
ref int r0 = ref MemoryMarshal.GetReference(span);
ref int r1 = ref Unsafe.Add(ref r0, span.Length);
while (Unsafe.IsAddressLessThan(ref r0, ref r1))
{
r0 = 0;
r0 = ref Unsafe.Add(ref r0, 1);
}
}
```
```asm
C.M2(System.Span`1<Int32>)
L0000: mov rax, [rcx]
L0003: mov edx, [rcx+8]
L0006: movsxd rdx, edx
L0009: lea rdx, [rax+rdx*4]
L000d: cmp rax, rdx
L0010: jae short L001f
L0012: xor ecx, ecx
L0014: mov [rax], ecx
L0016: add rax, 4
L001a: cmp rax, rdx
L001d: jb short L0012
L001f: ret
```
Here instead we pre-calculate the target address just once, outside the loop, and then just iterate until the initial, moving reference reaches that point. This allows the actual loop to be more compact and with no indexing logic needed. We just read directly from the moving reference, and then increment it by a fixed amount at the end of each iteration. Not groundbreaking, but better 🚀
## PR Checklist
Please check if your PR fulfills the following requirements:
- [X] Tested code with current [supported SDKs](../readme.md#supported)
- [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~
- [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~
- [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~
- [X] Tests for the changes have been added (for bug fixes / features) (if applicable)
- [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*)
- [X] Contains **NO** breaking changes
|
||
|
msftbot[bot]andGitHub
|
0bb94f5a7f |
Improved RuntimeHelpers.ConvertLength codegen (#3608)
<!-- 🚨 Please Do Not skip any instructions and information mentioned below as they are all required and essential to evaluate and test the PR. By fulfilling all the required information you will be able to reduce the volume of questions and most likely help merge the PR faster 🚨 --> <!-- 📝 It is preferred if you keep the "☑️ Allow edits by maintainers" checked in the Pull Request Template as it increases collaboration with the Toolkit maintainers by permitting commits to your PR branch (only) created from your fork. This can let us quickly make fixes for minor typos or forgotten StyleCop issues during review without needing to wait on you doing extra work. Let us help you help us! 🎉 --> ## Follow up from #3520 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - Optimization <!-- - Bugfix --> <!-- - Feature --> <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> The codegen for the second branch in `RuntimeHelpers.ConvertLength` does a signed division: https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/9b75c9f910f999834c64bd00e522d7ae464c121b/Microsoft.Toolkit.HighPerformance/Helpers/Internals/RuntimeHelpers.cs#L43-L46 This is not the best for the codegen, as the JIT has to handle the sign in that division, resulting in the following: ```asm ; [System.Byte, System.Private.CoreLib],[System.Numerics.Vector4, System.Numerics.Vectors] ConvertLength[TFrom, TTo](Int32) L0000: mov eax, ecx L0002: sar eax, 0x1f L0005: and eax, 0xf L0008: add eax, ecx L000a: sar eax, 4 L000d: ret ``` ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> Avoided that with a cast to `uint`, since the length is guaranteed to be a positive value in `[0, int.MaxValue]` anyway: ```asm ; [System.Byte, System.Private.CoreLib],[System.Numerics.Vector4, System.Numerics.Vectors] L0000: mov eax, ecx L0002: shr eax, 4 L0005: ret ``` Perfect! 😄🎉 ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
91157c65cd |
.NET 5 target for Toolkit and HighPerformance packages (#3356)
## Adds the .NET 5 target to `Microsoft.Toolkit.HighPerformance` ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> <!-- - Bugfix --> - Feature <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> The `Microsoft.Toolkit.HighPerformance` package maxes out at .NET Core 3.1. The `Microsoft.Toolkit` package maxes out at .NET Standard 2.1. Additionally, `Microsoft.Toolkit` doesn't have proper nullability annotations, and it reports installing additional dependencies if installed in a .NET 5 apps. The extra dependency is `System.Runtime.CompilerServices.Unsafe` which is actually built-in on .NET 5, but consumers not aware of this would still see the installation prompt from NuGet as reporting an extra indirect dependency. ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> ✅ Added .NET 5 target to `Microsoft.Toolkit.HighPerformance` ✅ Added .NET 5 target to `Microsoft.Toolkit` ✅ Enabled global nullability annotations to `Microsoft.Toolkit` and improved the codebase. ✅ Enabled C# 9 in both projects, with some extra code tweaks. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link --> - [ ] Sample in sample app has been added / updated (for bug fixes / features) - [ ] Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets) - [ ] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes <!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below. Please note that breaking changes are likely to be rejected. --> |
||
|
msftbot[bot]andGitHub
|
da85391ed1 |
Performance improvement in Count<T> extension (#3548)
## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - Performance improvement <!-- - Bugfix --> <!-- - Feature --> <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> About 20% improvement on .NET 5 when working on `char` types (or larger):  This was done by adding an unrolled loop for the vectorized path of the SIMD accelerated version of `Count<T>`. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
41b73b3aa9 |
New IBufferWriter<byte>.AsStream() extension (#3522)
## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> <!-- - Bugfix --> - Feature <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> There is currently no way to interoperate between the `IBufferWriter<T>` interface and the `Stream` class. Many APIs in the BCL and in 3rd party libraries use `Stream` as the standard way to accept an instance that can be written to or read from, and there is no built-in way to have a memory stream that is also using memory pooling, because none of the types in the BCL and in the `HighPerformance` package currently support both features at the same time. This PR fixes that 😄🚀 Consider this example that I saw from a user in the C# Discord server: ```csharp public byte[] Compress(byte[] source) { MemoryStream output = new MemoryStream(); using (DeflateStream dstream = new DeflateStream(output, CompressionLevel.Optimal)) { dstream.Write(source, 0, source.Length); } return output.ToArray(); } public byte[] Decompress(byte[] source) { MemoryStream input = new MemoryStream(source); MemoryStream output = new MemoryStream(); using (DeflateStream dstream = new DeflateStream(input, CompressionMode.Decompress)) { dstream.CopyTo(output); } return output.ToArray(); } ``` You can see how the code is very memory inefficient: the `MemoryStream` type will just `new`-up arrays as it goes, and at the end `ToArray()` is used too, which will duplicate the arrays too. Even by removing that, the main issue within `MemoryStream` remains. With the new extension introduced in this PR, these two APIs can be rewritten much more efficiently, like this: ```csharp public IMemoryOwner<byte> Compress(ReadOnlySpan<byte> span) { ArrayPoolBufferWriter<byte> bufferWriter = new ArrayPoolBufferWriter<byte>(); using DeflateStream deflateStream = new DeflateStream(bufferWriter.AsStream(), CompressionLevel.Optimal); deflateStream.Write(span); return bufferWriter; } public IMemoryOwner<byte> Decompress(ReadOnlyMemory<byte> memory) { ArrayPoolBufferWriter<byte> bufferWriter = new ArrayPoolBufferWriter<byte>(memory.Length); using DeflateStream deflateStream = new DeflateStream(memory.AsStream(), CompressionMode.Decompress); deflateStream.CopyTo(bufferWriter.AsStream()); return bufferWriter; } ``` Which heavily leverages all the various APIs and helpers in the `HighPerformance` package, and gives us the following results: | Method | Categories | Mean | Error | StdDev | Ratio | Gen 0 | Gen 1 | Gen 2 | Allocated | |------- |----------- |------------:|----------:|----------:|------:|---------:|---------:|---------:|----------:| | new[] | COMPRESS | 29,923.5 us | 174.19 us | 162.94 us | 1.00 | 312.5000 | 312.5000 | 312.5000 | 3089853 B | | **pool** | COMPRESS | **29,116.0 us** | 120.55 us | 106.87 us | **0.97** | - | - | - | **297 B** | | | | | | | | | | | | | new[] | DECOMPRESS | 832.9 us | 9.96 us | 8.83 us | 1.00 | 337.8906 | 336.9141 | 336.9141 | 2966680 B | | **pool** | DECOMPRESS | **119.6 us** | 0.70 us | 0.62 us | **0.14** | - | - | - | **392 B** | This benchmark compresses and decompresses a 1MB buffer, using the two methods detailed above. You can see the vastly reduced memory allocations using the pooled writer backed stream 🚀 ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> This PR introduces this new extension: ```csharp namespace Microsoft.Toolkit.HighPerformance.Extensions { public static class ArrayPoolBufferWriterExtensions { public static Stream AsStream(this ArrayPoolBufferWriter<byte> writer); } public static class IBufferWriterExtensions { public static Stream AsStream(this IBufferWriter<byte> writer); } } ``` Which helps to interoperate between the `IBufferWriter<T>` interface and the `Stream` class. In particular, since the `HighPerformance` package includes the `ArrayPoolBufferWriter<T>` type, this extension allows users to use that as a `Stream`, and then keep working with the resulting `ReadOnlyMemory<T>` produced by that type, as shown above. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
ade6c5bc7e |
New [ReadOnly]Memory<T>.Cast<TFrom, TTo> extensions (#3520)
## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - Feature ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> Right now there is no (easy) way to cast a `Memory<TFrom>` instance to a `Memory<TTo>` instance. There are APIs to to do that for `Span<T>` instances, but not for `Memory<T>`. The reason for that is that with a `Span<T>` it's just a matter of retrieving the wrapped reference, reinterpreting it and then adjusting the size, then creating a new `Span<T>` instance. But a `Memory<T>` instance is completely different: it wraps an object which could be either a `T[]` array, a `MemoryManager<T>` instance, etc. The result is that currently there are no APIs in the BCL nor in the toolkit to just "cast" a `Memory<T>`. This feature has been requested by a number of developers, including in a well known library such as `ImageSharp`: > Yes, that's exactly what I would need. But I'm wondering how would you implement it. > It's certainly non trivial to cast a `Memory<byte>` to a `Memory<TPixel>` and if there's an API for that I would gladly want to know... > So I pressume `ImageSharp` would need to do some work under the hood. (_`ImageSharp` issue, [here](https://github.com/SixLabors/ImageSharp/issues/1097#issuecomment-580639914)_) To solve that, I created a very simplified version of the code included in this PR, into a PR [here](https://github.com/SixLabors/ImageSharp/pull/1314). Having this available right out of the box in the `HighPerformance` package would be helpful in a number of similar situations, especially with `Memory<T>` APIs becoming more and more common across libraries now (as they've been out for a while). ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> This PR includes 4 new extensions for the `Memory<T>` and `ReadOnlyMemory<T>` types that enable the following: ```csharp // Cast between two Memory<T> instances... Memory<byte> memoryOfBytes = new byte[128].AsMemory(); Memory<float> memoryOfFloats = memoryOfBytes.Cast<byte, float>(); // ...any number of times is needed Memory<int> memoryOfInts = memoryOfFloats.Cast<float, int>(); Memory<byte> backToBytesMemory = memoryOfInts.Cast<int, byte>(); // Or just convert into bytes directly Memory<int> sourceAsInts = new int[128].AsMemory(); Memory<byte> sourceAsBytes = sourceAsInts.AsBytes(); // Want to get a stream from a string? Why not! 😄 using (Stream stream = "Hello world".AsMemory().AsBytes().AsStream()) { // Use the stream here, which reads *directly* from the string data! } ``` Here is the full list of the new APIs introduced in this PR: ```csharp namespace Microsoft.Toolkit.HighPerformance.Extensions { public static class MemoryExtensions { public static Memory<byte> AsBytes<T>(this Memory<T> memory) where T : unmanaged; public static Memory<TTo> Cast<TFrom, TTo>(this Memory<TFrom> memory) where TFrom : unmanaged where TTo : unmanaged; } public static class ReadOnlyMemoryExtensions { public static ReadOnlyMemory<byte> AsBytes<T>(this ReadOnlyMemory<T> memory) where T : unmanaged; public static ReadOnlyMemory<TTo> Cast<TFrom, TTo>(this ReadOnlyMemory<TFrom> memory) where TFrom : unmanaged where TTo : unmanaged; } } ``` ## Notes Marking as draft as this is still being worked on, but feedbacks and reviews are welcome! 😄 ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
c493caeda0 |
Added [Memory|Span]Owner<T>.DangerousGetArray (#3530)
## PR Type
What kind of change does this PR introduce?
- Feature
<!-- - Code style update (formatting) -->
<!-- - Refactoring (no functional changes, no api changes) -->
<!-- - Build or CI related changes -->
<!-- - Documentation content changes -->
<!-- - Sample app changes -->
<!-- - Other... Please describe: -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying, or link to a relevant issue. -->
There is currently no way to get the underlying `T[]` array from a `MemoryOwner<T>` or `SpanOwner<T>` instance without going through some hoops that are very inconvenient (and which are only possible for `MemoryOwner<T>`). Being able to use the array directly is necessary when working with some older APIs that don't offer a `Span<T>` or `Memory<T>` overload.
## What is the new behavior?
<!-- Describe how was this issue resolved or changed? -->
This PR introduces a new `DangerousGetArray` method that mirrors the `MemoryMarshal.TryGetArray` method and works on `MemoryOwner<T>` and `SpanOwner<T>` instances. I've removed the try pattern since here the types guarantee that the underlying memory store will always be an array. The methods are called `Dangerous___` because using the array is potentially dangerous in case a user keeps the array after disposing the original owner, as it means that that array might've been rented to some other consumer, so using it could lead to unexpected behavior. The methods are not inherently dangerous per se.
## API surface
```csharp
namespace Microsoft.Toolkit.HighPerformance.Buffers
{
public sealed class MemoryOwner<T>
{
public ArraySegment<T> DangerousGetArray();
}
public readonly ref struct SpanOwner<T>
{
public ArraySegment<T> DangerousGetArray();
}
}
```
## Example usage
Suppose we have a `Person` class with `string Name`, `string Surname` and `int Age` properties, and we want to calculate an MD5 hash with the current state of the class. This was originally asked by a user in the C# Discord server ([here](https://discordapp.com/channels/143867839282020352/312132327348240384/766694351383560205)).
```csharp
public static string GetMD5Hash(Person person)
{
using var buffer = new ArrayPoolBufferWriter<byte>();
buffer.Write<char>(person.Name);
buffer.Write<char>(person.Surname);
buffer.Write(person.Age);
using SpanOwner<byte> hash = SpanOwner<byte>.Allocate(16);
using var md5 = MD5.Create();
md5.TryComputeHash(buffer.WrittenSpan, hash.Span, out _);
return BitConverter.ToString(hash.DangerousGetArray().Array!, 0, 16);
}
```
You can see how here we can leverage the new `DangerousGetArray` API to get the underlying array to use with the `BitConverter.ToString` API, which doesn't have an overload accepting a `ReadOnlySpan<byte>`. The same goes for many other existing APIs that only accept an array as input data instead of the new memory APIs.
## PR Checklist
Please check if your PR fulfills the following requirements:
- [X] Tested code with current [supported SDKs](../readme.md#supported)
- [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~
- [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~
- [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~
- [X] Tests for the changes have been added (for bug fixes / features) (if applicable)
- [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*)
- [X] Contains **NO** breaking changes
|
||
|
msftbot[bot]andGitHub
|
a1ea6b8766 |
Fixed ArrayPoolBufferWriter<T> repeated new[] allocations (#3524)
## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - Optimization <!-- - Bugfix --> <!-- - Feature --> <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> The `ArrayPoolBufferWriter<T>` uses the given `ArrayPool<T>` instance to resize its internal buffer when needed, which only works as expected when the array itself is small. The issue is that the `ArrayPool<T>.Shared` instance has an internal threshold set to `1024 * 1024`, over which it just allocates new arrays every time to avoid keeping very large arrays alive for a long time. That is perfectly fine, except for one little detail: once you get past that threshold, `ArrayPool<T>.Shared` **stops rounding up the requested size**. It instead returns an array with `new[]` of **exactly the requested size**, which absolutely kills the performance when used in a writer type like `ArrayPoolBufferWriter<T>`: this means that as soon as we get past tha threshold, we'll basically end up resizing the whole array for every single new write operation, no matter how large it is. That's super bad for performance and memory usage 🥺 ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> The solution for this is pretty simple, this PR includes a simple check for the requested size, and if that's over `1024 * 1024` it just rounds that up to the closest power of 2, so that the array size will effectively just keep being multiplied by 2 every time. This has a **huge** performance impact when eg. trying to use the `ArrayPoolBufferWriter<T>` class to write a 10MB buffer, 8KB at a time: | Method | Mean | Error | StdDev | Ratio | Gen 0 | Gen 1 | Gen 2 | Allocated | |-------------------------- |-------------:|-----------:|-----------:|------:|------------:|------------:|------------:|-----------:| | Before | 1,380.236 ms | 19.9806 ms | 17.7122 ms | 1.000 | 355000.0000 | 355000.0000 | 355000.0000 | 5754.44 MB | | After | **8.820 ms** | 0.1757 ms | 0.4838 ms | **0.006** | 640.6250 | 640.6250 | 640.6250 | **30 MB** | In this simple benchmark alone, the updated version is **156x** faster and uses **190x less memory** 😄 Of course, results will vary a lot on the specific workload, but you can imagine the impact being even more dramatic when working with larger buffers, or with less items being written at any given time. With this change in general, users will not have to worry about the size of the data being written, and the class will automatically use the right approach in all cases. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
40672bb264 |
[Feature] Microsoft.Toolkit.Mvvm package (Preview 4) (#3527)
## Follow up to #3428 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> This PR is for tracking all changes/fixes/improvements to the `Microsoft.Toolkit.Mvvm` package following the Preview 3. <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - Feature - Improvements <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## Overview This PR is used to track and implement new features and tweaks for the `Microsoft.Toolkit.Mvvm` package. See the linked issue for more info, and for a full list of changes included in this PR. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
7e252d4d58 |
Refactoring with .NET 5 Unsafe APIs (#3510)
## Close #3509 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - Refactoring (no functional changes, no api changes) <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> There are a number of usages of `Unsafe.AsRef<T>(null)` and similar that are verbose. ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> These occurrences are replaced using the new `Unsafe.NullRef<T>()` and `Unsafe.IsNullRef<T>(...)` APIs. ## Notes Leaving this as draft as the new `System.Runtime.CompilerServices.Unsafe` package is still in release candidate. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
7c98feab00 |
Add ColorPickerButton (#3379)
# Add ColorPickerButton to the Toolkit Closes #3363 ## PR Type What kind of change does this PR introduce? Feature Documentation content changes Sample app changes ## What is the current behavior? The toolkit, and WinUI/UWP, has no flyout ColorPicker. The color picker that currently exists is a large canvas-type control (that is incorrectly named). This existing control has lots of usability concerns discussed in #3363 and the WinUI repository. ## What is the new behavior? A brand-new control is added to allow selecting and editing a color within a flyout. The selected color is always visible in the content area of a drop-down button as a preview.  The new properties for this picker are below. Note that these are purposely name 'CustomPalette...' instead of 'Palette...' as multiple palettes may be supported in the future (windows colors, recent colors, custom palette all in different sections visible at the same time). ```csharp /// <summary> /// Gets the list of custom palette colors. /// </summary> public ObservableCollection<Windows.UI.Color> CustomPaletteColors { get; } /// <summary> /// Gets or sets the number of colors in each row (section) of the custom color palette. /// A section is the number of columns within an entire row in the palette. /// Within a standard palette, rows are shades and columns are unique colors. /// </summary> public int CustomPaletteColumns { get; set; } /// <summary> /// Gets or sets a custom IColorPalette . /// This will automatically set <see cref="CustomPaletteColors"/> and <see cref="CustomPaletteSectionCount"/> /// overwriting any existing values. /// </summary> public IColorPalette CustomPalette { get; set; } /// <summary> /// Gets or sets a value indicating whether the color palette is visible. /// </summary> public bool IsColorPaletteVisible { get; set; } ``` Making all of this easier is a new IColorPalette interface. Any class can implement this interface to provide a custom color palette such as windows colors (the default), RYB colors, Flat UI colors, etc. Colors could also be algorithmically generated. ```csharp /// <summary> /// Interface to define a color palette. /// </summary> public interface IColorPalette { /// <summary> /// Gets the total number of colors in this palette. /// A color is not necessarily a single value and may be composed of several shades. /// </summary> int ColorCount { get; } /// <summary> /// Gets the total number of shades for each color in this palette. /// Shades are usually a variation of the color lightening or darkening it. /// </summary> int ShadeCount { get; } /// <summary> /// Gets a color in the palette by index. /// </summary> /// <param name="colorIndex">The index of the color in the palette. /// The index must be between zero and <see cref="ColorCount"/>.</param> /// <param name="shadeIndex">The index of the color shade in the palette. /// The index must be between zero and <see cref="ShadeCount"/>.</param> /// <returns>The color at the specified index or an exception.</returns> Color GetColor(int colorIndex, int shadeIndex); } ``` ## PR Checklist Please check if your PR fulfills the following requirements: - [x] Tested code with current [supported SDKs](../readme.md#supported) - [ ] Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link --> - [x] Sample in sample app has been added / updated (for bug fixes / features) - [x] Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets) - [ ] Tests for the changes have been added (for bug fixes / features) (if applicable) - [x] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [x] Contains **NO** breaking changes ## Other information **Control** * [x] Ensure the name ColorPickerButton is accepted * [x] Rename ColorPickerSlider to ColorPickerButtonSlider. ColorPickerSlider is already used by WinUI. * [x] Implement all accessibility functionality. Check tab ordering. * [x] This control originally used NumberBoxes for channel numerical input. Complete porting this functionality over to TextBoxes as the Toolkit does not have a dependency on WinUI. * [x] Support all visual state groups in the original ColorPicker. Connect all functionality * [x] Test changing all ColorPicker properties. Determine which ones make sense to ignore * [x] Trim displayed hex if alpha is not enabled * [x] ~~Switch to radio buttons to switch between RGB/HSV representation. A ComboBox within a Flyout is generally bad practice and is also limited by some bugs in UWP (#1467).~~ * [x] Switch to ToggleButton instead of RadioButton for RGB/HSV representation. Radio buttons don't work in flyouts and controls well due to UWP bugs. ToggleButtons may also visually look better. The design follows a 'segmented control' concept discussed here: https://github.com/microsoft/microsoft-ui-xaml/issues/2310 * [x] Switch the default color palette to be the windows colors (if possible) * [x] Align formatting to the toolkit conventions * [x] Handle CornerRadius in the template. Conditional XAML? Check how other controls do this. * [x] Rename 'CustomPaletteSectionCount' to ~~'CustomPaletteWrapCount'~~ or 'CustomPaletteColumns' like UniformGrid * [x] Update selected palette color data template to provide correct contrast of the border with the selected color ~~to match with windows settings app (check mark overlay)~~ The check mark is not included as the size of swatches in the palette could be smaller than the check mark itself. * [x] Rename 'CustomPaletteColumns' to 'CustomPaletteColumnCount' * [ ] Treat negative/zero numbers in CustomPaletteColumnCount as 'auto' and automatically calculate a good column count to keep rows/columns even. Set the default of this property to 0 'auto'. * [x] Improve spacing above/below channel sliders -- try 24px (2 x 12px) * [ ] Move localizable strings into resources * [x] ~Do not show the color (set the preview border visibility to collapsed) while the control is initializing. This prevents the default color from briefly appearing during initial load. Instead, the background will just show through.~ * [x] Do not change the saturation and value in the hue slider background. Keep SV at maximum. This allows the hue to always be clear to the user and is in line with other implementations (like in Inkscape). * [x] Rename `WindowsColorPalette` to `FluentColorPalette` * [x] Show palette color display name in a tooltip * [x] Use the WinUI algorithm for light/dark color switching * [x] Each tab should have independent visibility using IsColorPaletteVisible (new), IsColorSpectrumVisible (existing) and IsColorChannelTextInputVisible (repurposed to mean the entire tab). The tabs still visible should take up available space remaining. With only one tab visible the tab header should disappear. **Code Review** 1. [x] The mini-palette and color preview will be all one color when the selected color is black or white. The calculated accent colors will not change and pressing them will not change the selected color. * Requires feedback from Microsoft on how the accent colors are calculated in Windows * It is possible to specially handle when the color is as max/min value (black or white) at least the two accent colors to the left/right could be different shades of gray. 1. [x] The mini-palette accent colors are destructive. Pressing back and forward by 1 will not restore the original color. * Again, requires feedback from Microsoft on how the accent colors are calculated in Windows. * Due to perceptual adjustments it's likely this will always be destructive. 1. [x] The third dimension slider in the spectrum tab will vary the other dimensions in the spectrum. This results in the spectrum cursor jumping around as the slider value changes. This might be related to HSV/RGB conversion but needs to be investigated. 1. [x] Adjust the design of the sample app page to move the ColorPickerButton closer to the description. 1. [x] Check if a ColorToDisplayName converter already exists. Consider adding control specific converters to their own sub-namespace. 1. [x] The ColorPickerButton will derive from DropDownButton and have a ColorPicker property. Dependent on #3440 1. [x] The ColorPicker will have the same new style as the ColorPickerButton flyout. While it's a new concept to have tabs in a panel-type control, this is considered acceptable. 1. [x] Merge @michael-hawker branch into this one when given the thumb's up. Both controls will be in the same directory. 1. [x] Remove conditional XAML for corner radius after WinUI 3.0. Conditional XAML doesn't work correctly in resource dictionaries and with setters. See https://github.com/microsoft/microsoft-ui-xaml/issues/2556, fixed with #3440 1. [ ] All slider rendering will be broken out and put into a new ColorPickerSlider. This should simplify code-behind and the default template. 1. [x] The Pivot tab width and show/hide of tabs will be controlled in code-behind. use of the pivot itself is somewhat dependent on issues with touch. The pivot, or switching to a new control, will not hold the release. 1. [ ] Sliders should vary only 1-channel and keep the other channels at maximum. This ensures the gradient always makes sense and never becomes fully black/white/transparent. This could also be made a configuration of the ColorPickerSlider control. Edit: This does need to be configurable as it's only required in HSV mode. 1. [ ] Add color history palette to the sample app **Other** * [x] Complete integration with the sample app. Add XAML to dynamically change the control. * [ ] Complete documentation of the control **Future** These changes should be considered for future versions of the control. They are recorded here for lack of a better location. * [ ] The mini selected color palette may follow the Windows accent color lighter/darker shades algorithm. However, the implementation of this algorithm is currently unknown. This algorithm may be in the XAML fluent theme editor: https://github.com/microsoft/fluent-xaml-theme-editor * [ ] Switch back to NumberBox for all color channel numerical input. This will require WinUI 3.0 and the corresponding release of the toolkit. When https://github.com/microsoft/microsoft-ui-xaml/issues/2757 is implemented, also use NumberBox for hex color input. * [ ] ~Remove the custom 'ColorPickerButtonSlider' after switch to WinUI 3.0. This assumes there is no additional control-specific code at that point. (It currently exists just to work-around UWP bugs).~ This should be turned into it's own full primitive control. * [ ] Update ColorSpectrum_GotFocus event handler (instructions are within code) after/if ColorSpectrum bugs are fixed (likely after WinUI 3.0 * [ ] Use Color.IsEmpty if https://github.com/microsoft/microsoft-ui-xaml/issues/2826 is implemented * [ ] ~Ensure PivotItems are properly removed once/if https://github.com/microsoft/microsoft-ui-xaml/issues/2952 is closed.~ |
||
|
msftbot[bot]andGitHub
|
a950ab0d31 |
Parameterless ThrowHelper APIs (#3550)
<!-- 🚨 Please Do Not skip any instructions and information mentioned below as they are all required and essential to evaluate and test the PR. By fulfilling all the required information you will be able to reduce the volume of questions and most likely help merge the PR faster 🚨 --> ## Follow up for #3346 and #3455 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> <!-- - Bugfix --> - Feature <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> The `ThrowHelper` class exposes static throw-helper APIs that mirror the existing constructor for all the supported exception types. In the previous PRs though I had missed the parameterless constructors, so there were no APIs for that in the `ThrowHelper` class. ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> `ThrowHelper` now exposes a parameterless overload for all the supported exception types that are exposed. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
453feb11a4 |
Deprecated 2D array extensions from Microsoft.Toolkit (#3444)
## Part of #3062, related to #3435 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - Optimization - Deprecation <!-- - Bugfix --> <!-- - Feature --> <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> The `Microsoft.Toolkit` package has a number of extensions for 2D arrays that are inefficient (they're both a bit slow and causing unnecessary memory allocations) and replaced by equivalent APIs in the `Microsoft.Toolkit.HighPerformance` package. https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/30452cf0bbf627f12825cf50bbd31b0e526b9abe/Microsoft.Toolkit/Extensions/ArrayExtensions.cs#L27 https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/30452cf0bbf627f12825cf50bbd31b0e526b9abe/Microsoft.Toolkit/Extensions/ArrayExtensions.cs#L48 https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/30452cf0bbf627f12825cf50bbd31b0e526b9abe/Microsoft.Toolkit/Extensions/ArrayExtensions.cs#L68 ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> This PR makes these APIs obsolete, and also includes a number of small optimizations to existing code that was added during the refactoring to remove dependencies on these APIs, so that it'll be possible to remove them in the future with no issues. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link --> - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
dc2e32a6ab |
Fixed MemoryStream seek to end validation (#3543)
<!-- 🚨 Please Do Not skip any instructions and information mentioned below as they are all required and essential to evaluate and test the PR. By fulfilling all the required information you will be able to reduce the volume of questions and most likely help merge the PR faster 🚨 --> ## Fixes https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3536 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - Bugfix <!-- - Feature --> <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> Seeking to the end of a `Stream` from a `Memory<T>` or other types in the `HighPerformance` package throws an exception. ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> Seeking to the end of the stream is now allowed. This is consistent to other `Stream` types in the BCL. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
91bc478c9b |
Mutable and subclassable version of ObservableGroup (#3526)
## Fixes #3519 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> Removes two restrictions from `ObservableGroup` to make it usable in more situations. In my case, I wanted to be able to rename the groups (for this I needed a mutable key), and I wanted to add properties on the group level (I needed to unseal it) - Removes the immutable restriction on the `Key` property and makes the `Key` property observable. - Removes the `sealed` keyword from `ObservableGroup` ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> <!-- - Bugfix --> - Feature <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> `ObservableGroup` has an immutable `Key` property `ObservableGroup` is not inheritable ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> `ObservableGroup` has a mutable `Key` property `ObservableGroup` is inheritable ## PR Checklist Please check if your PR fulfills the following requirements: - [ ] Tested code with current [supported SDKs](../readme.md#supported) - [x] Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: https://github.com/MicrosoftDocs/WindowsCommunityToolkitDocs/pull/394 - [x] Sample in sample app has been added / updated (for bug fixes / features) --> _no update needed_ - [x] Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets) --> _not applicable_ - [x] Tests for the changes have been added (for bug fixes / features) (if applicable) --> _not applicable_ - [x] Header has been added to all new source files (run *build/UpdateHeaders.bat*) --> _not applicable_ - [ ] Contains **NO** breaking changes <!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below. Please note that breaking changes are likely to be rejected. --> ## Other information |
||
|
msftbot[bot]andGitHub
|
f2969ebb29 |
Performance improvement in MemoryStream (#3477)
## PR type: What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - Performance improvement <!-- - Bugfix --> <!-- - Feature --> <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> The `MemoryStream` type wraps a `Memory<byte>` instance, so every time a read/write operation needs to be performed, it will need to use `Memory<T>.Span`, which is relatively expensive to invoke, as it needs to handle multiple possible sources of data. We can use generic types and the value delegate trick (constrained generic struct + interface) to optimize this away. ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> We now use a `MemoryStream<TSource>` type (which is internal anyway) and have a bunch of `IMemorySource` types specifically supporting `byte[]` and `MemoryManager<byte>` sources with additional optimizations wherever possible. Also, just using this already removes all the overhead of dynamically creating a `Span<T>` from the wrapped `Memory<T>` instance. Here's a benchmark I put together to show the before/after:  The benchmark consists of writing 1024 times a 1024 bytes buffer to a target `Stream` instance. The new `MemoryStream<TSource>` version is almost 25% faster just thanks to this change 🚀 ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs).~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
188b906ee7 |
Shameful rename of [IsNullOr]WhiteSpace Guard APIs (#3515)
## Overview Some `Guard` APIs were incorrectly using the wrong capitalization for the `WhiteSpace` part, not following the same structure of the actual APIs in the BCL (eg. `string.IsNullOrWhiteSpace`). This PR deprecates them and adds new APIs with the right name. ...I'm sorry 😅 <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - API rename - API deprecation ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [ ] ~~Tests for the changes have been added (for bug fixes / features) (if applicable)~~ - [ ] ~~Header has been added to all new source files (run *build/UpdateHeaders.bat*)~~ - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
688032dc13 |
Support for nested/pointer/byref types for Type.ToTypeString() (#3468)
## Follow up for #3131 <!-- Add a brief overview here of the feature/bug & fix. --> The `Type.ToTypeString()` introduced with the `Guard` API lacks support for nested types, pointer types and byref types. ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> <!-- - Bugfix --> <!-- - Feature --> <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> The extension doesn't work properly when used with nested, pointer or byref types. It will either crash or just return the wrong formatted type (eg. the declaring type instead of the nested type). ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> The extension now works correctly with all sorts of nested, pointer and byref types 🎉 ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs).~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
3a581619e0 |
Memory usage improvements/optimizations to Messenger (#3424)
## Follow up for #3230, part of #3428 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - Optimization <!-- - Bugfix --> <!-- - Feature --> <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## Overview This PR includes two main parts: an improvement for the memory pooling buffers, and a refactor of how delegates are registered for message handlers. This last part allows to completely remove local closures for message handlers 🚀 ### Memory pooling improvements We're using memory pooling (by relying on the `ArrayPool<T>` APIs) in the `Messenger` class to achieve an amortized 0-allocation execution of the `Send` method in particular (`UnregisterAll` uses this too). We have code like this: https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/4890b5ed17995654b6f710b7949d1786648317a4/Microsoft.Toolkit.Mvvm/Messaging/Messenger.cs#L250 https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/4890b5ed17995654b6f710b7949d1786648317a4/Microsoft.Toolkit.Mvvm/Messaging/Messenger.cs#L401 This works just fine, and we do get the 0-allocation after the initial first invocation where we rent the buffer. There are two downsides here though: - In the `Send` method, we rent an `Action<TMessage>` buffer, so we'll rent a different buffer for every message type - Given that these types are either internal or not likely to ever by used by consumers of the library, all these rented buffers would only ever by used by the `Messenger` class itself, and the consumers would not be able to reuse them on their own. Neither of these points is a big deal and the current implementation is fine, but I think we can do better 😄 **Idea:** let's leverage the fact that arrays are covariant, and only use a single type to solve both problems, like so: ```csharp object[] maps = ArrayPool<object>.Shared.Rent(count); // Do stuff, example: foreach (object obj in maps) { var myActualItem = (SomeFancyTypePossiblyInternal)obj; // Do stuff with the item... } ``` This both allows us to just use `object[]` arrays, which both reduces the total number of rented arrays (as we can reuse them for different message types), and also makes it so that these rented arrays might potentially also be reused by consumers of the library (should they ever need to pool `object[]` arrays), further reducing allocations 🚀 ## Benchmarks Here are some benchmarks comparing the `Messenger` from this PR with the one in the `Preview1`. ### Sending messages | Method | Categories | Mean | Error | StdDev | Ratio | Gen 0 | Gen 1 | Allocated | |--------- |----------------- |-------------:|----------:|----------:|------:|------:|------:|----------:| | Old_Send | DefaultChannel | 161.7 us | 1.52 us | 1.43 us | 1.00 | - | - | - | | **New_Send** | DefaultChannel | **153.9 us** | 1.62 us | 1.43 us | 0.95 | - | - | - | | | | | | | | | | | | Old_Send | MultipleChannels | 148,668.7 us | 886.65 us | 785.99 us | 1.00 | - | - | 336 B | | **New_Send** | MultipleChannels | **138,825.0 us** | 797.61 us | 746.08 us | 0.93 | - | - | 336 B | Performance when sending message is slightly faster than before. Worst case scenario, it's not any slower. ### Registering messages | Method | Mean | Error | StdDev | Ratio | Gen 0 | Gen 1 | Allocated | |------------- |---------:|--------:|--------:|------:|---------:|--------:|----------:| | Old_Register | 443.6 us | 1.73 us | 1.53 us | 1.00 | 113.7695 | 25.3906 | 581.53 KB | | **New_Register** | **386.1 us** | 2.47 us | 2.31 us | 0.87 | 82.5195 | 4.3945 | **381.53 KB** | The new version is **13%** faster when registering messages, and uses **34%** less memory 🚀 ### Enabled recipient type-specific handlers One major annoyance for users working with manually registered handlers was the fact that type information was lost. As in, recipients were registered as just `object` instances, as it was necessary to cast them in the handler every time. This PR also changes this by adding support for a type parameter to specify the recipient type. This enables the following change (which is totally optional anyway, you can still just use `object` if you want): ```csharp // Before Messenger.Register<MyMessage>(this, (s, m) => ((MyViewModel)s).SomeMethod(m)); // After Messenger.Register<MyViewModel, MyMessage>(this, (s, m) => s.SomeMethod(m)); ``` ### Removed local closures The original implementation used `Action<T>` for handlers, which caused closures to be constantly created whenever the users wanted to access any local member on the registered recipient. This was because the recipient itself needed to be captured too to be accessed from the handlers. This detail also made it more difficult for other devs to implement `IMessenger` if they wanted to use a weak reference system. I've replaced that handler type with a custom delegate, called `MessageHandler`: https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/204ee41ad285bb960876a303ce83d1a5bc454e1a/Microsoft.Toolkit.Mvvm/Messaging/IMessenger.cs#L10-L22 This delegate also receives the target recipient as input, which allows developers to just use that to access local members, without the need to create closures. The handlers are now essentially static, so the C# compiler can cache the whole delegate too. This is especially useful for the `IRecipient<TMessage>` pattern, as that was previously creating unnecessary closures when registering handlers - that's completely gone now and delegates are cached there as well 🎉 For instance, you can see that here: https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/204ee41ad285bb960876a303ce83d1a5bc454e1a/Microsoft.Toolkit.Mvvm/Messaging/IMessengerExtensions.cs#L175-L179 We're now using that cached static delegate (will be able to also explicitly mark that as static when C# 9 lands, but it already is) instead of the method group syntax on `recipient.Receive`, which allocated a closure for each invocation. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
0a6b93b91c |
HighPerformance package improvements (#3351)
## Improvements for `Microsoft.Toolkit.HighPerformance`
<!-- Add a brief overview here of the feature/bug & fix. -->
## PR Type
What kind of change does this PR introduce?
<!-- Please uncomment one or more that apply to this PR. -->
<!-- - Bugfix -->
- Feature
- Optimization
<!-- - Code style update (formatting) -->
<!-- - Refactoring (no functional changes, no api changes) -->
<!-- - Build or CI related changes -->
<!-- - Documentation content changes -->
<!-- - Sample app changes -->
<!-- - Other... Please describe: -->
## Changes and fixes
<!-- Describe how was this issue resolved or changed? -->
- Improved codegen for exception throw methods
- Added custom `ArrayPool<T>` overloads to `MemoryOwner<T>`
## PR Checklist
Please check if your PR fulfills the following requirements:
- [X] Tested code with current [supported SDKs](../readme.md#supported)
- [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~
- [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~
- [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~
- [ ] Tests for the changes have been added (for bug fixes / features) (if applicable)
- [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*)
- [X] Contains **NO** breaking changes
<!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below.
Please note that breaking changes are likely to be rejected. -->
|
||
|
msftbot[bot]andGitHub
|
ff29d52998 |
New BitHelper APIs (#3362)
## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> <!-- - Bugfix --> - Feature <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> This PR adds a few new APIs to the `BitHelper` class. Follow up from this original thread on Twitter: https://twitter.com/SergioPedri/status/1275556765363568641. These are the new APIs being included in this PR: ```csharp namespace Microsoft.Toolkit.HighPerformance.Helpers { public static class BitHelper { public static bool HasZeroByte(uint value); public static bool HasZeroByte(ulong value); public static bool HasByteEqualTo(uint value, byte target); public static bool HasByteEqualTo(ulong value, byte target); } } ``` ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes <!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below. Please note that breaking changes are likely to be rejected. --> |
||
|
msftbot[bot]andGitHub
|
49eb987ac9 |
Removed Deprecated for 7.0 (#3435)
Removed: * Major components: * TabView/TabViewItem * HeaderedTextBlock * FacebookService and Microsoft.Toolkit.Uwp.Services project * RSS Parsers * Smaller methods: * StringExtensions.ToSafeString * LinkedIn, Twitter and Weibo sync Logout methods. * ConnectedAnimations.SetListDataItemForNextConnectedAnnimation * TileControl.IsCompositionSupported * NotifyTaskCompletion * Singleton This is still missing the update on the docs repo. ## Contributes towards #3062 ## Fixes #3396 ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> <!-- - Bugfix --> <!-- - Feature --> <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> - Other... Please describe: Removing dead code. ## What is the current behavior? Obsolete classes marked as obsolete, but still exist in code. ## What is the new behavior? Some classes/methods marked as obsolete are now removed from code. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link --> - [X] Sample in sample app has been added / updated (for bug fixes / features) - [ ] Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets) - [ ] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [ ] Contains **NO** breaking changes This PR IS a breaking change, as instead of just providing a warning, any developers that uses the dead code will now get missing method/class exceptions. |
||
|
msftbot[bot]andGitHub
|
3ab0cb8697 |
Generic throw helper (#3455)
## Closes #3454 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> <!-- - Bugfix --> - Feature <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> New generic overloads for all `ThrowHelper` APIs, see linked issue for more details. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link --> - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
67e40853c2 |
Massive amount of spelling fixes (#3434)
## Fixes #
After the last PR for minor spelling issues, I ran a spelling check on the rest of the code and found many places to fix typos. I am looking into a way to automate this into the PR checks, but this will take some effort due to needing many items added to the 'ignore' list.
## PR Type
What kind of change does this PR introduce?
- Documentation content changes
- Sample app changes
## PR Checklist
Please check if your PR fulfills the following requirements:
- [ ] Tested code with current [supported SDKs](../readme.md#supported)
- [ ] Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->
- [ ] Sample in sample app has been added / updated (for bug fixes / features)
- [ ] Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)
- [ ] Tests for the changes have been added (for bug fixes / features) (if applicable)
- [ ] Header has been added to all new source files (run *build/UpdateHeaders.bat*)
- [X] Contains **NO** breaking changes
<!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below.
Please note that breaking changes are likely to be rejected. -->
## Other information
|
||
|
msftbot[bot]andGitHub
|
a5017913b5 |
Minor codegen improvements in Microsoft.Toolkit.Collections APIs (#3439)
Quick-fix PR to remove an unnecessary `[MethodImpl(MethodImplOptions.NoInlining)]` attribute from a throw helper method. That attribute caused the JIT not to see the throw in the body, resulting in the caller branch assuming the forward path being taken (the faulty one). This produced worse codegen, as the non-faulting path was always forced to have an extra jump ahead. Also did another small codegen tweak and added a more detailed exception message for users. ## Leftover fix from #3260 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> <!-- - Bugfix --> <!-- - Feature --> - Optimization <!-- - Code style update (formatting) --> <!-- - Refactoring (no functional changes, no api changes) --> <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying, or link to a relevant issue. --> Unoptimal codegen for this throw helper method: https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/30452cf0bbf627f12825cf50bbd31b0e526b9abe/Microsoft.Toolkit/Collections/ObservableGroupedCollectionExtensions.cs#L447-L451 ## What is the new behavior? <!-- Describe how was this issue resolved or changed? --> The JIT is now properly handling calls to this method. ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
41343d8767 |
Microsoft.Toolkit.Mvvm package (part 2) (#3413)
## Follow up to #3229 <!-- Add the relevant issue number after the "#" mentioned above (for ex: Fixes #1234) which will automatically close the issue once the PR is merged. --> ### NOTE Marking this not as a draft so that the CI will run, but added the "DO NOT MERGE ⚠" tag as we might come up with further improvements to add to this PR before actually deciding to merge this and finalize the package. <!-- Add a brief overview here of the feature/bug & fix. --> ## PR Type What kind of change does this PR introduce? <!-- Please uncomment one or more that apply to this PR. --> - Bugfix - Feature - Refactoring (no functional changes, no api changes) <!-- - Build or CI related changes --> <!-- - Documentation content changes --> <!-- - Sample app changes --> <!-- - Other... Please describe: --> ## Notable changes <!-- Describe how was this issue resolved or changed? --> This PR includes some refinements and tweaks to the `Microsoft.Toolkit.Mvvm` package, like: - Added new `ObservableRecipient.SetProperty` overloads with `Expression<Func<T>>` and `bool broadcast` params - Fixed a possible bug in `Messenger.Type2.Equals` (just to be extra sure) - Improved codegen for `ObservableRecipient.Set<T>(ref T, T, string)` (missing `EqualityComparer<T>.Default.Equals` inlining) ## PR Checklist Please check if your PR fulfills the following requirements: - [X] Tested code with current [supported SDKs](../readme.md#supported) - [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~ - [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~ - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~ - [X] Tests for the changes have been added (for bug fixes / features) (if applicable) - [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*) - [X] Contains **NO** breaking changes |
||
|
msftbot[bot]andGitHub
|
f0256d58ab |
Fixed local errors in .NET Core 2.1 unit tests (#3365)
## PR Type
What kind of change does this PR introduce?
<!-- Please uncomment one or more that apply to this PR. -->
- Bugfix
- Build or CI related changes
<!-- - Documentation content changes -->
<!-- - Sample app changes -->
<!-- - Other... Please describe: -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying, or link to a relevant issue. -->
Some .NET Core 2.1 unit tests for the base package fail when run locally.
## What is the new behavior?
<!-- Describe how was this issue resolved or changed? -->
All tests run correctly when executed locally.
## PR Checklist
Please check if your PR fulfills the following requirements:
- [X] Tested code with current [supported SDKs](../readme.md#supported)
- [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~
- [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~
- [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~
- [X] Tests for the changes have been added (for bug fixes / features) (if applicable)
- [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*)
- [X] Contains **NO** breaking changes
<!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below.
Please note that breaking changes are likely to be rejected. -->
|
