2016-10-04 23 views
0

根據MSDN,winAPI功能如WindowFromPoint不會返回所有頂層窗口(至少跳過隱藏和禁用),然後我們需要使用更多的可混合功能,如ChildWindowFromPoint如何找出一般的hWnd代表什麼?

但是,最後一個函數不僅可以返回窗口,還可以獲取任何子控件句柄。

所以我的問題是我應該如何區分對象的實際類型,我有它的句柄,它是一個窗口,按鈕,複選框..等等。

當我試圖「定義」什麼是Window \ Form手動檢查它(如果它有一個標題欄),不同的對象之間的邊界真的很模糊。

獲取課程名稱當然不是一種選擇,因爲它們通常都是非常隨意的。

最後,我發現微軟在.Net Framework中的自動化UI有些如何設法區分對象,任何線索是如何做到的?看起來像一個人需要實現一個複雜的機制,這將比較許多參數來驗證它是什麼,但是然後AUI如何確定它發現了什麼?

回答

4

所以我的問題是我應該如何區分對象的實際類型,我有它的句柄,它是一個窗口,按鈕,複選框..等等。

您可以在窗口句柄上調用GetClassName來檢索窗口類的文本表示。雖然這可能有助於識別標準控制類,但對自定義窗口類(通過調用RegisterClassEx引入的類)沒有多大幫助。

窗口類是靜態的,並且特定窗口類的任何窗口稍後可以更改類模板中指定的某些設置。要檢索最新的窗口信息,您可以改爲使用GetWindowLongPtr

我發現微軟在.Net Framework中的自動化UI一些如何設法區分對象,任何線索如何做到這一點?

UI自動化根本不依賴窗口句柄。它通過檢查和操作可訪問樹來工作,這是通過COM接口實現的。本地窗口句柄和可訪問對象之間沒有嚴格的關係(這就是爲什麼它可以用於無窗口控件,例如大多數瀏覽器所使用的控件)。

AUI如何確定它發現了什麼?

因爲它不會預測UI自動化接口返回的內容。這些由控制作者實施,因此可以假定它是可信的信息。


這大致是正確的。您仍然可以通過調用SetClassLongPtr來修改註冊的課程。

+0

RealGetWindowClass()可能是更好的選擇。 – bunglehead