使用uiAccess = True安装桌面WPF应用程序时的注意事项 [英] Considerations when installing a desktop WPF app with uiAccess=True

问题描述

背景:

我需要在另一台显示器上创建调光效果.我想我通过使用WPF窗口(通过 Topmost 和 AllowsTransparency = True)占据整个屏幕尺寸来解决此问题.它具有内部黑色发光效果，样式为 WS_EX_TRANSPARENT |.WS_EX_TOOLWINDOW 应用于它(除其他外)，以​​允许用户单击进入其背后的应用程序.

I have a requirement to create a dimming effect on another monitor. I think I solved it by using a WPF Window that takes up the entire screen dimensions with Topmost and AllowsTransparency = True. It has an inner black glow effect and has the style WS_EX_TRANSPARENT | WS_EX_TOOLWINDOW applied to it (among other things) to allow users to click through to the apps behind it.

我监视Windows中的 EVENT_OBJECT_REORDER 事件，并调用 SetWindowPos 强制将Topmost状态置于其他Topmost窗口之上.到目前为止，在我的概念验证测试中，它似乎运行良好.

I monitor for EVENT_OBJECT_REORDER events in Windows and call SetWindowPos to force the Topmost state above other Topmost windows. It seems to work well so far in my proof of concept testing.

我发现的问题是调光(窗口)将覆盖任务栏，但是如果我单击开始"菜单，则不会.我目前正在使用Windows 10进行测试.如果单击开始"菜单，它将导致开始"菜单和任务栏出现在调光(窗口)上方.我希望一切都保持昏暗.

The problem I found was this dimming (window) would cover the task bar, but not if I click the Start Menu. I'm currently testing with Windows 10. If I click the Start Menu, it causes the Start Menu and Taskbar to appear above the dimming (window). I wanted everything to remain dim, always.

我通过在应用清单中设置 uiAccess = true，生成自签名证书并将exe复制到"c:\ program files *"来解决了此问题.这样一来，即使在开始"菜单上方，我也可以为窗口强制处于最上层"状态.

I solved this issue by setting uiAccess=true in the app manifest, generating a self-signed cert, and copying the exe over to "c:\program files*". This allows me to force a Topmost state for my window, even above the Start Menu.

我的问题:

• 是否可以在没有 uiAccess 的情况下在开始"菜单上放置窗口?甚至还有另一种无需使用窗口即可使屏幕变暗的方式(但不依赖于显示器驱动程序或硬件功能)?

• Is there a way to position a window over the Start Menu without uiAccess? Or even another way to force dimness to a screen without using a window (but not dependent on monitor drivers or hardware capabilities)?

如果没有，在分发WPF应用程序(通过WiX安装项目或类似的东西)时要牢记哪些注意事项，该应用程序将通过 uiAccess = True绕过UIPI限制?我可以在设置过程中简单地安装自签名证书吗?用户会遇到其他障碍吗?作为开发人员，我在构建它时是否会遇到其他障碍(除了我已经提到的内容之外)?

If not, what considerations do I need to keep in mind when distributing a WPF app (via a WiX setup project or something similar) that is to bypass UIPI restrictions with uiAccess=True? Can I simply install my self signed cert during the setup process? Will the user run into any additional hurdles? Will I, as a developer, run into any additional hurdles while building this (aside from what I've already mentioned)?

谢谢！

推荐答案

我监视EVENT_OBJECT_REORDER事件

I monitor for EVENT_OBJECT_REORDER events

您正在使用SetWinEventHook().此方案无法通过经典的如果两个程序可以做到这一点"括号.Raymond Chen在此博客文章中对此进行了很好的讨论，您的方法是专用帖子.

You are using SetWinEventHook(). This scenario fails the classic "what if two programs do this" bracket. Raymond Chen discussed this pretty well in this blog post, giving your approach a dedicated post.

这比您想像的要普遍得多.每台Windows机器都有一个执行此操作的程序，例如，运行屏幕键盘程序 Osk.exe .有趣的实验是，我预计它会在一段时间内剧烈闪烁，但假设最终会放弃.并不确定，上次我是在Vista时尝试过的，不会，请告诉我们.

This is a lot more common than you might assume. Every Windows machine has a program that does this for example, run Osk.exe, the on-screen keyboard program. Interesting experiment, I predict it will flicker badly for a while but assume it will eventually give up. Not actually sure it does, last time I tried this was at Vista time and it wouldn't, please let us know.

完全可以肯定，您会得出结论，这不是正确的解决方法，因此uiAccess也无济于事.您在这里需要它来绕过UIPI并使SetWindowPos()工作.UAC的一个方面，阻止程序尝试劫持提升的程序功能.覆盖开始"窗口即被视为DOS攻击.这里更大的问题是您的自签名证书不起作用，您必须购买一个真实的证书.每隔7年就会使您损失数百美元.

Fairly sure you will conclude that this isn't the right way to go about it so uiAccess is moot as well. You needed it here to bypass UIPI and make SetWindowPos() work. An aspect of UAC that blocks attempts by a program to hijack an elevated program's capabilities. Covering the Start window qualifies as a DOS attack. Bigger problem here is that your self-signed certificate isn't going to work, you'll have to buy a real one. Sets you back several hundred dollars every ~7 years.

用软件控制显示器亮度并非易事.每个人都可以找到SetDeviceGammaRamp()，这也是您应该做的.MSDN文档将为您提供大量的FUD，但是afaik每个主流视频适配器驱动程序都可以实现它.它在游戏中很流行.一个不可避免的限制是它仅在运行程序的桌面上有效.因此，不适用于安全桌面(屏幕保护程序和Ctrl + Alt + Del)，也不适用于其他登录会话，除非它们也启动了您的程序.

Controlling monitor brightness with software isn't that easy to do correctly. Everybody reaches for SetDeviceGammaRamp() and that is what you should do as well. The MSDN docs will give you plenty of FUD but afaik every mainstream video adapter driver implements it. It was popular in games. One unavoidable limitation is that it is only active for the desktop in which your program runs. So not for the secure desktop (screen saver and Ctrl+Alt+Del) and not for other login sessions unless they start your program as well.

WMI过于脆弱，无法考虑.我不太确定为什么会如此频繁地失败，我认为这与视频适配器和显示器之间通常不那么出色的I2C互连有关.或想要通过Fn按键控制亮度的笔记本电脑，始终可以胜任.或Windows功能可根据环境光线自动调整亮度，这始终是更理想的方式，而且很难遵循.

WMI is too flaky to consider. Not so sure why it fails so often, I assume it has something to do with the often less-than-stellar I2C interconnect between the video adapter and the monitor. Or laptops that want to control brightness with an Fn keystroke, that feature always wins. Or the Windows feature that automatically adjusts brightness based on ambient light, invariably the more desirable way to do this and a hard act to follow.

最常见的结果可能是您的程序耸了耸肩，而笨拙的监视器控件则对用户造成了诅咒.但是他会摆弄并弄清楚.抱歉.

Most common outcome is likely to be a shrug at your program and a curse of the user at the clumsy monitor controls. But he'll fiddle with it and figure it out. Sorry.

这篇关于使用uiAccess = True安装桌面WPF应用程序时的注意事项的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！