fc587f31f9
We have found that a very common pattern for event handlers is
to capture a weak reference into a lambda, and in the event handler,
try to upgrade the weak reference to a strong one, and if so, do some work:
```cpp
widget.Closed([weak = get_weak(), data](auto&& sender, auto&& args)
{
if (auto strongThis = weak.get())
{
strongThis->do_all_the_things(data);
}
});
```
This commit extends the existing delegate constructors to permit a
`winrt::weak_ref` + lambda (or `std::weak_ptr` + lambda), which
simplifies the above to
```cpp
widget.Closed({ get_weak(), [this, data](auto&& sender, auto&& args)
{
do_all_the_things(data);
} });
```
## Implementation notes
A lambda and pointer to member function are hard to distinguish
in a template parameter list. In theory, we could use SFINAE or
partial specialization, but a simpler solution is to distinguish
the two inside the body of the constructor, via
`std::is_member_function_pointer_v`.
The `com_ptr` and `shared_ptr` variants of the test were
unified, since I found myself editing two nearly identical tests.
Fixes #1371
Co-authored-by: Jon Wiswall <jonwis@microsoft.com>
|
||
|---|---|---|
| .github | ||
| .pipelines | ||
| cppwinrt | ||
| docs | ||
| fast_fwd | ||
| mingw-support | ||
| natvis | ||
| nuget | ||
| prebuild | ||
| scratch | ||
| strings | ||
| test | ||
| vsix | ||
| .gitattributes | ||
| .gitignore | ||
| CMakeLists.txt | ||
| Directory.Build.Props | ||
| Directory.Build.Targets | ||
| LICENSE | ||
| README.md | ||
| build_nuget.cmd | ||
| build_prior_projection.cmd | ||
| build_projection.cmd | ||
| build_test_all.cmd | ||
| build_vsix.cmd | ||
| compile_tests.cmd | ||
| cppwinrt.sln | ||
| cross-mingw-toolchain.cmake | ||
| prepare_versionless_diffs.cmd | ||
| run_tests.cmd | ||
README.md
The C++/WinRT language projection
C++/WinRT is an entirely standard C++ language projection for Windows Runtime (WinRT) APIs, implemented as a header-file-based library, and designed to provide you with first-class access to the modern Windows API. With C++/WinRT, you can author and consume Windows Runtime APIs using any standards-compliant C++17 compiler.
- Documentation: https://aka.ms/cppwinrt
- NuGet package: http://aka.ms/cppwinrt/nuget
- Visual Studio extension: http://aka.ms/cppwinrt/vsix
- Wikipedia: https://en.wikipedia.org/wiki/C++/WinRT
Building C++/WinRT
Don't build C++/WinRT yourself - just download the latest version here: https://aka.ms/cppwinrt/nuget
Working on the compiler
If you really want to build it yourself, the simplest way to do so is to run the build_test_all.cmd script in the root directory. Developers needing to work on the C++/WinRT compiler itself should go through the following steps to arrive at an efficient inner loop:
- Open a dev command prompt pointing at the root of the repo.
- Open the
cppwinrt.slnsolution. - Choose a configuration (x64, x86, Release, Debug) and build projects as needed.
If you are working on an ARM64 or ARM specific issue from an x64 or x86 host, you will need to instead:
- Open the
cppwinrt.slnsolution - Build the x86 version of the "cppwinrt" project first
- Switch to your preferred configuration and build the test binaries and run them in your test environment
Comparing Outputs
Comparing the output of the prior release and your current changes will help show the impact of any updates. Starting from a dev command prompt at the root of the repo after following the above build instructions:
- Run
build_projection.cmdin the dev command prompt - Run
build_prior_projection.cmdin the dev command prompt as well - Run
prepare_versionless_diffs.cmdwhich removes version stamps on both current and prior projection - Use a directory-level differencing tool to compare
_build\$(arch)\$(flavor)\winrtand_reference\$(arch)\$(flavor)\winrt