* Fix HotkeyControl virtual key display
* A new interop project was setup to provide wrappers for C# projects
that want to access functionality in the common project.
* Add assembly info
* Remove WIN32 configurations
* sln: set output dir prefix to "modules\" for all modules
* sln: CopyToOutputDirectory only when necessary
* sln: intermediate dir for csprojs
* sln: intermediate dir for vcxprojs
* sln: add PT as runner project deps + remove nonexisting project confs
* sln: remove AnyCPU for win-app-driver project
* installer: extract version number into separate file and use it where possible
* MSIX: rename package to include version on CDPx
* installer: generate assembly info for FZ editor
* MSIX: inject correct version to appxmanifest
The cache was introduced to improve performance by not querying the
OS for the window process path every time we need to check if the window
is interesting to FancyZones. Since then other changes were made to the
the way we check the windows. Right now, the IsInterestingWindow function is
called when:
1) WinKey + arrows are used
2) window is started to be dragged
3) window is created
1) and 2) are initiated by the user, happen only once per interaction so
their performance impact can be dismissed. The 3) happens all the time
but for the most part the check for WS_CHILD or
GetAncestor(window, GA_ROOT) == window will filter those out. In the
end, only top-level windows will be queried for their path.
Removing the cache improves code readability and will make code
maintenance easier.
Unifies the way windows are considered "interesting" by FancyZone.
Berfore the change WinKey + arrows would use different method than
dragging. This PR makes both use the WinKey + arrows method.
Cleans up FancyZones Settings.cpp by removing m_configStrings variable.
Contrary to its name it was used to create color picker control.
Adds a multiline option to the text input to settings. Uses this to
provide the user with a way to exclude certain apps from snapping to
zones.
* Use DPIAware::DEFAULT_DPI
* Make runner DPI-unaware, since it doesn't need to use a Per Monitor V2 DPI.
* Programmatically enable "Per Monitor V2 DPI" for the runner proccess and use a separate DPI-unaware thread for the corresponding API calls
* Increase PCH memory limit for settings project
* Address review issues
* Draw zoneWindows properly scaled
