fix(hotkeys): focus the buried dialog and say why the shortcut did nothing
SetForegroundWindow is refused when the hotkey comes from another application, so the dialog was raised but never focused; ForceForegroundWindow is now exposed by PM.Bridge for that. The explanation goes through a tray balloon because our window is disabled and behind the dialog, where no toast would be seen.
This commit is contained in:
@@ -272,6 +272,12 @@ type
|
||||
read FOnQuickSearchHotkey write FOnQuickSearchHotkey;
|
||||
end;
|
||||
|
||||
// Bring a window to the foreground despite the Win10/11 anti-focus-stealing
|
||||
// rules (AttachThreadInput + poll). Exposed because the host needs it to raise
|
||||
// a native dialog of ours that got buried — plain SetForegroundWindow is
|
||||
// refused when we are not the foreground process.
|
||||
function ForceForegroundWindow(ATargetHwnd: HWND): Boolean;
|
||||
|
||||
implementation
|
||||
|
||||
uses
|
||||
@@ -307,7 +313,6 @@ function UnhookWinEvent(hWinEventHook: THandle): BOOL;
|
||||
// Defined further down but needed by the constructor / MinimizeToTray.
|
||||
function IsOwnProcessWindow(AHwnd: HWND): Boolean; forward;
|
||||
function IsShellWindow(AHwnd: HWND): Boolean; forward;
|
||||
function ForceForegroundWindow(ATargetHwnd: HWND): Boolean; forward;
|
||||
procedure ForegroundEventProc(hWinEventHook: THandle; AEvent: DWORD; AWnd: HWND;
|
||||
idObject, idChild: LongInt; idEventThread, dwmsEventTime: DWORD); stdcall; forward;
|
||||
|
||||
|
||||
Reference in New Issue
Block a user