TL;DR 本当に always-on-top にしたければ その実行ファイルは UIAccess の諸条件をクリアしなければいけない
AutoHotkey で Always-on-top に設定した Gui を作って表示したところ、 一部のウィンドウの上には表示されず、隠れてしまうという現象が起こった。 (その「一部」が UWP アプリであることは後から分かった。)
再現条件が複雑で、
と、かなり迷走した。
AHK に関係のない他のウィンドウで試してみると、
ということが分かった。
そんなことないと思う人は試してみてほしい。 複数モニタがあれば、一つに Windows 標準の「映画 & テレビ」で何かの動画をフルスクリーン再生して (一時停止しておいてもいい)、そこに別のモニタからのウィンドウを移動していくとどうなるか。
タスクマネージャーを移動していくと何事もなく重なるのに、 普通のウィンドウを重ねようとすると、途中までは下に潜りこむような感じで隠れていて、ある程度まで来ると「映画 & テレビ」の方が消えてしまうのだ。
タスクマネージャーはすごく変なアプリだから特別なのかもしれないと思ったが、AutoHotkey 付属の Window Spy もタスクマネージャーと同じ結果になった。というか AutoHotkey が C:\Program Files にインストールされているマシンでは AHK スクリプトから UWP の上に表示できるみたいだ。同じ AHK スクリプトを実行して UWP に隠れてしまう方のマシンには AutoHotkey をインストールしておらず、zip を展開した状態で使っていた。
ここに来てやっと分かった。Ahk2Exe してあるかどうかというより、UIAccess 権限があるかどうかが問題だったのだ。
それまで権限の問題と思えなかった理由は、「管理者として実行」をしても現象が変わらなかったからだ。AutoHotkey のドキュメントでも、UAC の問題は UIAccess と管理者権限のどちらでも解消できると書いてある。https://www.autohotkey.com/docs/v2/FAQ.htm#uac これは少し誤解を招く文かもしれない。
というわけで結論として、UWP の中でもさらに特殊な条件を含めた really-always-on-top を実現するためには、UIAccess が必要である。WinSetAlwaysOnTop の remarks にも書いておいてほしい気がする。
UIAccess should not be used: By applications that are not assistive technologies. By assistive technology applications that display information or UI that is not relevant to the accessibility scenario they target. By applications that just want to appear above other applications in the new Windows UI.
と書いてある。まさに今回のことを言っているようだ。こんな場合は UIAccess を使うべきではない! とだけ書かれても、どうすればいいのか分からない。