* Modify the height of RowDltrUnits when UnitConverter is in LandscapeLayout mode
* clean
* Use the same layout than the existing one while fixing the issue
* Refactor SupplementaryItemsControl to improve performance, not rely on parents and not force the parent element to be HorizonAlignment="stretch"
* take feedback into account
* add HorizontalNoOverflowStackPanel to vcproj.filters
* format conditionals
* replace max by std::max
The .resw files for all languages are expected to be checked into the repo (this used to not the the case). Let's remove the conditions in the project file which ignore them if they don't exist.
Additionally removes pseudo-loc resource references from the build as pseudo-loc resources aren't currently being generated.
Update the Microsoft.UI.Xaml NuGet package to a new version. The ARM64 framework package in 2.0.181018003.1 had entries missing from its manifest, so the classes in the package couldn't be activated.
The app currently logs diagnostic events to ETW in various places. If we add certain flags to those events, the data is eligible to be sent as telemetry. (Whether it actually gets sent is controlled outside of Calculator--for example, there are lots of checks at the system level to ensure privacy settings are honored.)
Currently we set the "eligible for telemetry" flags only in official builds, so no telemetry gets uploaded while the app is in development. We already have this set up for the main TraceLogging provider, but we also need to do this for the AppLifecycle performance logging.
Calculator (the main app project) depends on CalcManager, but only transitively: Calculator -> CalcViewModel -> CalcManager.
However, Calculator's project file currently has a direct dependency on CalcManager. Let's remove this to make it harder to accidentally introduce new dependencies between the layers.
Also cleaning up some commented-out directives in the CalcManager MSBuild file.
Remove LayoutAwarePage, SuspensionManager, and other suspend-resume handling code. SuspensionManager::SaveAsync and related methods weren't actually called anywhere. I didn't attempt to remove the serialize/deserialize code at the ViewModel layer, although much of that is likely not needed either.
We may decide we want to persist more state through a suspend-terminate-resume cycle (as the app might have done a long time ago). But if we decide we want that, we should not use a persistence mechanism that's closely coupled to frame navigation.
