Commit Graph

13 Commits

Author SHA1 Message Date
Rudy Huyn
577aafb3f4 Migrate TraceLogger to runtime class (#772) 2019-11-05 18:59:24 -08:00
Rudy Huyn
e38e911bfa Modify how Calculator manages the visibility of the History button (#712)
* Modify how Calculator manages the History button + code cleaning

* remove extra include
2019-11-05 15:04:28 -08:00
Wei (Waley) Zhang
796d171960 Always-on-Top mode implemented (#579) 2019-07-30 17:53:39 -07:00
Stephanie Anderl
a6384269bc Updated Calculator diagnostic data collection per the specification (#572)
- Removed unneeded diagnostic events and code
- Added and consolidated events into the events defined in the spec
2019-07-17 18:09:39 -07:00
Matt Cooley
33b885ac17
Update to v142 build tools for Visual Studio 2019 (#548)
* Update to build tools v142
* Update official build pipelines to use VS2019
* Update instructions to suggest updating to VS2019
2019-06-24 16:38:45 -07:00
Mahdi Ghiasi
860d6d3eb2 Removed GroupName from JumpList so items can't be pinened or removed by user. (#499)
https://stackoverflow.com/a/39436591/942659
2019-05-13 17:01:28 -07:00
Daniel Belcher
9f01c8168b
Secondary formatting changes (#489)
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.
2019-05-02 16:48:33 -07:00
Oleg Abrazhaev
2826d37056 Fix the project code style, as it is not consistent. (#236)
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.html
https://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.
2019-05-02 11:59:19 -07:00
Rudy Huyn
bd04c92c1c Simplify title bar (#442)
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
2019-04-19 18:49:08 -07:00
Daniel Belcher
f210290ddc - Avoid referencing project headers from precompiled headers.
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
2019-02-14 18:20:25 -08:00
Pepe Rivera
531a8a1b7b Use TryResizeView to resize calc on first launch 2019-02-12 13:50:09 -08:00
Matt Cooley
4cadfb204d
Remove unused PLM code (#7)
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.
2019-02-01 15:15:48 -08:00
Howard Wolosky
c13b8a099e Hello GitHub 2019-01-28 16:24:37 -08:00