* move KeyboardShortcutManager, ValidationConverter and ViewState to Calculator
* remove dead code listed in #753
* remove Microsoft.UI.Xaml nuget package from CalcViewModel
* Make sure TitleBar takes into account the AOT mode change
* remove namespaces in cpp files
* code linting
* use macro for IsAlwaysOnTop and make IsAlwaysOnTop/DisplayNormalAlwaysOnTopOption read-only
* Fix FontWeight
* Fixed the WindowIdLog so that it is updated when a new WindowCreated event is fired
* Updated the windowidlog check in LogWindowCreated to use IsWindowIdInLog
Description of the changes:
Adjusted some of the values in .clang-format
Add clang-format-all.ps1
Fix path to .clang-format in Calculator.sln
How changes were validated:
Manual.
Fixes#202
This PR fixes code style for the project files.
The Problem
Different files in the project use different code style. That is not consistent and leads to harder maintenance of the project.
Description of the changes:
Have investigated and determined the most used code style across the given codebase
Have configured IDE and applied code style to all project files.
Have crafted clang-formatter config.
see https://clang.llvm.org/docs/ClangFormat.htmlhttps://clang.llvm.org/docs/ClangFormatStyleOptions.html
Some cases were fixed manually
How changes were validated:
manual/ad-hoc testing, automated testing
All tests pass as before because these are only code style changes.
Additional
Please review, and let me know if I have any mistake in the code style. In case of any mistake, I will change the configuration and re-apply it to the project.
Fixes#437.
Clicking on the same element in the hamburger view should re-open that view, like the menu items do
Description of the changes:
-Fixed the bug that was listed
How changes were validated:
-manual
Fixes#407 (partially) and #441
Description of the changes:
Remove TitleBarHelper and all <Border x:Name="CustomTitleBar" />
Let the system defines the draggable region
Centralize all events and functions associated to the title bar in a single control TitleBar instead of code splitted between MainPage/TitleBar/HistoryList/Memory.
Use the standard title bar when high contrast is activated instead of the custom one.
Modify the color of the title when the window doesn't have focus
Fix the right padding of the title bar with high contrast
How changes were validated:
Manually tested with LtR and RtL languages
Manually tested with high contrast
Tested when History and Memory flyout are opened
Initial PR for the feature/GraphingCalculator feature branch, part of #338.
The feature incorporates a proprietary Microsoft-owned graphing engine to drive graphing experiences in the Windows Calculator app. Due to the private nature of the graphing engine, the source available in the public repo will make use of a mock graphing engine. See README.md for more details.
This PR simply serves as a base for future feature development. As such, the PR will be immediately merged. Feedback on the content of this PR, and on the feature in general, is encouraged. If there is feedback related to the content of this specific PR, please leave comments on the PR page. We will address the comments in future PRs to the feature branch.
Before this change, the pchs for CalcViewModel and Calculator project referenced project headers. If those project headers (or any of their dependencies) were to change, then the pch would be recompiled, slowing local build times.
By removing references to project headers, the pch will be compiled once and is resilient to changes in the project. Now that project headers are explicit about their dependencies, when there is a change to a project header only the translation units referencing the modified header will need to be rebuilt.
- Manually tested by ensuring Calculator project builds locally.
@Microsoft/calculator-team
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.
