2015-11-06 66 views
1

我有一個傳統的COM組件,升級換代的一部分,我從現有的接口派生查詢有關VB腳本和COM接口繼承

接口1 { 一些方法 }

接口2:公共接口1 { 新方法 }

有一箇舊的評論註釋不要這樣做。而是有inteface2有單獨的一個不是從基地派生,因爲它的一部分相同的CoClass ...沒有必要重複任何代碼...

評論評論: 腳本語言是解釋型語言,並且由於所有方法都是延遲綁定,所以它們是天生多態的。所有變量都是無類型的(VARIANT是無類型的)。 但是,有關腳本語言的單獨問題。腳本語言不使用虛函數表來調用COM對象上的方法,而是通過IDispatch接口調用方法。不幸的是,IDispatch只能與一個自定義界面相關聯。 通過IDispatch接口訪問的所有方法必須是自定義界面

任何人都可以解釋...的一部分,他的意思是說的GetIDsOfNames將不能返回正確的ID?或者是別的東西

回答

1

它足夠準確,一個coclass可以實現多個接口。但其中一個是「特殊」,它是IDL中的[default]。腳本語言只能使用該默認界面,他們沒有機制來檢索另一個界面。換句話說,他們不能調用QueryInterface()。主要是因爲他們在語言設計中根本不支持接口或轉換或多重繼承的概念。故意地,腳本語言應該很容易使用。

因此,如果interface1最初是默認接口,那麼腳本編程人員不能使用添加的interface2方法。你會想看看this SO post看到的後果。

您可以通過追加新方法來保持COM接口與舊客戶端程序的向後兼容,並且永不改變舊方法的順序或參數。這是很冒險的,一個意外遇到你的組件的舊版本的更新客戶端程序將會以一種非常糟糕的方式出現。通常很難診斷,純粹的DLL地獄。只有真正安全的方法是分配新的[uuid],強制客戶端程序重新編譯。如果您還更改了DLL的名稱或安裝位置,那麼它們可以並排居住。