????
MSAA --> UIA
?
English version:
?
?
說穿了,MSAA就是IAccessible Interface
?
這個(gè)Interface本來是準(zhǔn)備給盲人用的, 結(jié)果卻在大多數(shù)情況下用作UI Automation的一種實(shí)現(xiàn)方法. 但是呢, 這個(gè)接口包含的方法又太少了, 非常的雞肋, 只能夠讀名字,類型,位置. 對(duì)于一些特別的屬性, 比如ClassName, Orientation什么的, 就沒有暴露出來. 也不能支持UI操作, 比如選擇, 移動(dòng)窗口, 更沒有提供Event Support
所以呢,微軟想想,覺得是應(yīng)該專門給UIAutomation提供一套獨(dú)立的Interface了, 于是就給了兩個(gè):
?
IAccessibleEx
IRawElementProviderSimple
這兩個(gè)Interface歸類是歸入Windows Automation API的, 而不是MSAA.
?
第一個(gè)Interface IAccessibleEx, 名字看起來跟MSAA的IAccessible類似, 他實(shí)際上只是一個(gè)讓客戶端獲取IRawElementProviderSimple的入口接口而已。 實(shí)現(xiàn)Pattern和Properties的都在IRawElementProviderSimple接口里面。他的另外一個(gè)目的是給傳統(tǒng)的MSAA Client提供接口兼容.
?
參考:
?
IAccessibleEx的默認(rèn)實(shí)現(xiàn)在UIAutomationCore.DLL里面. 這里面實(shí)現(xiàn)了UIA?<-> IAccessibleEx 的bridge
?
客戶端使用Automation首先是獲取IAccessible, 然后通過QueryService （不是QueryInterface,因?yàn)闉榱酥С諺ista的high DPI和MSHTML）獲取IAccessibleEx， 然后再通過QueryInterface就可以獲取IRawElementProviderSimple了。
?
中間的IAccessibleEx的作用是handshake， 雖然說它里面也暴露了不少屬性，但是具體的實(shí)現(xiàn)都是在IRawElementProviderSimple和原來的IAccessible當(dāng)中。 微軟已經(jīng)故意淡化IAccessibleEx interface了，主要用作內(nèi)部實(shí)現(xiàn)UIA的橋梁， 在MSDN中已經(jīng)找不到IAccessibleEx的Definition了
拿到IRawElementProviderSimple后，剩下的事情就簡(jiǎn)單了， 就是直接問這個(gè)Interface要對(duì)應(yīng)的provider，然后從provider里面拿pattern就可以了。 詳細(xì)的介紹可以參考:
這里需要說明的是，AutomationProvider， 既可以在UI Server中實(shí)現(xiàn)，也可以在Client中實(shí)現(xiàn)。在UI Server中實(shí)現(xiàn)的話， 就直接從IRawElementProviderSimple繼承，然后用下面的方法回應(yīng)客戶端請(qǐng)求就可以了：
if ((m.Msg == WM_GETOBJECT) && (m.LParam.ToInt32() ==
??????????????? AutomationInteropProvider.RootObjectId))
??????????? {???????????????
??????????????? m.Result = AutomationInteropProvider.ReturnRawElementProvider(
??????????????????????? this.Handle, m.WParam, m.LParam,
??????????????????????? (IRawElementProviderSimple)this);?????????????
??????????????? return;
??????????? }
但是如果都在Server端實(shí)現(xiàn)的話，對(duì)于傳統(tǒng)的Win32 Control， 需要做的修改就太大了。 所以UIAutomation也支持在Client里面實(shí)現(xiàn)。凡是客戶端的實(shí)現(xiàn)，就叫做Provider/Automation Proxy， 具體說來， 就是在ProviderOptions property里面返回ProviderOptions.ClientSideProvider
對(duì)于Win32和WinForm的默認(rèn)實(shí)現(xiàn)，都是在client里面的。 具體的assembly是UIAutomationClientSideProvider.DLL。 里面的ProxyHwnd.GetElementProperty實(shí)現(xiàn)非常具體代表性:
?
如果要獲取AutomationID, 實(shí)現(xiàn)方法是發(fā)送WM_GETCONTROLNAME message
如果要獲取Name, 邏輯是：
如果是WinForm Control， 就讀MSAA里面的Name
否則， 首先嘗試調(diào)用GetWindowLong和GetWindowText API
如果返回空， 再嘗試PostMessage
?
看到這里，我不小心找到了一個(gè)2004年的Automation paper:
?
這位叫做Brian McMaster的兄弟，現(xiàn)在是Test Architect， 當(dāng)年在沒有Automation只有MSAA的時(shí)候， 就教育大家用WM_GETCONTROLNAME message， 區(qū)分control tree結(jié)構(gòu)，提防window owner和parent不一致的情況等等。
?
有了這些了解后，動(dòng)手來玩UIA就很簡(jiǎn)單了。WinForm Server side需要做的事情是:
?
1. override WndProc, 用AutomationInteropProvider.ReturnRawElementProvider方法來回應(yīng)WM_GETOBJECT消息
2. 實(shí)現(xiàn)IRawElementProviderSimple， 并且在接口方法中返回ProviderOptions.ServerSideProvider
3. 實(shí)現(xiàn)具體的provider， 比如ISelectionProvider
?
這些都可以在我上面的link中找到例子代碼的。
而UIAutomation的客戶端呢， 現(xiàn)在有兩組API, managed/unmanaged
?
managed API在System.Windows.Automation里面。 具體的class是AutomationElement
unmanaged API是一組以UIA開頭的API。
?
目前managed API的內(nèi)部實(shí)現(xiàn)借用了unmanaged API。 而unmanaged API里面用到的client side provider， 其實(shí)是在managed的class中實(shí)現(xiàn)的。 所以兩者關(guān)系目前比較復(fù)雜。而且有的功能在unmanaged API里面沒有問題，但是managed API里面有bug。 在Win8的時(shí)候， 微軟打算把兩者的實(shí)現(xiàn)都合并起來， 減小維護(hù)成本。
幾個(gè)有趣的地方是：
?
如果一個(gè)UI Server同時(shí)擁有ServerProvider和ClientProvider，那么ServerProvider會(huì)覆蓋掉同類型的ClientProvider。如果有的Provider只在ClientSide才實(shí)現(xiàn)， 那么ClientProvidier會(huì)正確返回的。 不用擔(dān)心實(shí)現(xiàn)了ServerProvider導(dǎo)致ClientProvider不工作的情況
?
[added on 9/24/2009]
Win32和WinForm的ClientProvider有系統(tǒng)的默認(rèn)實(shí)現(xiàn). ClientProvider的注冊(cè)是在client side執(zhí)行的, Server side不需要管. 具體的請(qǐng)參考:
如果要研究系統(tǒng)提供的Client Provider注冊(cè)過程, 可以用windbg放這樣的斷點(diǎn):
sxe ld UIAutomationClientsideProviders*
[/added]
?
如果使用UIAutomation API, 會(huì)發(fā)現(xiàn)目前UI Automation里面的Property和Pattern是不能自己隨意擴(kuò)展的。比如你想自己定義一個(gè)PatternID和Interface注冊(cè)進(jìn)去是不行的。 因?yàn)閁I Automation返回給你的interface其實(shí)是做過手腳的。 MSDN中甚至都說了， 你不能直接使用interface里面的方法:
"The interface returned by this method can only be passed back to UI Automation. Attempting to call a method on the interface will raise an exception"
所以，如果你真的要做，就老實(shí)地按照前面介紹的步驟，用COM的標(biāo)準(zhǔn)方法， 先拿MSAA， 然后再自己QueryInterface。 只要能作QI， 什么都解決了。
?
最后要提的是，前面的介紹都是針對(duì)Win32/WinForm的。 對(duì)于WPF， 它通過自己的AutomationPeer來實(shí)現(xiàn)UIAutomation的Server. 根UIAutomation Client的通信方式也是通過Named Pipe而不是DCOM/Message了。 不過傳統(tǒng)的MSAA Client還是可以通過MSAA訪問WPF的， 原因在于WPF里面提供了UIAMSAA Bridge， WPF會(huì)自己創(chuàng)建Inproc IAccisible Proxy來滿足MSAA Client的請(qǐng)求。
?
最后再貼幾個(gè)鏈接:
?
這兩個(gè)doc是微軟寫的， 結(jié)果MSDN上卻沒有連接。 里面詳細(xì)介紹了UIA的design goal, IAccessibleEx和IRawElementProviderSimple的作用和關(guān)系， 基本上可以算一個(gè)design spec了。 這兩個(gè)doc解決了我看代碼一年都沒看明白的問題。 里面把MSAA, UIA, Provider, Pattern, Proxy, Bridge, 還有依賴調(diào)用關(guān)系解釋得淋漓盡致！
?