尽管没有断点,为什么 Visual Studio 仍会获得焦点?

发布于 2024-11-07 21:53:06 字数 89 浏览 1 评论 0原文

我的应用程序中没有断点,但有时 Visual Studio 会无缘无故地获得焦点。 (在调试模式或不在调试模式)(就像有一个断点)

可能是什么原因?

there is no breakpoint in my application but sometimes Visual Studio get the focus when there is no reason. (in debug mode or not in debug mode) (like there was a breakpoint)

What can be the reason?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

江心雾 2024-11-14 21:53:06

如果调试器没有因为您手动设置断点或因为应用程序引发异常或遇到其他意外错误而中断,则最可能的解释是您的应用程序正在放弃焦点。

例如,在将焦点设置到应用程序中的另一个窗口之前,您先销毁当前具有焦点且位于前台的窗口。然后,由于某些窗口始终必须具有焦点,因此窗口管理器将激活设置为下一个可用窗口,而该窗口恰好是 Visual Studio 拥有的窗口。产生的效果就像按下 Alt+Tab 一样。

Raymond Chen 有一篇关于此的博客文章,正确的顺序用于禁用和启用窗口

如果您完成了模式对话框,您可能会想按以下顺序进行清理:

  • 销毁模式对话框。
  • 重新启用所有者。

但是如果您这样做,您会发现前台激活不会返回给您的所有者。相反,它会转到某个随机的其他窗口。明确地将激活设置为预期所有者“修复”了问题,但仍然存在所有闪烁,并且闯入窗口的 Z 顺序变得一团糟。

发生什么事了?

当您销毁模式对话框时,您正在销毁具有前台激活的窗口。窗口管理器现在需要找到其他人来激活。它尝试将其提供给对话框的所有者,但所有者仍然处于禁用状态,因此窗口管理器会跳过它并查找其他窗口,即未禁用的窗口。

这就是为什么你会得到奇怪的闯入窗口。

销毁模式对话框的正确顺序是

  • 重新启用所有者。
  • 销毁模式对话框。

这一次,当模式对话框被销毁时,窗口管理器会查看所有者,嘿,这次它已启用,因此它继承了激活。

无闪烁。没有闯入者。

If the debugger isn't breaking because you've manually set a breakpoint or because the application has thrown an exception or encountered some other unexpected error, the most likely explanation is that your application is giving up the focus.

For example, you destroy the window that currently has the focus and is in the foreground before setting that focus to another window in your application. And then, because some window always has to have the focus, the window manager sets activation to the next available window, which just happens to be the one owned by Visual Studio. The resulting effect would be just as if you pressed Alt+Tab.

Raymond Chen has a blog article about this, The correct order for disabling and enabling windows:

If you are finished with a modal dialog, your temptation would be to clean up in the following order:

  • Destroy the modal dialog.
  • Re-enable the owner.

But if you do that, you'll find that foreground activation doesn't go back to your owner. Instead, it goes to some random other window. Explicitly setting activation to the intended owner "fixes" the problem, but you still have all the flicker, and the Z-order of the interloper window gets all messed up.

What's going on?

When you destroy the modal dialog, you are destroying the window with foreground activation. The window manager now needs to find somebody else to give activation to. It tries to give it to the dialog's owner, but the owner is still disabled, so the window manager skips it and looks for some other window, somebody who is not disabled.

That's why you get the weird interloper window.

The correct order for destroying a modal dialog is

  • Re-enable the owner.
  • Destroy the modal dialog.

This time, when the modal dialog is destroyed, the window manager looks to the owner and hey this time it's enabled, so it inherits activation.

No flicker. No interloper.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文