It seems that secondary taskbars handle try button positioning
correctly. So there is no need for this workaround.
Original change was introduced in 674a486 due to #1232 issue.
Windows 11 22H2 introduced new touch-optimized taskbar for devices with
touch screen.
It seems that in this mode taskbar window size is bigger than actual
taskbar on screen. There is region defined for the window that covers
actually displayed portion of the window.
We should account for that region (if present) when obtaining taskbar
window dimensions.
More info about how to enable/disable touch taskbar:
https://www.elevenforum.com/t/turn-on-or-off-tablet-optimized-taskbar-in-windows-11.5133/
It may happen that during `InitStartMenuDLL` execution some component
posts a message that is then intercepted by (still active) `HookInject`
that will call `InitStartMenuDLL` again (and everything will repeat).
To prevent such endless recursion during initialization, we will make
sure that `InitStartMenuDLL` will be executed just once.
Shift Aero button slightly when it is positioned in corner of any
monitor (not just primary one).
Moreover this shift should be done only for top/bottom taskbar.
Windows 11 Insider builds started to register global shell hotkey for
Win key (and Ctrl+Esc) that are used to trigger start menu.
The problem is that it is not (easily) possible to intercept messages
about these hotkeys.
Thus we will unregister them during init and install hook that will
prevent their further registration.
Fixes#1165
- Taskbar is now handled by taskbar.dll, so we need to hook APIs there
- TaskList window (MSTaskListWClass) is not visible so we need to
hook messages of its parent TaskBand window (MSTaskSwWClass)
Fixes#1230
When taskbar is hidden its window is moved off the screen (except for
few pixels at border). It may happen that the taskbar window actually
spans to another monitor (though still not visible).
MonitorFromWindow API may thus return different monitor handle than the
one visible taskbar is on.
We will use GetTaskbarPosition function that correctly identifies taskbar's
monitor by checking rectangle of visible taskbar.
Fixes#908
- handling of `Taskbar alignment` setting (left/center)
- start menu position is based on position of start button
- mouse clicks to original button now work properly (without triggering original menu)
- custom button is properly positioned
- Win+X works properly
Items can be pinned to directories that require administative privileges
(such as Open-Shell's default installation directory), so long as users
take ownership of the pinned folder. Also adds a command to Open-Shell's
context menu that opens the current pinned folder.
Adds general support for directory-based settings by creating a new
setting type called TYPE_DIRECTORY which uses a new bool added to
BrowseLinkHelper, called bFoldersOnly. START_MENU_PINNED_ROOT
has been removed, and all instances of both it and BrowseLinkHelper
have been adjusted accordingly. To create your own directory-based
settings, use CSetting::TYPE_DIRECTORY. Empty directory paths are
reset to their default value as they can cause unexpected behavior.
`Open-Shell` hooks `SHFillRectClr` (ordinal 197) API from `shlwapi.dll`
in order to be able to customize taskbar.
The API is hooked even if taskbar customization is disabled in `Open-Shell` (default).
`WindowBlinds` hooks the same API so this is causing clashes between
both programs.
In fact `Open-Shell` hooks later which makes `WindowBlinds` hook to be
completely ignored.
The solution would be to hook only if taskbar customization is enabled.
This way `Open-Shell` should be more compatible with other customization
tools in default state.
Fixes#433.
In several cases we don't want menu(s) to close when an action on menu was
done. For example on drag-n-drop or menu item deletion (where confirmation
dialog is shown).
In such situations `s_bPreventClosing` was set to true (and then back to
false when closing was allowed again).
Though original code honored this variable only in certain situations and
typically (at least on Win10) menus were hidden/closed despite of it.
This patch changes the behavior and menus(s) are not closed when
`s_bPreventClosing` is set to true.
Basically now menu(s) stay visible until there is an action that changes
active window.
Following functionality was also removed because it is not needed now:
* CMenuContainer::HideTemp
* COwnerWindow::OnClear
WM_CLEAR was sent to the window only by already removed `HideTemp`
* Fix naming inconsistencies
'Menu' vs 'StartMenu'
* Installer: Remove Facebook link
* Installer: Remove PayPal donate remnants
* OpenShellReadme: Remove info about product version
