It was decided that the term 'Basic' is new and
has no established meaning in the software community.
So, Replacing the term 'Basic' with 'Common'. To disambiguate
multiple instances of 'Common', we use an already existing term
'Primitive' and we also append the Platform to which the package targets.
The package title doesn't follow a particular format and is not machine readable.
Thus, I propose the following format: "'Product' - 'Area' - 'Specifics' ('Source/Target')"
Remove redundant MSBuild logic
Consolidate common MSBuild logic
Reorder code-blocks for better readability
Fix-up comments and new-lines across project files
Improve support for Visual Studio 2022:
Since VS IDE 2022 (17.0) is 64-bit only, replace all 32-bit specific MSBuild properties with generic ones.
## 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.
<!-- 🚨 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
To make diff understandable through blame and across similar project files,
I have re-organized some lines in these project files. This also improves
readability. Previously, the focus is per-project file but now—to maintain
project logic across repos and several similar logic across project files,
new way of authoring project files is required.
This refactor is the start of it.
Format comments to be legible.
- Place comment start and end tags on a new line for multi-line comments.
- Have space between start and end tags in a single line comment.
Place comments where appropriate.
- If an entire block is common to the comment then place it above the block.
- Only place a comment near or after the block, if it refers exclusively.
Sources are not formatted!
Both VS IDE Code Clean-up and dotnet-format applies this formatting.
Only Code labels and Code within pre-processor blocks are affected.
The reason may be that the indentation wasn't read/written properly
by the formatter within or around those code blocks.
Both VS IDE Code Clean-up and dotnet-format applies this formatting.
Only Code labels and Code within pre-processor blocks are affected.
The reason may be that the indentation wasn't read/written properly
by the formatter within or around those code blocks.
NOTE: We could ignore this commit but we keep it as a reference point
for the VS C# Editor and .NET format team to diagnose this issue.
Update and follow EditorConfig settings.
BOM: Byte Order Mark (Used to identify UTF-8 encoding).
We don't need BOM specified as the latest editors can work without it.
Shane Weaver