在没有轮询的情况下检测活动的子窗口 [英] Detecting active childwindow change without polling

问题描述

您好，



我正在尝试检测窗口更改。可能没有民意调查。我发现了这篇文章： http://www.relaut.com/detect-active -window-title-without-polling-c / [ ^ ]。

如果窗口激活意味着将新进程放在前台，那么效果很好。但是，如果我要更改活动的浏览器选项卡，则无效。

有没有类似的方法来检测这种情况？



谢谢。

Hello,

I am trying to detect window changes. Potentially without polling. I have found this article: http://www.relaut.com/detect-active-window-title-without-polling-c/[^].
Works great if the window activation implies putting a new process in foreground. But does not work if I am changing the active browser tab for example.
Is there any similar way that detects this scenario too?

Thank you.

推荐答案

我不这么认为。这完全是浏览器的内部。对于外部词，没有tab这样的概念，因为它们可以以许多不同的方式实现。你所谈论的内容并不明显，但看看你引用的文章表明你正在谈论使用Windows Hooks来挂钩外来进程的行为。但是让我们考虑一下这些流程是什么。是的，如果他们有一个主窗口，它可以访问所有顶级事件，但一般情况如何？真的没什么可说的。



例如，让我们考虑WPF WebBrowser 控件。它本身没有标签，因此WPF应用程序可以实现它们。但是除了某些对象向Windows操作系统公开 Window 之外的所有其他 UIElement 对象的WPF选项卡都不是窗口对象。它们在没有消息泵送的情况下工作，并且仅在DirectX（最接近硬件）的级别上与OS交互;并且所有基于事件的UI仅通过顶部窗口对象与OS消息传递系统连接。这样，从操作系统的角度来看，这些选项卡将完全从其角色中抽象出来，因此没有任何预定义的方法来识别它们。对于操作系统，它们根本就不存在。



现在，让我们在控件中实现这样的选项卡。毕竟，类 System.Windows.Controls.WebBrowser 基于 System.Windows.Interop.ActiveXHost 。我不认为标签是if的一部分，但让我们想象一下。所以呢？即使控件完全基于Windows控件，选项卡也可以扮演任何可以想象的角色，因为没有标准告诉浏览器应该有选项卡或某些选项卡应该是浏览器的一部分。此外，没有任何东西（除了明显的费用）阻止任何人完全基于WPF从头开始实现浏览器。或者在DirectX上。或者是其他东西。对于Windows操作系统，这将是 本体 ，康德不可知的事情就像这样（最流行的不准确的英文渲染：自我中的东西） 。 :-)

-SA

I don't think so. This is a totally internal to the browser. For the outside word, there is no such concept as "tab", because they can be implemented in many different ways. It wasn't obvious what you are talking about, but the look at the article you referenced suggests that you are talking about using Windows Hooks for hooking up behavior of the foreign processes. But let's consider what those processes can be. Yes, if they have a main window, it will be accessible with all its top-level events, but how about the general case? Nothing can be told, really.

For example, let's consider WPF WebBrowser control. It does not have tabs itself, so a WPF application may implement them. But WPF tabs, as all other UIElement objects except some object exposing Window to Windows OS, are not window objects. They work without message pumping and interact with OS only on the level of DirectX (which is closest to the hardware); and all event-based UI is connected with OS messaging system only through the top Window object. This way, those tabs will be something totally abstracted from their role, from the OS standpoint, so there is no any predefined way to recognize them. For OS, they simply don't exist.

Now, let's imaging for a second that such tabs are implemented in the control. After all, the class System.Windows.Controls.WebBrowser is based on System.Windows.Interop.ActiveXHost. I don't think the tabs are part of if, but let's just imagine it. So what? Even if the control was totally based on a Windows control, the tabs can play any thinkable role, as there is not a standard telling that a browser should have tabs or some tabs should be part of a browser. Moreover, nothing (except apparent expenses) prevents anyone from implementing a browser from scratch fully based on WPF. Or on DirectX. Or something else. For Windows OS, this would be a noumenon, Kant's unknowable "thing-as-such" (most popular inaccurate English rendering: "thing-in-itself"). :-)

—SA

这篇关于在没有轮询的情况下检测活动的子窗口的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！