16. ActiveX 元件
COM 簡介
筆者不想深入介紹關於 COM 的技巧，但是要了解 Visual Basic 在此領域的潛能，您至少需要了解一些主要的概念。
長話短說
當 Microsoft 開始發售 Windows 時，它成為第一種可以在同一時間內執行多重應用程式的作業系統，每個人都了解 Microsoft 需要設計一個可以在應用程式之間交換資料和溝通的系統，Clipboard 適合從事此簡單的剪貼（cut-and-paste）動作，但是 Clipboard 太過於簡單而無法處理 Microsoft 目前所提出大部分嚴苛的需求。
以此為原則，第一個重要嘗試就是動態資料交換（DDE），一個讓應用程式之間互相呼叫的協定，DDE 並不是非常的成功，可能在於其缺乏可靠度。雖然 DDE 擴展成為可工作於區域網路（Network DDE），而可以連結不同工作站的應用程式，但是只有少數的 Windows 應用程式實作這個功能。（Visual Basic對於 DDE 提供有限的支援，但是筆者沒有將其包含在此書中。）
支援 Windows 3.1 的第一個 OLE（Object Linking and Embedding）版本始於 1992 年並且利用 DDE 作為應用程式之間相互通訊的基礎。OLE 是第一個可以讓使用者以及程式設計人員建立複合文件（compound documents）的協定，複合文件就是文件中包含不同應用程式的資料格式（舉例來說，Word 文件包含了 Excel 工作表）。依照應用程式的需求而定，複合文件可以完整的包含其他簡單的文件（內嵌 Embedding），或是單純的包含已存在文件的關聯（連結 Linking）。當使用者點取複合文件中嵌入或是連結的文件，Windows 就會執行有能力處理此特殊文件的應用程式。
OLE2 發表於 1993 年，是第一次包含了對所在位置啟動（in-place activation）的支援，就是給予使用者可以不用開啟另一 Windows 就可以編輯複合文件的能力。舉例來說，OLE2 使您可以不要離開 word 的環境而編輯在 word 文件中的 excel 工作表。但是您只能看到 excel 的功能表，當您編輯嵌入式資料的時候，excel 的功能表代替了 word 的功能表。OLE2 是一個重要的階段，因為 OLE2 代表了放棄以 DDE 作為通訊協定而倚靠一個以元件為基礎的新架構：元件物件模型（COM：Component Object Model）。
越來越明顯地，COM 的基礎架構比連結以及嵌入的技術來的重要。以使用者的觀點來看，當建立複合文件的能力日益強大時，開發者發現他們只要利用 COM 就可以開發大型應用程式。事實上，COM 促進了以元件為基礎的開發觀念，使您將大型應用程式分割成較小的單位，讓您在維護以及部署這些小單位的元件上比起整個大型應用程式容易。OLE 中讓程式間互相通訊的部分就是 OLE Automation。許多程式語言可以以 OLE Automation 客戶端的身分，控制其他作為 OLE Automation 伺服器的應用程式。舉例來說，您可以在 Visual Basic 3 或是之後的版本之外，利用 VBScript 來控制 Excel 以及 Word。
這個新程式設計典範的潛力，在 Microsoft 發行 Visual Basic 4 企業版後，變的更為明顯。Visual Basic 4 企業版中包含了對 Remote Automation 的支援。Visual Basic 程式設計人員最後不僅要建立 COM 元件，並且也是透過網路上的 電腦（使用其 CPU、記憶體以及其他資源）命令以及執行元件的先驅者。此時分散式運算初次在 Windows 平台上露面。
在 Visual Basic 4 發行時，另一種元件的類型初次出現﹕OLE 控制項（OLE controls）。這是 VBX 控制項的繼承者，VBX 控制項對 Visual Basic 的普及有很大的助益。VBX 控制項的問題在於其獨有的架構、命名方式、以及 Visual Basic 的環境，使得 VBX 控制項幾乎不能被其他的程式語言所使用。當轉換到 32 位元平台時，Microsoft 決定建立一個以可以被其他廠商採納以及支援，並且以 OLE 為基礎的新型態的控制項。
Remote Automation 只是下一個技術－也就是分散式 COM、或是簡稱 DCOM，的測試過程。DCOM 在 1996 年隨著 Microsoft Windows NT 4.0 正式發行，許多程式設計人員繼續使用了 Remote Automation 一段時間，直到 1997 年 Microsoft 發行 DCOM95.EXE，這是一個增加在 Windows 95 上支援 DCOM 的程式。DCOM 證明了比 Remote Automation 更有效率和穩定，而 Microsoft 不再修訂 Remote Automation 的版本。Remote Automation 唯一的長處就是支援 16 位元的平台。換句話說，如果您正在利用 Visual Basic 5 以及 6 發展應用程式，您內定的定址模式只有 32 位元的平台，您將不能在使用 Remote Automation。
Microsoft 實驗室發行的最新的一個技術就是 ActiveX。在某種意義上，ActiveX 就是 Microsoft 對於網際網路新挑戰的一個答案。舉例來說，OLE 控制項太巨大以至於無法在網路上傳遞，所以 Microsoft 需要設計一種新的控制項。如今，ActiveX 成為一種 OLE 的同義詞，並且您可以把 COM 元件視為 ActiveX 元件。伴隨著 ActiveX 的出現，OLE Automation 也改名簡稱為Automation。ActiveX 對於不斷成長的開發者字典也提出了新的名詞：ActiveX 控制項以及ActiveX 文件。ActiveX 控制項已經取代了 OLE 控制項，同時 ActiveX 文件也已經取代了 OLE 文件並且允許程式設計人員在收納器中（舉例來說，Microsoft Internet Explore）建立 ActiveX 文件。Visual Basic 5 以及 6 可以建立 ActiveX 控制項以及文件。
COM 元件的類型
您可以依據程式執行的地點，將 COM 程式碼元件分成三種類型。
In-process 伺服器（DLL）
COM 元件中最簡單的類型就是與使用元件的應用程式位於同一位址空間的 DLL。因為在 32 位元的平台上每個處理序（process）有自己的位址空間，所以每個處理序負責處理元件的不同執行個體。這些元件並沒有透過 COM 的幫助而直接與客戶端聯繫，因此當速度為重要的因素時，它們是最適當的選擇。它們的主要缺點就是客戶端對於伺服端的故障沒有防護。如果元件發生致命的錯誤，其客戶端將會毀損。
ActiveX 控制項是可以被 ActiveX 收納器（如 Visual Basic 的表單）包容的一種如同處理序元件的種類。要符合 ActiveX 控制項的規格，元件必須實作出 ActiveX 規格所訂定的幾個介面。然而，身為 Visual Basic 的程式設計人員，您不需要擔心這些附加的介面，因為 Visual Basic 為您做好了所有的事情。第十七章將敘述ActiveX 控制項。
本機 out-of-process 伺服器（EXE）
您也可以將 ActiveX 元件編譯成一個 EXE 的程式。當您想要建立一個獨立作業的應用程式並且可以同時提供外界一個可程式化的物件時，將元件編譯成 EXE 程式是合宜的。這種伺服器最好的例子就是 Microsoft Office 系列：您可以獨立使用 Excel 或 Word 應用程式；或是在您的應用程式中，將它們當作是元件的提供者。EXE 伺服器在自己的位址空間中執行，如此使得與它們的客戶端聯繫的速度比起同處理序元件（In-process component）慢。另一方面，ActiveX EXE 伺服器較同處理序伺服器（In-process server）安全一點。如果有一個元件毀損，客戶端的應用程式通常可以復原。
遠端 out-of-process 伺服器（EXE）
遠端伺服器是一個不在客戶端應用程式的電腦上執行的 EXE 程式。客戶端與伺服器透過 DCOM（或是 Remote Automation）做聯繫。不用說，它們之間聯繫的速度比本機伺服器還要慢，但是遠端元件提供建立真實分散式應用程式的能力。一個執行在遠端電腦的遠端伺服器程式不會挪去客戶端應用程式的 CPU 時間以及記憶體空間，因此您可以將複雜的程式分散到您網路上的所有電腦上。更進一步地，如果您需要完成一項耗費網路上某台電腦資源的工作（舉例來說，一個複雜的資料庫查詢或是一個允長的列印工作），將工作委託給實際上資源所在的電腦的遠端元件去執行是更方便適合的。
遠端伺服器的一個好處就是它們和本機 EXE 伺服器完全一樣。事實上，同一個伺服器可以提供服務給本機電腦的應用程式（如此以本機伺服器類型工作），也可以提供服務給執行在遠端電腦的應用程式（如此以遠端伺服器工作）。
您也可以把 DLL 當作遠端伺服器來執行。要允許 DLL 存在於一個獨立的生命週期，您需要確定 DLL 是寄宿在遠端電腦的 DLL 代理處理序中（DLL surrogate process）。這是依據以 Microsoft Transaction Server 為基礎的元件所定的原則。筆者也沒有在此書中涵蓋 MTS 的程式設計。
使用既有的元件
為了讓您體驗到以元件為基礎的程式設計的威力，筆者將會讓您知道在 Visual Basic 中加入一個拼字檢查功能是一件很簡單的事。發展一個拼字檢查的程式不是一件普通的工作，這可能要花上您數個月的時間。很幸運地，Microsoft Word 已經包含了一個很好的拼字檢查元件，並且更重要的是，Word 透過 Automation 將檢查元件提供出來，就如同一個可程式化的物件一般。您所要做的就是利用此項功能並且利用 Word 為伺服器建立一個應用程式。
要使用任何 Automation 元件首先要做的就是在 設定引用項目對話方塊 中加入一個 引用項目 至 物件程式庫 中，您可以從 專案 功能表中找到此功能。瀏覽 可引用項目 的清單，並且核取 Microsoft Word 8.0 Object library 。（這個例子假設您已經在您的電腦中安裝了 Word 97。）在您做好此步驟後，您可以利用 瀏覽物件 來檢視所有 Word 物件程式庫中的物件，如果您安裝了 VBAWRD8.hlp 檔案，您甚至可以查詢關於特定屬性或是方法的相關說明或是資訊。（見圖16-1）。
| 圖16-1 核取 Microsoft Word 8.0 Object library 的「引用項目對話方塊」以及顯示物件程式庫內容的瀏覽物件對話方塊。 |
您甚至可以不用加入引用項目至物件程式庫中就可以讓您的專案如 Automation 客戶端一樣地工作，此時，建立物件必須利用 CerateObject 函數代替 New 關鍵字。並且您必須將物件引用（Object Reference）儲存在一般的 As Object 物件變數上而不要儲存在特定的物件變數上，這表示您只能使用較沒有效率的晚期連結（late binding）代替早期連結（early binding）。所有利用 Visual Basic 3 或是 VBScript 寫的客戶端程式只能透過此方法存取 Automation 伺服器 。
當您已經加入一個引用至 Word 物件程式庫中，這個物件就如同在專案中，您便可以進行您的應用程式開發。舉例來說，您可以宣告一個物件變數並且在您主要的表單載入時建立一個新的 Word.Application 物件的執行個體﹕
Dim MSWord As Word.Application Private Sub form_Load() 'Create the instance of Word that will be used later. Set MSWord=New Word.Application End Sub
當一個 Word 物件程式庫的物件建立時，Word 應用程式本身是不可見的。這樣讓您的使用者在使用物件時甚至不會察覺到您是使用外在的物件程式庫。然而，如果您想要的話，仍可以讓 Word 是可見的：
MSWord.Visible=True
然而，在筆者準備好的範例程式中，使用了 Microsoft Word，不過在使用者前隱藏起來。
圖 16-2 顯示了使用者實際看到的畫面。主要的程序就是實際上完成拼字檢查的那一段，如果檢查出有字彙不正確，將要置換的建議字彙清單列在 ListBox 控制項中。Private Sub cmdCheck_Click()
Dim text As String
Dim suggestion As Word.SpellingSuggestion
Dim colSuggestions As Word.SpellingSuggestions
' Add a document if there aren't any (needed to get suggestions).
If MSWord.Documents.Count = 0 Then MSWord.Documents.Add
text = Trim$(txtWord.text)
lstSuggestions.Clear
If MSWord.CheckSpelling(text) Then
' The word is correct.
lstSuggestions.AddItem "(correct)"
Else
' The word is incorrect. Get the list of suggested words.
Set colSuggestions = MSWord.GetSpellingSuggestions(text)
If colSuggestions.Count = 0 Then
lstSuggestions.AddItem "(no suggestions)"
Else
For Each suggestion In colSuggestions
lstSuggestions.AddItem suggestion.Name
Next
End If
End If
End Sub
| 圖16-2 一個使用 Microsoft Word 作拼字檢查的範例 |
在 cmdCheck_Click 程序中的關鍵方法是 CheckSpelling，如果傳遞的引數是正確的，則傳回 True，否則傳回 False。在後面的例子中，程式呼叫 GetSpellingSuggestions 方法，並傳回一個包含 0 或是更多 SpellingSuggestion 物件的集合。如果有任何的建議，程式會利用 For Each 迴圈列舉出來並且放入 ListBox 控制項中。
之前的程序使用 New 關鍵字建立了一個 Word.Application 類別執行個體，如同在現在的專案中一般。但是當您與 COM 物件一起工作時，您也可以使用 CreateObject 函數，此函數可以接受類別的名稱：
' An alternative way to create a Word.Application object Set MSWord = CreateObject( "Word.Application")
CreateObject 函數比 New 關鍵字有更多能力，因為您可以在執行期間利用類別名稱字串建立物件，代替直接寫在客戶端的原始碼中。兩種建立 COM 物件的方法中，其他他微妙的差異都包含在此章節中。
使用外在的 Automation 物件是很容易的一件事，前面的例子讓您了解如何利用元件的方法、屬性以及事件。此外，這個簡單的範例證明了 COM 的語言中立（language-neutral）本質。您的 Visual Basic 程式可以使用 COM 來存取其他其他語言所寫的元件，反過來也一樣﹕您可以利用 Visual Basic 來發展元件，然後在其他的發展環境中使用它們。
注意
當宣告以及建立一個屬於外部物件程式庫的物件時，您可以使用 伺服器名稱.類別名稱的全名語法代替單一的類別名稱。這或許是必要的，以解決一些含糊的問題。舉例來說，像是應用程式引用多個外部元件，而兩個以上的物件使用相同的名稱。這種情形比您預期的還要常發生。如果不預防，您可能會遇到一些不易察覺的錯誤。舉例來說，Excel 物件程式庫以及 Word 物件程式庫所提供的應用程式物件。現在，思考一下當 Visual Basic 執行下列程式碼時會如何﹕
Dim x As New Application x.Visible=True
何種視窗會出現，Excel 或是 Word？答案是﹕結果是依據在引用項目對話方塊清單中位於前面的物件程式資料庫。因此引用項目對話方塊中包含兩個優先權的按鈕，讓您更改該項目在清單中的位置。然而，注意到此種彈性的做法會造成一些不易察覺的錯誤。舉例來說，如果您將程式碼複製到另一個擁有不同順序的清單的專案中，則程式不會按照如預期般的工作。因此，筆者建議您應該詳細指明外部物件的全名，除非您百分之百確定您的應用程式不會使用其他他會提供相同名稱的物件程式庫。
建立一個ActiveX EXE伺服器
如果您已經擁有了一個以類別所建構的程式，只需要按滑鼠數下就可以將其轉換成 ActiveX 伺服器。稍後您將會見到，您甚至不需要將應用程式編譯成實際的 EXE 檔案來測試其元件，而可以在 Visual Basic 的整合發展環境中利用環境所給您的所有工具來除錯。
當然，您也可以從功能表的 檔案 選取 建立新專案 ，然後選取 ActiveX EXE 項目來啟動一個 ActiveX 元件。在這種情況下，Visual Basic 建立一個包含 Public 類別模型的專案代替包含表單的專案。
基本步驟
當展示如何實作一個新的技術時，習慣上由一個簡單的例子開始。然而，在這個案例上，我們可以再利用我們在
第七章 所發展的一個以類別為基礎的例子，CFileOp 應用程式。
設定專案屬性
第一件要做的事就是卸載所有不必要的模組。當您將 CFileOp 應用程式轉換為 ActiveX 伺服器時，您不再需要 Form1 表單，因此您可以將表單載出。然而，不要將表單從磁碟上刪除，因為您馬上將需要使用到它。
下一步就是將此專案變成 ActiveX 應用程式，您可以在 專案屬性 對話方塊中的 一般 頁籤做設定。（見圖16-3）您也應該給予專案一個有意義的名稱，舉例來說，FileOpSvr。這個名稱成為程式庫的名稱，此程式庫是客戶端需要引用以使用此應用程式所提供的物件。在 啟動物件 欄位中選擇（無），並且加入對此專案的描述，在這個案例中，把描述設定為 A component for file operations 。這段描述會出現在客戶端程式的 引用 對話方塊中。
最後，到對話方塊的 元件 頁籤並且確定將啟動模式設定為 ActiveX 元件 。此設定告訴 Visual Basic 環境您要如同由其他的應用程式引發一個元件一般地測試目前的專案。不要忘記 ActiveX 應用程式也可以如同一般的 Windows 應用程式一般地執行﹔要測試 ActiveX 元件在某應用程式的行為，將啟動模式設為 獨立的應用程式 。
| 圖16-3 設定 FileOpSvr 伺服器應用程式的「專案屬性」對話方塊的所有屬性。 |
設定類別屬性
FileOpSvr 專案幾乎已可以執行了，但是 Visual Basic 實際上拒絕執行，直到專案內包含至少一個建立好的 Public 類別。因為您轉換一個標準執行檔專案，CFileOp 類別模組的 Instancing 屬性是設定為 1-Private，而 private 類別在外是看不到的。為了符合 Visual Basic 的需求，您必須將屬性更改為 5-MultiUse，意義為此類別為 Public，並且其執行個體可以被客戶端的應用程式所建立。（您需要了解更多有關於執行個體屬性，您將在下一章學習到）
執行伺服器專案
到此，您已準備好要執行伺服器應用程式。如果您按下 F5，會出現一個對話方塊，這是 專案屬性 對話方塊的偵錯頁。確定核取 等待元件建立完 成選項，然後點取 OK 開始執行伺服器。如果所有的設定都是正確的，您將會看到程式在執行，但是沒有任何事情發生。這是正常的的情形﹕Visual Basic 正在等待客戶端的應用程式對此元件請求某一物件。
小秘訣
當執行 ActiveX EXE 或是 DLL 專案時，您應該取消在選項對話方塊中的一般頁籤上的以背景方式編譯選項。如此設定可以確定當程式提供本身的物件給客戶端的應用程式時，不會有編譯或是語法的錯誤發生。在多數的情況中，錯誤會造成您必須停止伺服器和客戶端的應用程式，修正錯誤，然後重新開始。如果您不想要更改整合發展環境的設定，您可以用按下Ctrl+F5的編譯方式代替 F5 的編譯方式或是選取功能表中執行中的全部編譯後開始。
建立客戶端應用程式
現在是回收您在 ActiveX EXE 專案中所捨棄的 Form1 表單的時候了。執行另一個 Visual Basic 環境的執行個體，選擇 標準執行檔專案 ，如果必要的話，移除 Visual Basic 自動建立的 Form1 模組。您必須這樣做以防止名稱的衝突。
此時，您可以選取 專案 功能表中的 新增檔案... 命令，將 CFileOp.Frm 檔案加入到專案中。（您可以使用 Ctrl+D 快速鍵。）您需要將此表單設為此專案的啟動物件，可以在 專案屬性 對話方塊的 一般 頁籤中做此設定。如果您現在執行客戶端的專案，您將會得到一個編譯錯誤的訊息（使用者自訂型態尚未定義），這是由下列在 Form1 模組的宣告程式段中的程式所引起的：
Dim WithEvents Fop As CFileOp
原因是很明顯的：CFileOp 物件對於目前的應用程式而言是外部的物件，要使 Visual Basic 能夠找到此物件，您必須在應用程式的 引用 對話方塊加入對此物件的引用。選取 FileOpSvr 專案很簡單，因為其描述為「A component for file operations」，出現在註冊系統上以字母排列的所有元件的前方。然而，如果您懷疑，只要檢查對話方塊中靠近下面的 位置 欄位。此字串應該指向 VBP 專案檔案，或是如果您尚未儲存此專案，則指向一個位於 WINDOWS TEMP 目錄中的暫存檔。在多個有相同的敘述的元件中找尋所需的元件時，您應該檢查此欄位，此情況常發生在不同版本的相同元件上。
測試客戶端
加入一個引用到 FileOpSvr 專案中之後，就可以執行此客戶端的應用程式，並且可見到應用程式如同原來的以類別為基礎的應用程式一般地執行。然而，所看不到的差異在於所有的物件對於應用程式來說都是外部的，並且利用 COM 與應用程式聯繫。更令人興奮的是您可以如同一個標準的 Visual Basic 專案般地對以 COM 為基礎的應用程式進行偵錯。事實上，您可以使用 F8 功能鍵來追蹤任何跨應用程式的呼叫，您將由客戶端專案的原始程式碼傳送到伺服器的程式碼並再傳回。
顯然地，這個小小的特色實際上卻是一個很大的救難者，當您測試 ActiveX 客戶端和伺服器的程式可以節省您許多時間。
當您已完成測試階段，就應該關閉客戶端應用程式表單，並且按下工具列上的 停止 按鈕以停止伺服器的程式。（這是少數當您按下「停止」按鈕就可以成功停止一個執行的應用程式的情況之一。）如果您嘗試以相反的程序完成這些動作，那麼當您想要停止伺服器時候會出現一個警告，如圖16-4。如果您按下 Yes 按鈕，確定終止伺服器的應用程式，那麼當客戶端的程式嘗試使用 Fop 變數所儲存的物件指標時，應用程式會出現錯誤。
| 圖16-4 如果客戶端正在使用伺服器的物件時，您不應該停止伺服器的應用程式。 |
Instancing屬性
一個類別模組的 Instancing 屬性決定客戶端的應用程式如何藉由 COM 建立以及引用此類別物件。此屬性可以分配六個不同的值，即使不是所有的值都適用於四種專案形式，詳列於表 16-1，您可以在 Visual Basic 中建立﹕
| 標準 EXE | ActiveX EXE | ActiveX DLL | Active X 控制項 | |
|---|---|---|---|---|
| 1-Private | ۷�� | ۷ | ۷�� | ۷ |
| 2-PublicNotCreatable | ۷ | ۷ | ۷ | |
| 3-SingleUse | ۷ | |||
| 4-Global SingleUse | ۷ | |||
| 5-MultiUse | ۷ | ۷ | ||
| 6-Global MultiUse | �� | ۷ | ۷ |
| 表16-1 不同專案類型中所適用的 Instancing 屬性 |
選擇最適當的設定
您需要了解各種可能的 Instancing 屬性的設定之間的差異。在執行時，您不能閱讀和更改列於 屬性 視窗中類別的屬性值。不同於控制項的屬性，類別的屬性是只適用於設計階段的屬性。Instancing 屬性可能的設定列於下一頁中。
Private ﹕Private 類別模組在目前的專案以外是看不到的。換句話說，不只是客戶端的應用程式不能建立此種類型的類別，甚至不可以引用這些類別。事實上，伺服器的應用程式不允許傳送一個 Private 類別的執行個體到客戶端。（舉例來說，如同一個 Function 的傳回值或是一個 Procedure 的參數）。在標準的 EXE 專案中所有的類別模型都是 Private，因此，在這些專案中執行 Instancing 屬性是不適用的。
PublicNotCreatable﹕ 這些類別是外在的專案可以看到的，但是客戶端的應用程式不能直接建立類別的執行個體。這句話的意思是，客戶端可以宣告這些類別型態變數以及利用 Set 命令指派物件引用，但是不可以使用 New 運算子或是 CreatObject 函數來建立這些類別的執行個體。客戶端要得到 PublicNotCreatable 類別合法的引用唯一的方法就是請求伺服器傳回引用，舉例來說，透過其他類別的方法。因此，Visual Basic 提供所有的 ActiveX 專案包含至少一個可建立的類別。
SingleUse﹕ SingleUse 物件是公開並且是可建立的，所以客戶端可以宣告類別變數並且使用 New 運算子或是 CreatObject 函數建立執行個體。當一個新的物件被客戶端建立，COM 載入一個新的伺服器執行個體，每次位於不同的位址空間。舉例來說，當一個客戶端應用程式建立十個 SingleUse物件，COM 執行十個不同的處理序，每個處理序提供一個物件的執行個體。
MultiUse﹕ MultiUse 物件是公開並且是可建立的，但是不同於 SingleUse物件，單一元件的執行個體提供客戶端應用程式所請求的所有物件。這是在 ActiveX EXE 或是 ActiveX DLL 中加入的物件模組的預設值，也是在大多數的情況中最適用的設定。
GlobalSingleUse以及GlobalMultiUse﹕ 這分別是 SingleUse 以及MultiUse 的變數的設定。一般全域（Global）物件在後面的章節中描述。
Private以及Public物件
一個類別最重要的特性就是其範圍（Scope）。如果執行個體（Instancing）屬性是 1-Private，在伺服器以外沒有任何類別執行個體可以看的到。在其他的屬性中，這些物件可以被客戶端應用程式操作並且可以自由地由伺服器傳遞至客戶端，反之亦然－舉例來說，如參數傳至方法或是屬性以及函數的傳回值。
如果一個客戶端的應用程式可能得到一個伺服器 Private 物件的物件引用，一連串嚴重難以處理的事情可能會發生，包含致命的錯誤或是甚至是 GPE 錯誤。很幸運地，您不會執行任何嚴重的危險程式，因為 Visual Basic 編譯器會阻止從伺服器傳回 Private 物件至客戶端。舉例來說，如果您的伺服器元件定義了一個 Private 類別，並且您建立一個擁有會傳回 Private 類別的執行個體的 Public 方法的 Public 類別，
Visual Basic 會產生一個如圖16-5的錯誤訊息。當您嘗試傳遞客戶端一個元件的 BAS 模組中的使用者自訂型態（UDT）時，也會發生相同的錯誤訊息。這是因為在 BAS 模組中的所有定義都視為 Private，縱使使用 Public 關鍵字做宣告也是如此。
| 圖16-5 對伺服器而言，傳遞 Private 物件以及資料結構給予客戶端都是不合法的。 |
MultiUse 以及 SingleUse 物件
要了解 SingleUse 以及 MultiUse 物件之間的差異，您必須要記住的是除非您明白地請求其建立多執行緒的元件（多執行緒包含在後面的〈多執行緒 ActiveX 元件〉的章節中），不然 Visual Basic 建立單一執行緒的元件。
一個單一執行緒 MultiUse 元件只可以在同一時間服務一個客戶端﹔換句話說，即使元件提供許多物件給其客戶端，在特定的時間內只有一個物件可以執行程式。所以如果分別有兩個客戶端同一時間對元件中的物件提出請求，將只有一個客戶端會被直接地服務，另一個客戶端必須等到第一個物件中的方法完成執行後才會執行。然而，沒有任何請求會遺失，因為 COM 自動地排列好所有客戶端的請求﹔請求會被延緩並放置在佇列中。每個請求將會留在佇列中直到在每個請求的佇列之前的工作都完成以後。
這個 同時一項工作 （one-thing-at-a-time）的限制已經被多執行緒 MultiUse 元件打破了，MultiUse 元件可以建立執行的多執行緒，每個執行緒提供一個不同的物件。因此多執行緒元件可以服務多個客戶端，不會因為一個客戶端阻礙而影響到其他其他的客戶端。
相反地，每個 SingleUse 物件是由不同的處理序（process）所提供的。SingleUse 物件主要的優點在於它們可以多工（Multitask）。換句話說，每個單獨的 SingleUse 類別執行個體在不同的處理序中執行，SingleUse 物件比 MultiUse 物件需要較多的記憶體以及系統資源。總體來說，您可以假設每增加一個 SingleUse 物件需要大約 800KB 的記憶體，因此很明顯地，當您想像建立上千上百個物件時您不可以使用 SingleUse 物件。實際上，在高階系統上您不能執行超過數十個的 SingleUse 物件。這是因為當太多的處理序在執行時，您的 CPU 花費在處理序轉換上的時間比實際上執行處理序程式碼的時間還要多。
另外一個 SingleUse 元件的問題就是您不能在 Visual Basic 的環境中做完整的測試。IDE 只能提供一個 SingleUse 物件，當客戶端請求第二個 SingleUse 物件時，提供 SingleUse 物件的 Visual Basic 執行個體會顯示一個錯誤訊息。出現錯誤訊息的幾秒中之後，客戶端的應用程式收到一個代號 429 的錯誤訊息「元件無法建立物件或傳回引用到此物件」。要完整的測試一個 SingleUse 元件，您必須將 SingleUse 元件編譯成 ActiveX EXE 檔案並且以您的客戶端引用這個 EXE 檔案來代替 Visual Basic 環境所提供的元件。
所有的事情考慮後，您的最佳選擇通常就是建立單一執行緒或是多執行緒的 MultiUse 物件。這也是較容易達成的方法，感覺上您可以提供 10、100 或甚至 10000 個物件而不會消耗掉您的系統所有的記憶體以及 CPU 時間。當您利用同處理序（in-process）ActiveX 時，您沒有別的選擇。因為一個 ActiveX DLL 與客戶端在同一位址空間執行，不可能在不同的位址空間建立同一元件的多個執行個體。因此，ActiveX DLL 專案不支援 SingleUse 屬性。
不論您的決定是什麼，最重要的一點是在相同的 ActiveX EXE 伺服器內您絕不應該混合 MultiUse 以及 SingleUse 物件（或是它們的 Global 變數）。如果您如此做，您沒有對 MultiUse 物件所提供元件的特別執行個體的控制，並且一個特定的客戶端可能所擁有的物件是不同執行個體所提供的，這些事情都是您應該避免的。
實際上，如果一個 SingleUse 元件是一個物件的階層，您要使階層的根物件成為唯一一個可建立的物件並且使階層中所有其他的 Public 物件為 PublicNotCreatable.。您也要提供您的客戶端一定數量的建構式（Constructor method）以擁有建立每個如此相關物件的執行個體的服務。需要更多的物件階層以及建構式的訊息，見 第七章 。
內部的執行個體（Internal instancing）
一個 ActiveX 伺服器可以讓定義在自己 Visual Basic 專案內的物件成為執行個體。在此情形下，物件受到物件如何被建立以及使用的影響，角色有些微不同：
從所有 COM 的成本來看，對於定義在同一個專案中的 Public 物件使用 CreateObject 建立執行個體要比使用 New 運算子慢上四、五倍也不應該感到驚訝。因此，一般來說，應該避免 CreateObject。（見稍後此章中的〈多執行緒 Visual Basic 應用程式〉對於此角色的例外）
全域（global）物件
全域和非全域 SingleUse 以及 MultiUse 物件唯一的差別在於當引用到全域物件的方法以及屬性時，您可以忽略掉全域物件的宣告。讓我們用一個例子來解釋﹕
假設您擁有一個包含數學計算方法的物件，例如﹕
' In the Math class of the VBLibrary project
Function Max(x As Double, y As Double) As Double
If x > y Then Max = x Else Max = y
End Function
如果您使這個物件為 GlobalMultiUse 或是 GlobalSingleUse，您在 Visual Basic 客戶端應用程式中可以不用明確地建立一個指到此物件執行個體的物件變數就能引用到 Max 方法。這非常的便利，因為這是一種 Visual Basic 語言程式庫的延伸。
'In the client application Print Max(10, 20) 'This works!
換句話說，您可以建立一個可以顯示 sub 以及 function 方法的類別，您可以如同命令以及函數般地在您的客戶端個別地顯示這些方法。您不會被方法所限制因為您的類別可以顯示屬性，並且其客戶端見到這些屬性如同這些屬性是變數一般。舉例來說，您可以在 Visual Basic 中加入常數﹕
'A read-only property in the VB2TheMax.Library class Property Get Pi() As Double Pi = 3.14159265358979 End Property ' In the client program Circumference = Diameter * Pi
然而，您應該注意下列幾個要點。即使您忽略宣告一個指到一個類別執行個體的變數，並且仍然存取其屬性以及方法，所忽略的步驟只是 Visual Basic 提供您在語法上的便利。事實上，在此背後，語言建立了一個隱藏的適當型態的物件變數，並且當每次取用一個類別的成員時使用此變數。此動作表示您使用一個全域物件並不能加快您程式的速度。相反的，隱藏的引用是由 auto-instancing 變數所實作出來的，所以當您存取全域物件的方法以及屬性時要付出一點點的成本，因為 Visual Basic 要決定是否要建立一個新的執行個體。
進一步地，因為您對這個隱藏的變數沒有控制權，所以您不能將它設定為 Nothing，所以這個物件只有在應用程式結束時才會消滅。這一點通常沒有關係，但是當物件取用很多記憶體以及資源時可以變得有意義些。
令人關心的是您可能使用全域變數多年但不知道它的意義。事實上，VBA 程式庫只不過是全域物件的集合﹔您可以利用物件瀏覽器瀏覽 VBA 函式，您會看到一些名稱為 Math、Strings 等模組名稱。每個模組提供一些方法。因為每個模組標記為「全域」，所以您可以在 Visual Basic 應用程式中顯示這些方法如同是原生函數一般。相同地，Visual Baisc 程式庫（在物件瀏覽器中名稱為 VB）包含一個全域模組，提供所有語言所支援的模組，例如 App、Printer 以及 Clipboard。需要更多的資訊，見第七章 〈Subclassing the VBA Language〉 。
因為全域物件典型上用於建立程式庫，往往被實作為同處理序（in-process）ActiveX 元件。在隨書光碟中，您可以找到關於這個觀念方面一個較複雜的例子一VB2TheMax 元件，包含了 Visual Basic 語言中許多 math、date、time、string 以及 file 的函數以及命令所延伸出的十七個類別以及一百七十個以上的方法。
這裡有兩個您需要知道有關於全域物件更重要的說明。
第一， 這樣的物件只有在專案之外才是全域的。在元件的專案中，它們是一般的物件，必須如一般的物件一樣，宣告以及建立執行個體。
第二， 如同此時所寫的，Visual Basic 只是一個建立支援全域物件的客戶端的發展環境，您可以在 COM 相容的程式語言中使用您的全域物件程式庫，但在這些程式語言中，您的全域物件被視為一般的 SingleUse 或是 MultiUse 物件。
在應用程式間傳遞資料
COM 好用的地方在於元件和其客戶端可以把資料傳回、傳出，並且不需要您擔心通訊上所有基本的核心細節。然而，如果您能稍微了解 COM 在背後所做得做的事，您一定可以寫出更好的程式。
外部參數傳遞（Marshaling）
外部參數傳遞（Marshaling）是 COM 每次執行時，資料需要從客戶端傳送到跨處理序伺服器並傳回的一種作業。外部參數傳遞（Marshaling）是一個複雜的程序：因為 ActiveX EXE 伺服器和其客戶端位於不同的位址空間，元件並不能直接看到儲存在客戶端位址空間的變數，反之亦然。考慮當客戶端執行下列程式碼會發生何事：
Dim x As New MyServer.MyClass, value As Long value = 1234 x.MyMethod value
當您利用傳址傳遞一個變數，呼叫的程序會接收到變數的位址。然後這個位址接收或是可能修改這個變數。然而，當呼叫起源於另一個處理序，呼叫的程序將可能無法存取變數的值，因為變數位於另一個位址空間並且所收到的位址對於程序來說沒有什麼意義。但是您知道傳遞一個變數到一個跨處理序伺服器，實際上可以正常工作，所以如此要感謝 COM marshaling。要詳細的解釋 marshaling 如何工作超出了本書的範圍，但是下列的解釋足以滿足我們的目的。(見圖16-6。)
| 圖16-6 COM marshaling 如何工作 |
當您與 ActiveX EXE 元件一起工作時外部參數傳遞（Marshaling）才是必要的。因為同處理序元件是在客戶端的位址空間執行，它們可以直接的存取以及修改所有客戶端的變數。這說明了為何 ActiveX DLL 元件較跨處理序元件快上許多。
外部參數傳遞（Marshaling）的技術是很複雜的。舉例來說，如果一個參數值以傳址傳遞，stub 在伺服器的位址空間建立一個暫存的參數值並且傳遞這個變數的位址給予方法。如此方法中的程式碼可以存取以及更改此變數值。當方法傳回時（returns），stub 讀取新的變數值，包裝起來，並且傳回代理伺服器模組，代理伺服器模組將原來記憶體位置中的變數值用新的值替換。
除了允許資料交換之外，外部參數傳遞（Marshaling）技術促使了「location transparency」的概念，「location transparency」是元件的本質。客戶端的程式碼不需要知道伺服器的位址，同時伺服器也不需要知道何處正在呼叫。事實上，元件中同樣的方法可以被外部或是元件內部本身呼叫，並且這兩種方式都將以相同的方式工作。
「location transparency」的概念是很重要的，因為「location transparency」保證當物件備部署在網路上遠端的電腦上，物件可以繼續工作。在這種情況下，代理伺服器和 stub 模組間的通訊更加複雜因為需要依賴 RPC（Remote Procdure Call）以便在各電腦間工作。但是 COM 處理了所有的問題。您客戶端以及伺服器的應用程式將如以前一般的工作。
簡單的資料型態
要正確的使資料傳出以及傳入，COM 有義務知道資料儲存的格式。以 Visual Basic Strings 來舉例﹕當客戶端傳遞一個 string 給一方法，實際上是傳送一個指到實際資料的 32bit 指標。代理伺服器中的方法知道接收到一個 string 因此可以瞥見到客戶端的位址空間以接收實際的字元資料。
所有 Visual Basic 簡單資料型態都與 COM 所能處理的資料相容。這表示一個伺服器可以傳回客戶端任何的 numeric、string 或是 Variant value。從 Visual Basic 6 開始，一個伺服器可以傳回任何型態的陣列。（以 Visual Basic 之前的版本所寫的伺服器只能傳回存在 Variants 的陣列。）
以 Visual Basic 4 或是 5 所編譯的元件不能傳回使用者自訂型態（UDT）到客戶端。Visual Basic 6 允許元件傳送一個「使用者自訂型態」，此「使用者自訂型態」是要定義在 Public 類別中並且您需要安裝 DCOM98 或是在 Windows NT 4 中安裝 Service Pack 4。安裝 Windows 98 會自動安裝 DCOM98。即使在寫作的同時 Windows 2000 還沒有發行，期望 Windows 2000 不需安裝任何 Service Pack 就支援此項特色應是合理的。不要忘記 DCOM98 或是 Service Pack 4 也必須安裝在您顧客的電腦上。如果沒有安裝，Visual Basic 會產生一個執行錯誤 458，「 Variable uses an Automation Type not supported in Visual Basic.」。您應該抓住此錯誤訊息並且顯示一個更有意義的訊息給您的使用者，例如建議他們應該升級他們的作業系統以支援此項特色。
因為「使用者自訂型態」必須定義在一個 Pubic 類別中，所以您不能傳遞定義在客戶端的「使用者自訂型態」到伺服器，除非客戶端是一個 ActiveX EXE 程式本身。最後，注意到 DCOM98 或是 Service Pack 4 只有在您的元件傳遞「使用者自訂型態」參數給跨處理序伺服器時才需要。當您與 ActiveX DLL 一起工作時，不會有外部參數傳遞（marshaling）發生並且不論在 Windows 95 或是 Windows NT 4 系統上「使用者自訂型態」都可以傳回客戶端。
Private 以及 Public物件
一個伺服器以及一個客戶端可以相互傳遞 Public 物件。其中包含定義在伺服器的物件以及外部程式庫所提供的物件，例如 Microsoft Word 或是 Microsoft Excel 物件程式庫。
筆者將會稍微深入描述關於物件外部參數傳遞（marshaling）的細節。除了在專案中的類別模組中所定義的物件之外，一個 Visual Basic 應用程式處理三個程式庫所提供的物件：Visual Basic、VBA 以及 VBRUN 程式庫。這三種程式庫在物件的顯示上看起來似乎一樣（但是它們是不同的）。
所有由 Visual Basic 所提供的物件對於提供的程式庫都是 private，所以不能傳遞給其他其他的應用程式（舉例來說，表單物件、App 物件，以及所有內建控制項。），縱使其他的應用程式是由 Visual Basic 所寫的。舉例來說，假如在您的伺服器中有一 Public 類別包含下列程式碼：
‘This function can't appear in a Public class module.
Function CurrentForm() As Form
Set CurrentForm = Form1
End Function
編譯器會拒絕執行這個應用程式。相反地，由 VBA 以及 VBRUN 程式庫所提供的物件是 Public 的，所以可以在不同的處理序之間傳送。這裡包含了 ErrObject 以及 Collection 物件（在VBA程式庫中）。
許多程式設計人員發現一個嚴重的限制，那就是在伺服器和客戶端之間不能傳遞一般的物件，例如表單以及控制項，並且找尋更改的方式。
更改的方式實際上是有的﹔只要使用 As Object 或是 As Variant 宣告方法的參數以及傳回值代替明確的宣告類型：
‘In the MyClass public module of the MyServer ActiveX EXE project
‘Assumes that the project contains a Form1 form and a Text1 text box on it
Function CurrentField() As Object
Set CurrentField = Form1.Text1
End Function
' In the client project
Dim x As New MyServer.MyClass
Dim txt As Object
Set txt = x.CurrentField
txt.Text = "This string comes from the client"
客戶端的應用程式宣告一個一般的 As Object 變數接收CurrentField 方法所傳回的結果，意思是您要做晚期連結。如同您所知道的，晚期連結缺乏效率並且無法讓您使用 WithEvents 關鍵字。
使客戶端應用程式使用特定的物件變數宣告物件對於同處理序 ActiveX 伺服器來說是比較好的事。但是您應該注意到用此方法建立的 DLLs 在某些情況下可能無法正常的工作，所以堅持使用 As Object 變數通常是合理的，即使是與同處理序元件一起工作。同時請不要忘記只有在客戶端的應用程式是以 Visual Basic 撰寫時才能使用這種方法。
現在筆者已經告訴您更改的方式，附加一點，就是 Microsoft 明確地不允許這個技巧，並且警告在之後的 Visual Basic 版本中可能不能執行。所以使用這個方法要自行負責。
這個問題也產生一個有趣的問題﹕客戶端的應用程式如何存取位於伺服器應用程式的表單以及控制項?答案是客戶端應該從來不會直接存取伺服器的 Private 物件，因為這樣會破壞元件的封裝性。如果客戶端需樣使用伺服器的 private 物件，伺服器應該實作出一些用來提供請求的方法以及屬性，舉例來說﹕
Property Get CurrentFieldText() As String
CurrentFieldText = Form1.Text1.Text
End Function
Property Let CurrentFieldText(newValue As String)
Form1.Text1.Text = newValue
End Property
注意Friend 方法以及屬性不會出現在元件的 Public 介面中，所以不能被外在的專案所呼叫。因此，它們不需要外部參數傳遞（marshaling），並且您可以傳遞一個 Private 物件或是一個使用者自訂型態當作是 Friend 成員的參數或是回傳值。
說明
不要忘記當您在外部參數傳遞（marshal）一個物件，實際上正傳遞一個引用，而不是物件本身。當客戶端使用這個物件的方法以及屬性的時候，這些方法以及屬性的實際程式是在元件中執行。這個特性是很重要的，因為每一次客戶端使用物件變數時，就會發生一個到遠端物件的來回旅程。
類型程式庫
您可能會納悶 COM 是如何建立代理伺服器以及 Stub 來讓客戶端和伺服器聯繫。答案就在類型程式庫中，類型程式庫集合了元件提供的 Public 類別的所有有關資訊，包含了個別方法的語法、屬性以及事件。類型程式庫通常儲存為副檔名為 TLB 或是 OLB 的檔案，但是它也可以嵌在元件本身的 EXE、DLL 或是 OCX 檔案中。舉例來說，Visual Basic 編寫的元件的類型函數庫儲存在元件的 EXE 或是 DLL 檔案中。
如果一個元件擁有類型程式庫，您就可以在引用對話方塊中選取並且使用物件瀏覽器查詢。引用對話方塊列出所有的已經註冊在登錄資料庫中的類型函數庫。如果您有一個類型函數庫尚未註冊，您可以按下 瀏覽 將物件加入登錄資料庫中。
一般而言，您不用將物件加入引用對話方塊就可以使用物件，但是您必須使用 CreateObject 函數建立物件並且只能透過一般的 As Object 變數引用。事實上，沒有類型函數庫，Visual Basic 便沒有足夠的資訊讓您宣告一個特定的物件變數，所以您被限制在使用晚期連結。要使用特定的變數（早期連結）、New關鍵字以及 IntelliSense，您必須把伺服器的類型函數庫加到引用列表中。
小秘訣
Visual Basic 可以建立單一的類型函數庫，但是您需要企業版的 Visual Basic。要領是簡單的，在專案屬性對話方塊」的元件頁籤中，核取遠端伺服器檔案，然後重新編譯專案。Visual Basic 產生一個與專案名稱相同的 TLB 檔案。
效能建議
現在您知道到資料如何在客戶端以及伺服器之間作外部參數傳遞，您可以了解一些巧妙的技巧以增進您 ActiveX EXE 元件的效能。
一個非常有效的建議就是您應該在宣告方法的參數時多使用 ByVal 代替 ByRef （除非程序實際上要更改參數值以及要傳回客戶端）。傳值參數不會以外部參數傳遞的方式傳回客戶端因為 COM 知道在呼叫期間變數值不能更改。
理想的狀況是當您呼叫一個 Sub 程序時，將所有的參數宣告為 ByVal， 因為在這種情況下沒有資料會傳回客戶端，當傳送長字串時您可能會有最佳體認。舉例來說，筆者發覺利用 ByVal 宣告的字串傳遞速度比利用 ByRef.宣告快上約百分之二十。
跨 process 的呼叫本質上就慢。呼叫一個四個參數的方法幾乎要比設定四個屬性慢四倍。因此，您的伺服器應該提供讓客戶端快速設定以及存取屬性的方法。舉例來說，您的伺服器提供 Name、Address、City 以及 State 屬性。除了提供一般的屬性設定程序以外，您可以增加下列 GetProperties 以及SetProperties 方法：
' In the MyClass module of the MyServer project
Public Name As String, Address As String
Public City As String, State As String
Sub SetProperties(Optional Name As String, Optional Address As String, _
Optional City As String, Optional State As String)
If Not IsMissing(Name) Then Me.Name = Name
If Not IsMissing(Address) Then Me.Address = Address
If Not IsMissing(City) Then Me.City = City
If Not IsMissing(State) Then Me.State = State
End Sub
Sub GetProperties(Optional Name As String, Optional Address As String, _
Optional City As String, Optional State As String)
If Not IsMissing(Name) Then Name = Me.Name
If Not IsMissing(Address) Then Address = Me.Address
If Not IsMissing(City) Then City = Me.City
If Not IsMissing(State) Then State = Me.State
End Sub
因此客戶端的應用程式可以使用一行程式就設定以及存取所有的屬性（或是其中的一部份集合）。
'Set all properties in one statement. Dim x As New MyServer.MyClass x.SetProperties "John Smith", "1234 East Road", "Los Angeles", "CA" ' Read just the City and State properties. Dim city As String, state As String x.GetProperties city:=city, state:=state
您可以使用指定名稱變數大大增加程式的可讀性，如同前面的程式片斷一般。
其他他解決跨 process 的呼叫的方法是利用陣列傳遞所有的參數。您可以使用 Variants 陣列，因為它們可以傳遞不同類型的參數值。當然，客戶端和伺服器都必須同意傳遞陣列中的資料意義。
當您不知道您要傳遞多少資料項目給伺服器時，這是最有效率的處理方式。舉例來說，假設伺服器提供一個 Public 集合類別，擁有一般的 Add、Remove、Count 以及 Item 方法。您可以考慮提高這個應用程式的效率，如果您提供一個 AddMulti 方法，此方法每呼叫一次可以加入一個以上的項目：
' In the MyCollection modules of the MyServer project
Private m_myCollection As New Collection
Sub AddMulti(values As Variant)
Dim v As Variant
For Each v In values
m_myCollection.Add v
Next
End Sub
注意到 values 參數宣告為 Variant 代替宣告成 Variants 的陣列，如同您所預期的，程序利用一個 For Each...Next 迴圈重複地輸入成員。這給予此方法無比的彈性，因為您幾乎可以傳遞任何東西：Strings 的陣列、Variants 的陣列、物件的陣列以及包含 Strings 陣列的 Variant、Variants、物件甚至是一個集合：
' In the client application
Dim x As New MyServer.MyCollection
' Pass an array of Variants built on the fly.
x.AddMulti Array("First", "Second"," Third")
相同地，如果客戶端的應用程式需要存取儲存在 MyCollection 模組中所有的變數值，您可以實作一個利用 Variants 陣列傳回所有集合中的項目的方法來提高效率：
Function Items() As Variant()
Dim i As Long
ReDim result(1 To m_myCollection.Count) As Variant
For i = 1 To m_myCollection.Count
' Object values require the Set command.
If IsObject(m_myCollection(i)) Then
Set result(i) = m_myCollection(i)
Else
result(i) = m_myCollection(i)
End If
Next
Items = result
End Function
您可以參考 Dictionary 物件來讓伺服器的介面更有效率且提供更好的效能。（見第四章
〈Dictionary Objects〉 ）最後，您可以利用在元件中宣告為 Public 的使用者自訂型態在客戶端以及伺服器之間傳遞資料。
錯誤處理
在 COM 程式設計中您必須要做的很重要的部分就是錯誤處理。當然，錯誤處理一直都是重要的，但是當您撰寫 ActiveX 元件時，您必須正確地考慮到所有不可預期的錯誤。
伺服器元件中的錯誤處理
元件中產生的錯誤如同在一般的程式中發生的錯誤一樣；如果目前的程序沒有主動的錯誤處理機制保護，則程序會直接離開並且將控制權傳回給呼叫者。如果呼叫者也沒有錯誤處理機制，控制權會再傳給目前程序的呼叫者，控制權一直傳下去，直到應用程式遇到擁有錯誤處理機制的呼叫程序，或是一直到沒有呼叫的程序為止。（就是到達最頂端的程序並且錯誤沒有被接收。）在最後的例子中，錯誤是非常嚴重的，並且應用程式會終止。
在元件中的屬性以及方法一直會有一個呼叫者就是客戶端應用程式，所以就某方面來說程序中的程式碼受到保護而不至於產生「致命性錯誤」，因為所有的錯誤都會傳回客戶端。事件程序是這個規則中的例外，因為它沒有直接的呼叫者，所以您應該確定在 Class_Initialize 以及 Class_Terminate 事件程序中不會發生錯誤。
縱使方法以及程序中的錯誤會傳回客戶端，一個好的程式設計人員要能夠先控制這些錯誤。基本上，您可以採用下列三種策略之一：
當傳回一個自訂錯誤給客戶端時，您可以在遵循 COM 的指導手冊來處理它。根據這樣的說明文件，所有的自訂錯誤碼的範圍應該在 512 到 65535，如此才不會與 COM 本身的錯誤碼混淆，並且應該加上十六進位的值 &H80040000（或是 -2,147,221,504）。Visual Basic 對於這個值訂定了一個符號常數，vbObjectError，所以在 ActiveX 伺服器內一個基本的 Visual Basic 錯誤處理機制可能類似下面的程式碼：
Function Evaluate() As Double
On Error GoTo ErrorHandler
' Open an initialization file (omitted).
' ...
' Evaluate the result. (This is just a sample expression.)
Evaluate = a * b(i) / c
Exit Function
ErrorHandler:
Select Case Err
Case 6, 11 ' Overflow or division-by-zero error
Err.Raise Err.Number ' can be returned to clients as is.
Case 53
Err.Raise 1001 + vbObjectError, , _
"Unable to load initialization data"
Case Else
'It's always good to provide a generic error code.
Err.Raise 1002 + vbObjectError, , "Internal Error"
End Select
End Function
不論您決定採取何種策略，有一件事是您絕對不應該做的，那就是顯示一個對話方塊。一般來說，元件應該委託錯誤給客戶端並且讓客戶端決定是否要讓使用者了解發生的錯誤。從元件內顯示一個對話方塊是不好的程式設計，因為這樣會使應用程式無法執行遠端的物件。
在客戶端應用程式的錯誤處理
在客戶端應用程式中的一個正確的錯誤處理比在伺服器中來的重要，因為大多數的例子中客戶端並沒有呼叫者可以供其委託錯誤，所以所有的錯誤都必須要在此處理。即使您有絕對的把握伺服器不會產生錯誤（舉例來說，當您只是簡單地存取一個屬性。），筆者強烈建議您無論如何還是要提供錯誤處理機制。原因是當您和 ActiveX 元件一起工作時，您也會由 COM 本身導致錯誤的產生。下面列出幾項由 COM 產生的錯誤。
這裡所列出的並不是很詳盡，您應該在您的錯誤處理機制中記錄其他他錯誤。總結來說，在客戶端應用程式中典型的錯誤處理機制應該記錄三種不同錯誤發生的來源：伺服器、COM 以及客戶端本身。底下便是一個可能的 Visual Basic 客戶端的錯誤處理機制：
Private Sub cmdEvaluate()
Dim x As New MyServer.MyClass' res As Double
On Error GoTo ErrorHandler
res = x.Evaluate()
Exit Function
ErrorHandler:
Select Case Err
Case 429 ' ActiveX can't create the component.
MsgBox "Please reinstall the application", vbCritical
End
Case 430 ' Automation error
MsgBox "Unable to complete the operation at this time." _
& "Please try again later.", vbCritical
Case 462 ' The remote server machine is unavailable.
MsgBox "Please ensure that the server machine " _
& " is connected and functioning", vbCritical
Case 1001 + vbObjectError
MsgBox "Please copy the file VALUES.DAT in the " _
& "application directory.", vbCritical
Case 1002 + vbObjectError
MsgBox "Unknown error. Please contact the manufacturer." _
,VbCritical
Case Else
' This might be a standard Visual Basic error or COM error.
' Do whatever is more appropriate for your application.
End Select
End Sub
「元件忙碌」以及「擱置元件的請求」
如同筆者之前所提到的，COM 將來自客戶端的所有請求循序化，所以伺服器可以用「先進先服務」的方式處理所有的請求。但是在某些情況下，COM 不能接受客戶端的請求﹔這就稱作元件忙碌（component busy）。舉例來說，當您的程式利用 Microsoft Excel 當作伺服器，而 Excel 正在展示一個強制回應（modal）的對話方塊時，會發生這樣的情形。
Visual Basic 假設這是一個暫時性的問題而自動間隔地重試。如果問題持續出現，Visual Basic 會顯示一個 元件忙碌中 對話方塊，如圖16-7 所示。 切換至... 按鈕啟動其他其他的應用程式並且將啟動的視窗帶到所有視窗的最上層，如此您可以改正這個問題。（這個選項對於沒有使用者介面的 ActiveX 伺服器沒有作用。） 重試 按鈕讓您重試這個操作十秒鐘。最後，如果您點取 取消 的按鈕，您撤銷了這項請求並引發一個錯誤 &H80010001 (十進位 -2,147,418,111)傳回客戶端。這是另一個您必須記錄在錯誤處理機制的錯誤。
| 圖16-7 「元件忙碌中」對話方塊 |
另一個不同的問題發生在 COM 接受了客戶端的請求，但是 COM 接受的請求太多以至於這項請求無法完成。舉例來說，這會發生在當元件等候一項查詢完成時，或是顯示一個訊息方塊並等候使用者關閉對話方塊。這些問題造成擱置元件請求（component request pending），伺服器常常因為意料之外的錯誤停止，而在偵錯階段這種錯誤是相當常見到的。
因為 COM 已經接受了請求，Visual Basic 不會重新遞送一次。但是直到方法傳回結果，客戶端的應用程式已經失效並且不能接受使用者的輸入。五秒以後，如果使用者試著與客戶端應用程式交談，一個如圖 16-8 的對話方塊就會出現。這個對話方塊與 元件忙碌 中對話方塊類似，但是 取消 的按鈕不能使用，因為請求是不能被撤銷的。
| 圖16-8 請求被擱置時的「暫停處理元件的請求」對話方塊 |
一些 Application 物件的屬性影響到這些對話方塊的行為以及表現。App.OLEServerBusyTimeout 屬性為在多少毫秒之後會出現 元件忙碌中 對話方塊。（預設值為 10000 毫秒）。App.OLEServerBusyMsgText 以及 App.OLEServerBusyMsgTitle 屬性讓您設定對話方塊的內容以及標題。如果您設定非空字串給予這兩個屬性，標準的 元件忙碌中 對話方塊會被置換成一個包含 確定 以及 取消 按鈕的一般訊息方塊。您可以將 App.OleServerBusyRaiseError 屬性設定為 True 來要求 Visual Basic 不要顯示 元件忙碌中 對話方塊。在這種狀況下，不會顯示任何訊息，而且錯誤 &H80010001 會直接傳回客戶端。（這跟使用者按下 元件忙碌中 對話方塊中的 取消 按鈕所產生的錯誤一樣）。
有一組相似的屬性可以讓您自訂 擱置元件的請求 對話方塊：App.OleRequestPendingTimeout（預設值是 5,000 -也就是五秒），App.OleRequestPendingMsgText 以及 App.OleRequestPendingMsgTitle。
當您的應用程式是與遠端元件往來時，自訂 元件忙碌中 對話方塊以及 暫停處理元件的請求 對話方塊就特別的重要。預設的暫停時間通常都不夠，所以對話方塊很可能會出現。當與遠端元件工作時， 切換至... 的按鈕沒有作用，所以您應該提供一個訊息向使用者解釋發生了什麼事。
包含使用者介面的元件
ActiveX EXE 一個主要的優點就是使用者可以如同執行標準的 Windows 應用程式一般的啟動元件，這樣增加了許多彈性但是也製造了一些小小的問題。
決定啟動模式
舉例來說，應用程式必須決定是使用者執行的或是 COM 子系統執行的。在前者的例子中，應該顯示一個使用者介面，該介面由載入應用程式的主表單來達成。一個 ActiveX EXE元 件可以分別這兩種狀況，可以在 Sub Main 程序中藉由查詢 App 物件的 StartMode 屬性來達成。
Sub Main
If App.StartMode = vbSModeStandalone Then
' Being launched as a stand-alone program
frmMain.Show
Else ' StartMode = vbSModeAutomation
'Being launched as a COM component
End If
End Sub
為了使之前的程式碼可以工作，您應該在 專案屬性 對話方塊中的 一般 頁籤中設定 Sub Main 為啟動物件。一個忠告：當伺服器由 COM 啟動，Visual Basic 執行 Sub Main 程序以及建立物件的執行個體，然後 COM 把物件傳回給客戶端。如果在 Sub Main 程序或是在 Class_Initialize 事件程序中花太多時間則此呼叫會因為暫停而失敗。因此，您絕不應該在這些程序中執行花費許多時間的指令，例如資料庫的查詢。
顯示表單
一個 ActiveX EXE 元件可以如同一般應用程式顯示一個以上的表單。舉例來說，元件可能是一個資料庫的瀏覽器，可以如單獨的程式一樣工作或是如元件一樣由別的應用程式所引發。
然而，當程式如COM元件一般的工作時（App.StartMode =vbSModeAutomation），客戶端是位於前景的應用程式，且視窗可能包含了伺服器的表單。這會造成一個問題，而很不幸地，Visual Basic 沒有方法可以保證表單會在視窗的最上方。舉例來說，表單物件的 ZOrder 方法把表單帶到同一應用程式所有表單的上方，但是並不必然在所有應用程式視窗的最上方。這個問題的解決方式是呼叫 SetForegroundWindow API 函式：
' In the server application
Private Declare Function SetForegroundWindow Lib "user32" _
(ByVal hwnd As Long) As Long
' A method that displays a modal window
Sub DisplayDialog()
frmDialog.Show
SetForegroundWindow frmDialog.hWnd
End Sub
不幸地，在 Windows 98 下 Microsoft 改變了函式工作的方式，所以從前的方法在現在的作業系統上可能不能工作。解決此問題的方式之一是：由 Karl E. Peterson所發明，出現在 1999 年二月發行的 Visual Basic Programmer's Journal中 的「Ask the VB Pro」專欄。
Visual Basic 6 對於 MsgBox 命令提供新的 vbMsgBoxSetForeground 旗標，確定訊息方塊出現在所有應用程式視窗的最上方。
另一個有關於 ActiveX EXE 元件中表單的問題。您常常使表單的行為類似一個強制回應的表單，但是強制回應不會穿越處理序的範圍，使用者總是要使用滑鼠點取才能啟動視窗。換句話說，如果伺服器正在顯示一個強制回應的視窗，由客戶端引發的方法尚未傳回，因此客戶端不能對自己的視窗作出反應。結果五秒鐘的暫停時間到了之後，一個 擱置元件的請求 對話方塊出現，解釋因為元件沒有回應，操作不能完成。（這有點令人誤解，因為是客戶端沒有回應，不是伺服器。）
解決這個問題的簡單的方法就是在呼叫元件顯示強制回應的對話方塊的方法之前，取消所有客戶端的表單。這很容易很快的做到，感謝Forms 集合：
Private Sub cmdShowDialogFromComponent_Click()
SetFormsState False
x.DisplayDialog
SetFormsState True
End Sub
' The same routine can disable and reenable all forms.
Sub SetFormsState(state As Boolean)
Dim frm As Form
For Each frm In Forms
frm.Enabled = state
Next
End Sub
限制使用者的行為
一個ActiveX EXE元件的執行個體可以同時服務交談式的使用者以及客戶端的應用程式。舉例來說，當使用者啟動一個程式，並且客戶端請求一個由元件所提供的物件時，元件是由正在執行的伺服器所提供。反過來不一定為真，如果客戶端已經建立一個物件而使用者啟動一個程式，一個新的，不同的伺服器執行個體會載入到記憶體中。
當伺服器顯示一個表單，像是客戶端應用程式請求的結果，伺服器應該防止使用者關閉此視窗。您要防止這種情況發生，可以在表單中設定一個Public屬性，告知為何會顯示表單，並且在 QueryUnload 事件程序中加入一些程式碼：
' In the frmDialog form module
Public OwnedByClient As Boolean
Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
If UnloadMode = vbFormControlMenu Then
' The form is being closed by the user.
If OwnedByClient Then
MsgBox "This form can't be closed by the end user"
Cancel = True
End If
End If
End Sub
當然，您必須在顯示表單之前正確地設定 OwnedByClient 屬性，如下列的程式碼：
' If the form is being displayed because a client requested it frmDialog.OwnedByClient = True frmDialog.Show vbModal
在更複雜的案例中，相同的表單可能被使用者以及一個以上的客戶端所使用。在這些情況中，您應該提供一個表單的屬性作為一個計數器，並且判定何時可以安全的載出表單。
最後要說的是關於擁有使用者介面的元件。這樣的元件是一個本機內建的元件，正因為如此，它不能在遠端的電腦執行。這表示您正在建立一個相容性不高的解決方案。當您決定您是否要將使用者介面加入元件的時候，請將此細節加以考慮。這種情況有一個例外就是當元件為了管理顯示一個以上的表單，以及專門為了偵錯的目的，並且當表單為非強制回應表單而不會停止一般從客戶端來的執行流程的時候。
相容性的問題
程式設計人員就以可判讀的名詞做思維的推理：每個類別有一個完整的名稱，以 servername.classname 的格式，這個完整的全名稱做 ProgID。當然，沒有程式設計人員會故意建立兩個有相同ProgID卻不相同的類別，所以看起來名稱的衝突永遠不會發生。但是COM要管理所有不同的程式設計人員所寫的類別，所以假設有兩個不同的程式設計人員所建立相同ProgID的物件不會有名稱上的衝突似乎太過於樂觀。因此，COM使用特殊的識別碼來標記每個類別以及它們所提供的介面。
這種識別碼稱為GUIDs（全球唯一識別碼），並且產生識別碼的演算法確定不會有兩個完全相同GUIDs會被世界上兩台不同的電腦產生出來。GUIDs是128位元數字並且通常是以一群由括號所包圍的十六進位數字所表示。舉例來說，Excel.Application物件（Excel 97版本）的 GUID為：
{00024500-0000-0000-C000-000000000046}
當Visual Basic編譯一個ActiveX伺服器時，對於每一個類別以及它們所提供的介面會產生一個不同的識別碼。一個類別的識別碼稱為CLSID，而類別所提供的介面的識別碼稱為IID，但是每個類別以及所提供的介面只有一個 一般的GUID。所有的GUIDs儲存在Visual Basic為元件所建立的型態程式庫中，並且註冊在登錄資料庫裏。型態程式庫本身登記成另一個單一的識別碼。
登錄資料庫的角色
一個好的程式設計人員至少應該對COM如何註冊在登錄資料庫中有一般的了解。並且知道當客戶端建立一個COM的執行個體時會發生什麼事。
要執行一個元件，Visual Basic必須要把元件的類別的ProgID轉換為實際的CLSID。要做到這樣，Visual Basic呼叫COM執行時期程式庫中的函數來在登錄資料庫HKEY_CLASS_ROOT子目錄中搜尋ProgID。如果搜尋成功，搜尋到的項目CLSID子機碼包含類別的識別碼。（見圖16-9）。當程式利用 CreateObject 函數建立類別執行個體的時候，是在執行時期搜尋；當程式利用New運算元建立類別執行個體的時候，是在編譯時期做搜尋。附帶地，這解釋了使用New運算元建立類別執行個體比使用 CreateObject 函數快速。當使用New運算元時，執行時已經包含了類別的CLSID，節省了在登錄資料庫中所消耗的時間。（您使用特定的變數代替一般的變數可以得到較好的效能）。
| 圖16-9 登錄資料庫編輯器顯示COM在哪裡可以找到MyServer.MyClass元件的CLSID。 |
以此觀點來看，COM可以搜尋到登錄資料庫中HKEY_CLASS_ROOT\CLSID子目錄中元件的CLSID。如果元件正確地註冊了，COM可以利用這個機碼找到所有所需要的資訊。（見圖16-10）(See Figure 16-10.)。特別地，LocalServer32 鍵值的值是元件實際EXE檔案的所在的目錄。其他重要的資訊儲存在 TypeLib 鍵值中，其中包含了類型程式庫的GUID。COM利用這個GUID搜尋登錄資料庫，找尋型態程式庫的所在位置。（在特別的例子中，型態程式庫在提供元件同樣的EXE檔案中，但是一般是儲存在以.tlb為副檔名的不同的檔案中）
| 圖16-10 COM使用CLSID擷取執行檔案的路徑。 |
元件的相容性
理論上，小心仔細評估您的需求可以使您建立一個包含所有類別以及方法的COM元件，以面對真實世界的嚴苛考驗。在這理想的模擬情境中，您不用在元件中增加任何的類別以及方法或是更改任何的Public介面。這些元件絕對不會產生任何相容性的問題。當Visual Basic的編譯器將一方法的名稱轉換為VTable中的位移，這個位移永遠是合法的並且指到元件中同樣的程序。
你可能會懷疑，這樣的模擬情境太完美以至於不可能為真。事實上是您常常更改您的元件、修正錯誤以及增加新的功能。這些改變會對已存在的客戶端造成問題。更精確的說，如果您新版本的元件更改了排列在VTable中方法的順序，當已存在的客戶端試圖存取位於錯誤位移的方法時，會有嚴重的事情發生。類似的問題會發生在相同的程序卻有不同的引數數目或是引數型態上。
Visual Basic定義了三種等級的相容性：
版本相同： 新的物件擁有相同的專案名稱以及與前一版本擁有相同的介面。舉例來說，這發生在如果您更改了方法以及屬性的設計方式但是沒有更改它們的名稱、參數以及傳回值的型態。（您甚至不可以增加選擇性參數到已存在的方法中，因為這樣當方法被引發時，會改變堆疊中參數值的數目）。在這種情況下，Visual Basic使用前一版本中所使用的CLSIDs以及IIDs來編譯新的元件，已存在的客戶端甚至不會發覺元件實際上已被更改過。
版本相容： 如果您增加新的方法以及屬性但是沒有更改已存在成員的介面時，Visual Basic可以建立一個與前一版本相容的新的元件，在某些意義上來說，所有的方法以及屬性仍然保留Vtable中的位置。因此，已存在的客戶端可以安全地呼叫舊有的成員。VTable延伸記錄新的成員，新的成員只會被對於新版本元件重新編譯的客戶端所使用。元件的EXE或是DLL的檔案名稱可以與前一版本的名稱相同，當您在顧客的電腦中安裝新版本的元件，將會把舊版本的元件覆蓋掉。
版本不相容： 當您更改已存在方法以及屬性的介面－舉例來說，增加或是移除引數（包含選擇性的引數）或是更改引數的型態或是回傳值－此元件不再跟前版的元件相容。Visual Basic 6有時會製造不相容的元件甚至您只是更改了程序屬性對話方塊。在這種情況下，您必須更改元件所在的EXE或是DLL檔案的名稱，這樣元件才能再顧客的電腦中與前一版本的元件共存。舊的客戶端應用程式使用前一版本的元件，新的客戶端應用程式使用新版本的元件。
如果客戶端使用New運算元建立來自元件的物件，客戶端透過CLSID引用這些物件，使用這種方式，當有兩個不同（不相容）卻擁有相同的ProgID的元件安裝在同一台電腦時，不會有衝突產生。但是較好的方式是不同版本的元件要有不同的ProgID，您可以藉由更改新元件的專案名稱來達成此目的。
讓我們來考慮當您建立一個版本相容的元件時，實際上會發生什麼事。您可能會相信Visual Basic只是簡單的以繼承前一版本元件的CLSID以及IID的方式建立一個新的元件，但是並不是如此。相反地，Visual Basic為所有的元件中的類別以及介面，產生新的識別碼。這樣合乎COM的指導原則，其中提到一旦您發行一個介面之後便不應該再去更改它。然而，新的元件也包含了前一版本元件的CLSID以及IID的所有相關資訊，如此以舊版本元件所建立的客戶端可以繼續如以前一般的工作。當舊的客戶端從新的元件請求一個物件時，COM搜尋登錄資料庫中舊的CLSID，舊的CLSID仍然引用同一個EXE檔案。您需要了解電腦是如何運作的，因為這裡解釋了為何一個版本相容的元件在執行檔中累積多重的CLSID以及IID集合，並且也會導致過多項目填滿登錄資料庫。（包含您顧客以及您自己的）。
在Visual Basic環境中的版本相容
您已經足夠的了解如何建立一個相容的元件並且何時應該建立元件。Visual Basic並不允許像其他程式語言一般地選擇類別的CSID；所有的類別以及介面都是自動產生。但是您可以決定一個新版本的元件是否要保留前一版本元件所產生的CSIDs。Visual Basic提供的三種設定會影響到識別碼如何產生，如圖16-11：
| 圖16-11 Visual Basic 整合發展環境中的版本相容設定。 |
不相容： 當您每次在此環境中執行專案時（或是編譯至磁碟中），Visual Basic會覆蓋所有已存在的識別碼並且重新產生它。這包含了所有的類別、介面以及元件的型態程式庫。這表示與前一版本正常工作的客戶端將不能與新版本的元件工作。
與專案相容： 當您選擇此模式，您必須也選擇一個必須保存相容性的VBP、EXE或是DLL檔案。在這種情況下，Visual Basic拋棄所有類別以及其介面的識別碼，但是保留元件類型程式庫的GUID。這樣的設定在發展過程中是很有用的，因為由其他Visual Basic執行個體所載入的客戶端應用程式將不會失去引用對話方塊中伺服器型態程式庫的引用。當Visual Basic發展環境失去型態程式庫的引用時，在引用對話方塊中引用項目相對應的位置之前會標記上MISSING: 的標記。當這種情形發生時，您必須將其刪除，關閉對話方塊，重新開啟對話方塊，並且選取已被加入相同名稱的新的引用。
當然，如果要使得已存在的客戶端能夠繼續使用新版本的元件工作，只是保留型態程式庫的GUID是不夠的，但是這是一個難題，因為在測試期間您沒有發行任何已編譯好的客戶端。當您建立一個ActiveX EXE或是DLL專案，Visual Basic的預設值為專案相容模式。
與機器碼相容： 當您對一個已存在的元件設定與機器碼相容，Visual Basic試圖保留所有元件的型態程式庫、類別以及介面的識別碼。您應該在發行此元件（以及它的客戶端應用程式）給您的顧客時強制使用此模式，因為這樣可以保證不用重新編譯所有已存在的客戶端就能替換元件。您需要提供包含前一版本元件的執行檔的路徑，這樣Visual Basic將利用此路徑找到所有所需要的識別碼。
注意
一個常見的錯誤就是為機器碼相容選取參考檔案時，選擇與編譯過程的目標相同。如果您犯了這個錯誤，當您每一次編譯您新版本的檔案時，一個新的GUID集合會加入您的EXE檔案中。這些識別碼都是沒有用的，因為它們來自發展階段的編譯物，並且它們不斷的增加執行檔的大小並且在您的登錄資料庫中加入一些不會用到的機碼。此外，在某些環境中，當編譯的目標以及機器碼相容所使用的參考檔同時發生時，會造成編譯時的錯誤。
替代的方案是，您應該為您的元件準備一個初始的版本，包含所有適當的類別以及方法（即使是空的），然後建立一個執行檔並且作為所有後來編譯的參考。用這種方式，您可以選擇機器碼相容並且可以避免GUID的擴展。當然，一經您發行您伺服器第一個公開的版本，它將變成一個新的機器碼相容的參考。記得將這樣的EXE以及DLL檔案儲存在不同的目錄，如此當您編譯專案至磁碟的時候就不會意外地覆蓋掉它們。
當您正在機器碼相容模式下，Visual Basic僅僅將編譯元件當作參考來嘗試維護相容性。事實上，在發展一個新版本元件的某些時候，您可能故意地或是意外地破壞相容性－舉例來說，更改專案的名稱、更改類別或是方法的名稱，或是方法的引數的型態或是數量。（見
〈版本相容〉 章節，在此章之前）。當您稍後執行或是編譯此專案，Visual Basic會顯示一個如圖16-12的對話方塊並且提供您三個選項：
| 圖16-12 說明在機器碼相容模式下如何處理一個不相容的元件 |
此時，您可能有目的地要破壞前一版本元件的機器碼相容性。這是一個有效的手法，舉例來說，當您正要部署客戶端的應用程式以及所有所需要的元件時並且您確定在顧客的機器上沒有舊版本的元件。您可以藉由手動重新設定相容性為 不相容 來破壞相容性並且重新編譯應用程式。這時您所得到的元件不包含所有前一版元件的GUID因此元件的體積較小並且在登錄資料庫中不會有一些從來不會用到的機碼。
設計提示
要設計一個不平凡的元件幾乎是不可能的，所以當需求改變時，您不需要破壞與前一版本元件的相容性。這裡有幾個提示幫助您保留元件的相容性。
第一， 慎選每一個方法以及屬性的資料型態。寧願使用Longs而不要使用Integers因為前者提供較大的變數值範圍且不會破壞效能，使用Double代替Single作為引數。使用Variant引數也可以幫助您在需求改變時提供相容性。
第二， 嘗試去預期您的方法的成長性。即使您不希望寫出具有這些附加能力的程式碼，提供所有必要的方法以及引數在之後變成是必要的。您可以使用 Optional 以及 ParamArray 關鍵字來使您的程式具有彈性而不會影響已存在客戶端的簡單性。
讓您可以與前一版本的元件保持相容性的其他的手法就是包含一個可以做任何事情的方法，此方法依照您所傳入的引數決定完成的工作。實作的方式如下：
Function Execute(Action As String, Optional Args As Variant) As Variant
' No code is here in the initial version of the component.
End Function
任何時候您想要增加類別的智慧功能但是您不想破壞元件與已存在客戶端的相容性時，您只要加入一些程式碼在 Execute 方法中，然後以「破壞機器碼相容」的方式重新編譯。舉例來說，您可能增加從檔案儲存以及載入初始資料的功能：
Function Execute(Action As String, Optional Args As Variant) As Variant
Select Case Action
Case "LoadData" 'LoadData and SaveData are private procedures
LoadData args 'defined elsewhere in the project.
Case "SaveData"
SaveData args
End Select
End Function
Args 變數是一個Variant，所以您可以使用陣列傳遞多重的參數給它。舉例來說，您可以實作一個在一段期間內銷售數量的函數：
' Inside the Evaluate method
Case "EvalSales"
' Check that two arguments have been passed.
If IsArray(Args) Then
If UBound(Args) = 1 Then
' The arguments are the start and end date.
Evaluate = EvalSales(Args(0), Args(1))
Exit Function
End If
End If
Err.Raise 1003, , " A two-element array is expected"
然後您可以呼叫 Evaluate 方法：
'Load initialization data.
obj.Evaluate "LoadData", "c:\MyApp\Settings.Dat"
'Build a 2-element array on the fly, and pass it to the Evaluate method.
SoldPieces = obj.Evaluate("DevalSales", Array(#1/1/98#, Now))
註冊元件
如同筆者在之前所描述的，關於元件許多重要的資料都儲存在登錄資料庫中。當元件經過了註冊（registration）的過程，資訊就完全地記錄在登錄資料庫中。當您在IDE的環境中執行一個ActiveX專案，Visual Basic便完成一個元件暫存的註冊，當客戶端像直譯的元件請求一個物件時，COM將呼叫Visual Basic本身。當您停止執行這個專案，Visual Basic直接取消元件的註冊。
然而，當您安裝一個元件在顧客的電腦中時，您需要完成一個永久的註冊。這裡有三種永久註冊ActiveX伺服器的方法：
regsvr32 <filename>
有時，您可能要取消元件的註冊。舉例來說，在您將元件殺掉之前取消註冊是一個好的點子，因為您將可以移去所有元件在登錄資料庫中的項目。如果您保持登錄資料庫的潔淨，您可以有一個較有效率的系統以及減少一些不預期造成程式設計人員神經緊張的"ActiveX can't create the component" 的錯誤。您可以用下列兩種方式取消元件的註冊：
regsvr32 /U <filename>
小秘訣
您可以利用下列的方式來減少註冊一個DLL伺服器的時間。打開Windows Explorer並且瀏覽到C:\Windows\SendTo目錄（假設您的作業系統安裝在 C:\Windows目錄）。然後建立一個捷徑到Regsvr32.exe 檔案並且標記為 Register-ActiveX DLL，或是您喜歡的名稱。當您做好此步驟，您可以藉由在元件上按下滑鼠的右鍵，然後傳送到註冊命令來輕易的註冊元件。要輕易地取消元件的註冊，您可以建立下列兩行批次檔：
C:\VisStudio\Common\Tools\Vb\Regutils\regsvr32 /U %1 Exit
然後建立捷徑到SendTo表單。（當然,記得路徑要符合您的系統）。
停止伺服器
當您使用一個物件之後，當您不在需要這個元件後您必須載出此元件。如果您忽略此步驟，元件會繼續停留在您的系統之中，消耗記憶體、資源以及CPU時間。一個跨處理序ActiveX元件符合下列條件時，是正確的載出。
不要忘記只有在客戶端應用程式中的物件變數保持元件的活力。如果元件有一個以上的私有變數指到自己的物件，這樣不能阻止COM在當沒有客戶端使用物件時毀滅元件。
以後面兩個載出元件的條件來討論，您要注意的是元件中的程式碼實際上做了哪些事。舉例來說，許多元件利用隱藏的表單容納一個Timer控制項，以提供背景處理的能力。考慮下列簡單的程序：
' In the MyClass module of the MyServer component
Sub StartBackgroundPrinting()
frmHidden.Timer1.Enabled = True
End Sub
這樣的表單能夠在所有客戶端都終止後使元件仍然存在著，直到使用著重新啟動電腦或是直接從工作管理員或是其他相同的工具殺掉此執行緒，更糟糕的是元件是不可見的，所以除非您檢視存活執行緒的列表，否則您不知道執行緒仍然存活著。當然，這個問題的解決方式就是在 Terminate 事件程序中載出此表單，也就是當客戶端釋放所有元件的引用時總是執行的程序：
' In the MyClass module of the MyServer component
Private Sub Class_Terminate()
Unload frmHidden
End Sub
如果客戶端是正在執行的程式碼-舉例來說，一個不斷監視序列埠有無所需資料的迴圈 - 您必須設計一個方法，當所有的引用釋放後停止這個程式碼。大多數的時候，您可以使用解決隱藏表單的方式解決這個問題，就是直接在 Terminate 事件程序中停止這個程式碼。一些複雜的伺服器提供一個方法，像是 Quit 或是 Close，客戶端可以使用此方法表示不再需要這個元件並且設定所有的引用為Nothing。舉例來說，這種方式接近Microsoft Excel以及Microsoft Word所使用的方式。（見本章一開始的 Spell Checker範例 ）。
最後一點要注意的：一個伺服器必須在所有客戶端的服務完成後才可以結束。即使伺服器提供一個如 Quit 的方法，伺服器不應該嘗試迫使自己結束。如果一個伺服器突然自己終結－舉例來說，使用 End 敘述－所有仍然引用伺服器元件的客戶端會收到一個錯誤代碼440的錯誤，Automation錯誤。Quit 方法應該只是伺服器的一個請求，用來對關閉伺服器本身做準備，載出所有的表單以及停止背景活動。
持久性
Visual Basic 6已經加入了建立持久儲存功能的物件（persistable objects）的功能，就是物件的狀態可以被儲存以及恢復。持久儲存功能的物件的要點在於新的 Persistable 物件屬性以及獨立的PropertyBag物件。只有公開的以及可建立的物件可以作為持續儲存功能的物件，所以 Persistable 屬性只有在執行個體為MultiUse或是SingleUsecreatable（或是它們的Global變數）才會在類別屬性的列表中將出現 Persistable 屬性。
儲存以及恢復狀態
當您設定一個公開的以及可建立的物件的屬性為1-Persistable，物件模組提供三個新的內部事件：InitProperties、WriteProperties 和 ReadProperties。在 InitProperties 事件中，類別被期待初始化其屬性，通常表示指定物件的屬性為預設值。這個事件通常在 Initialize 事件之後被觸發。
' A persistable CPerson class with just two properties
Public Name As String
Public Citizenship As String
' Default values
Const Name_Def = ""
Const Citizenship_Def = "American"
Private Sub Class_InitProperties()
Name = Name_Def
Citizenship = Citizenship_Def
End Sub
當物件被要求儲存內部的狀態時，Class_WriteProperties 事件被觸發。這個事件程序收到一個PropertyBag物件，一個應該填滿物件目前的狀態值的虛擬袋子。您使用接受屬性名稱以及值的PropertyBag類別的 WriteProperty 方法填滿這個袋子。
Private Sub Class_WriteProperties(PropBag As PropertyBag)
PropBag.WriteProperty "Name", Name, Name_Def
PropBag.WriteProperty "Citizenship", Citizenship, Citizenship_Def
End Sub
最後，當物件被要求恢復內部的狀態時，Class_ReadProperties 事件被觸發。傳遞給事件程序的PropertyBag物件包含了前一次所儲存的屬性值，並且物件可以透過PropertyBag類別的 ReadProperty 方法來取出屬性值。
Private Sub Class_ReadProperties(PropBag As PropertyBag)
Name = PropBag.ReadProperty("Name", Name_Def)
Citizenship = PropBag.ReadProperty("Citizenship", Citizenship_Def)
End Sub
傳遞給 WriteProperty 以及 ReadProperty 方法中的最後一個引數是屬性的預設值。預設值是PropertyBag物件用來做資源的最佳化。如果屬性的值與預設值相同，那麼屬性實際上就不會被儲存到PropertyBag物件中。這個參數是選擇性的，
但是如果您使用它，就必須在所有三個事件程序中使用相同的值。因此，使用符號常數是適當的。
PropertyBag物件
要擁有一個物件以儲存狀態，您必須建立一個獨立的PropertyBag 物件並且傳遞持續儲存功能的物件給PropertyBag類別的 ReadProperty 方法。
'Inside a form module
Dim pers As New CPerson, pb As New PropertyBag
'Initialize a CPerson object.
Private Sub cmdCreate_Click()
pers.Name = "John Smith"
pers.Citizenship ="Australian"
End Sub
'Save the CPerson object in a PropertyBag.
Private Sub cmdSave_Click()
'This statement fires a WriteProperties event in the CPerson class.
pb.WriteProperty "Aperson", pers
End Sub
如果類別的 Persistable 屬性不是1-Persistable，當您試著從此類別儲存或是恢復一個物件時，會得到一個錯誤330，"不合法的參數 不能寫入物件因為不支援持久儲存功能的物件"。
恢復物件的狀態也是很簡單的：
Private Sub cmdRestore_Click()
'To prove that persistence works, destroy the object first.
Set pers = Nothing
'The next statement fires a ReadProperties event
' in the CPerson class.
Set pers = pb.ReadProperty("Apersonl")
End Sub
當您傳遞物件給 WriteProperty 以及 ReadProperty 方法，您沒有指定預設值。如果您忽略最後一個參數並且PropertyBag 沒有相對應的值，Visual Basic產生一個錯誤327"找不到'property name'的資料值"。這是您在程式有邏輯上錯誤的徵兆。基本上，您拼錯了屬性的名稱，或是當您儲存物件時您指定了一個預設值但在回存時忽略了。一但曾經載入PropertyBag物件並擁有一個以上的屬性值，您可以將這些值存回磁碟，如此您可以在其後的程序中恢復物件的狀態。您可以使用PropertyBag的 Contents 屬性來做這樣的工作，PropertyBag的 Contents 屬性是一個Byte陣列，包含了儲存在PropertyBag中所有儲存值的資訊，如同下一頁程式的示範：
' Save the PropertyBag to a binary file. Dim tmp As Variant Open App.Path & "\Propbag.dat" For Binary As #1 tmp = pb.Contents Put #1, , tmp Close #1
前面的程序使用一個暫存的 Variant 變數儲存Byte陣列。當您從載出的檔案的內容時您可以使用同樣的技巧。
' Reload the PropertyBag object from file. Dim tmp As Variant Set pb = New PropertyBag Open App.Path & "\Propbag.dat" For Binary As #1 Get #1, , tmp pb.Contents = tmp Close #1
注意
如果您在IDE環境中測試程式，您可能會發覺您無法載出前一次儲存到磁碟上的物件狀態，因為錯誤713"類別沒有註冊"。這是因為propertybag中物件的CLSID被儲存起來。預設上，在IDE中每次您重新執行應用程式，Visual Basic為專案中的每一個類別重新產生一組新的CLSID，所以不能載入不同CLSID的物件。要克服這個問題，您應該設定「機器碼相容模式」，如同在本章之前的章節 〈Visual Basic環境中版本相容〉 所解釋的。
物件階層的持久性
持久性（persistence）的技術也可以用在物件的階層上﹔階層中的每一個物件有責任將其所依靠的物件儲存在它的 WriteProperties事件中並且在 ReadProperties 程序回復。所有的工作只要在階層中的每個物件將其Persistable屬性設定為 1-Persistable。舉例來說，您可以將CPerson類別延伸為包含一個其他CPerson的 Children集合，並且在 WriteProperties 以及ReadProperties 事件程序中，記錄新的屬性：
Public Children As New Collection ' A new public property
Private Sub Class_WriteProperties(PropBag As PropertyBag)
Dim i As Long
PropBag.WriteProperty "Name", Name, Name_Def
PropBag.WriteProperty "Citizenship", Citizenship, Citizenship_Def
' First, save the number of children (default = 0).
PropBag.WriteProperty"ChildrenCount", Children.Count, 0
' Next, save all the children, one by one.
For i = 1 To Children.Count
PropBag.WriteProperty "ChildlW"&1, Children.Item(1)
Next
End Sub
Private Sub Class_ReadProperties(PropBag As PropertyBag)
Dim i As Long, ChildrenCount As Long
Name = PropBag.ReadProperty("Name", Name_Def)
Citizenship = PropBag.ReadProperty("Citizenship", Citizenship_Def)
' First, retrieve the number of children.
ChildrenCount = PropBag.ReadProperty("ChildrenCount", 0)
' Next, restore all the children, one by one.
For i = 1 To ChildrenCount
Children.Add PropBag.ReadProperty("Childle" & 1)
Next
End Sub
有趣地，所產生的PropertyBag物件包含了許多名稱為 Name、Citizenship、 Child1、Child2 等等的屬性，但是這不是問題因為它們封裝在一個屬性的階層之中，所以不會有困擾產生。換句話說，儲存在 Child1 子樹狀目錄中的 Name 的值與儲存在 Child2 子樹狀目錄中的 Name 的不同，其餘的也是如此。如果您想了解更多這方面的技巧，可瀏覽隨書光碟中範例程式的程式碼。
注意
您需要確定在階層結構中不包含任何的循環的引用。或是至少您需要確定當您在儲存以及恢復物件時，引用是正確的。要解釋這為什麼是一個重要的考量，讓我們假設CPerson類別提供一個Spouse屬性，可以傳回一個person的wife或是husband的引用，試想假使每個物件都嘗試儲存這個屬性的狀態，會發生什麼是。Mr. Smith儲存Mrs. Smith的狀態，接著Mrs. Smith儲存Mr. Smith的狀態，接著Mr. Smith儲存Mrs. Smith的狀態，不斷地循環下去直到出現"out of stack space" 錯誤。
依據關連的自然性，您必須發明另一套策略以避免這種無止境的迴圈。舉例來說，您可以儲存person的配偶的名稱來代替儲存整個狀態來解決這個問題，但是之後您需要在ReadProperties事件程序中正確地重建關連。
在任何類別模組中使用 PropertyBag
之前筆者解釋過 Persistable 屬性只有在Public以及可建立的類別中才可以使用。就某方面的意義而言，這是COM的需求，而不是Visual Basic。然而，這並不表示您不能利用PropertyBag物件─並且相容於儲存資料在Automation-compliant格式中─來實作一種物件持久性。事實上，您唯一不能做的事是實作一個自訂的類別事件，比如 WriteProperties 以及 ReadProperties。但是您可以增加一個特殊的屬性以設定以及傳回物件的狀態並且使用一個private PropertyBag物件作為連續機制的低階實作。筆者有一個CPerson類別模組提供一個特殊的 ObjectState 屬性：
' The CPerson class module
Public FirstName As String, LastName As String
Property Get ObjectState() As Byte()
Dim pb As New PropertyBag
' Serialize all the properties into the PropertyBag.
pb.WriteProperty "FirstName", FirstName, "U"
pb.WriteProperty "LastName", LastName, "U"
' Return the PropertyBag's Contents property.
ObjectState = pb.Contents
End Property
Property Let ObjectState(NewValue() As Byte)
Dim pb As New PropertyBag
' Create a new PropertyBag with these contents.
pb.Contents = NewValue()
'Deserialize the class's properties.
FirstName = pb.ReadProperty("FirstName", "")
LastName = pb.ReadProperty("LastName", "")
End Property
當實作此種 「持久性」時，在客戶端應用程式的程式碼有點不同：
Dim p As New CPerson, state() As Byte p.FirstName = "Francesco" p.LastName = "Balena" 'Save the state into a Byte array. state() = p.ObjectState ' ... ' Create a new object, and restore its state from the Byte array. Dim p2 As New CPerson p2.ObjectState = state() Print p2.FirstName & " " & p2.LastName ' Displays "Francesco Balenal".
當然，如果此物件依靠其他物件，它們必須也提供 ObjectState 屬性，如此主要的物件才能正確地循序化子物件的屬性。一個清楚的方法是要定義一個 IObjectState 介面並且在所有產生持久性的物件中實作這個介面。注意到這個技巧可以正常工作是因為低連續性是由元件的程式碼所產生的，而不是PropertyBag 物件，所以這裡沒有關於 Instancing 屬性的限制。這個技巧也可以在標準EXE程式中使用並且是您使用PropertyBag物件所不知道的最實用的技巧。
ADO Recordsets的持久性
有一個您在Visual Basic說明文件中找不到的事實就是在某些條件下您甚至可以傳遞一個ADO Recordset給一個PropertyBag物件。更明白的說，任何的ADO Recordset可以使用 Save 方法儲存到檔案中－舉例來說，一個送給adUseClient並包含 CursorLocation 集合的Recordset－可以傳遞給一個PropertyBag的 WriteProperty 方法。這給予您在應用程式間交換資料前所未有的彈性。舉例來說，代替使用Save方法儲存單一的Recordset 到一個檔案，您可以在一個PropertyBag物件中儲存多筆相關的Recordset，然後再將其 Contents 屬性儲存到檔案中。
建立一個ActiveX DLL伺服器
在Visual Basic中建立一個同處理緒的DLL元件和建立跨處理緒的元件沒有什麼不同，所以在前一章〈 建立一個ActiveX EXE伺服器〉中所討論的主要技巧，對ActiveX DLL元件也是可以應用。在本章中，筆者將焦點放在這兩種類型的元件少數的差異之處。
注意
如果您尚未準備好，請下載Visual Basic最新的Service Pack。雖然Service Pack沒有增加任何語言上新的功能，但是它修正了在ActiveX DLL元件上一些嚴重的錯誤 - 特別地，發生在當應用程式使用超過七或八個同處理緒服務時。
在Visual Basic IDE中的同處理緒元件
同處理緒元件可以藉由從 專案屬性 對話方塊的設定將類別基礎的標準執行檔專案轉換為ActiveX DLL專案來建立，如同您在跨處理緒元件中所做的。相同的，您可以從功能表的 檔案 選擇 建立新檔案 ，在 建立新檔案 對話方塊中選擇建立ActiveX DLL 專案。
建立跨處理緒以及同處理緒專案的最主要差異在於，後者可以在相同的IDE環境中建立客戶端。Visual Basic 5以及6發展環境支援專案群組（project groups）的觀念並且可以在同一個Visual Basic執行個體中容納多個專案。要建立專案群組，首先先跟一般一樣建立一個專案，然後從功能表的 檔案 選擇 增加新專案 來建立附加的專案或是從磁碟載入一個已存在的專案。這種功能讓您利用一個標準執行檔建立專案群組以及一個以上的ActiveX DLLs，這樣您可以同時測試多個同處理緒元件。您也可以將專案群組儲存成副檔名為.vbg的檔案，這樣您可以利用單一的 開啟 指令打開一個專案群組。
當您啟動Run命令，被標記為 啟動專案 的專案開始執行（見圖16-13）。通常是一個標準執行檔專案當作是客戶端，然後再從Active X DLL專案中建立一個或是一個以上物件執行個體。您不需要直接執行執行ActiveX DLL專案（如同您將跨處理緒元件執行在不同的Visual BasicIDE執行個體中），但是您仍然要在標準執行檔的 引用 對話方塊中加入一個DLL的引用。
| 圖16-13 您可以在「專案」視窗中按下滑鼠右鍵設定啟動專案。 |
注意在IDE中少數的命令間接地與目前的專案有關－也就是在 專案屬性 中反白的專案。舉例來說， 引用 對話方塊會因為反白的專案的不同而有不同的內容， 專案屬性 對話方塊也只讓您見到以及更改目前反白專案的屬性。當目前的專案是標轉執行檔的時候，物件瀏覽器只能顯示其他ActiveX DLL 專案的Public類別以及成員且不允許您更改成員的屬性。要顯示所有的private成員或是更改其屬性和DLL的方法以及屬性的描述，您必須將ActiveX DLL設為啟動專案。
對於在相同的客戶端環境中執行DLL是沒有限制的，因為一個ActiveX DLL只能有一個客戶端。DLL載入客戶端的位址空間，所以不能與其他的應用程式共享。如果兩個不同的客戶端應用程式對同樣的同處理緒元件請求物件，COM建立兩個不同的DLL的執行個體，每個執行個體在所要求客戶端的位址空間內。因此，使用ActiveX DLL比使用ActiveX EXE 簡單的多；每個元件只對一個客戶端服務，所以所有的請求可以直接執行。客戶端應用程式不需要處理逾時的情況。
一個ActiveX DLL專案不能包含SingleUse或是GlobalSingleUse類別。原因是DLL在客戶端相同的處理緒中執行並且沒有各自的處理緒。所以當客戶端從元件建立第二個物件時，COM不能為DLL建立一個新的處理緒。
同處理緒元件和跨處理緒元件之間的差異
ActiveX DLL元件不可能每件事都做到。在大多數的情況中，是由於先天上同處理緒的限制並且不能被Visual Basic控制。
錯誤處理
在同處理緒元件中的錯誤討論就如同ActiveX EXE伺服器一般。然而，就某種意義來說，在同處理緒元件中錯誤處理更為重要，因為在伺服器中任何嚴重的錯誤都會導致客戶端的結束，反之亦然。因為兩者實際上是同一處理緒。
使用者介面
ActiveX DLLs可以顯示它們自己的表單，如同跨處理緒元件一般。有趣的是，從同處理緒元件所產生的表單會自動放在客戶端表的的前面，所以您不需利用 SetForeground-Window API函數整理表單以達到正確的狀態。然而，依據客戶端的能力，一個同處理緒元件可能不能顯示非強制回應的表單。舉例來說，利用Visual Basic5或是6，Microsoft Office 97 套裝軟體（或是之後的版本）中所有的應用程式，以及所有經過VBA語言註冊同意的其他廠商的應用程式，都支援同處理緒元件顯示非強制回應表單。另一方面，利用Visual Basic 4所寫的應用程式以及所有Microsoft Office之前版本的應用程式，當同處理緒元件試圖顯示一個非強制回應表單時，會產生錯誤369。
Visual Basic透過 App.NonModalAllowed 唯讀的屬性讓您能夠判斷客戶端是否有顯示非強制回應表單的能力。Microsoft建議在元件中顯示非強制回應表單之前先利用測試這個屬性，並且如果必要以強制回應表單代替。
If App.NonModalAllowed Then
frmChart.Show
Else
frmChart.Show vbModal
End If
假如您仔細思考過會發覺vbModal常數是1並且 App.NonModalAllowed 回傳值是0或是-1，您可以一句陳述式做所有的事：
frmChart.Show (1 + App.NonModalAllowed)
不幸地，若您沒有將元件編譯成實際的ActiveX DLL ，將無法測試這項功能，因為當成是在Visual Basic環境中執行時 App.NonModalAllowed 屬性總是傳回True。
關閉伺服器
同處理緒元件終止的狀態規則跟您在跨處理緒元件中所見到的不同。最主要的差異在於同處理緒元件事跟隨著客戶端的命運：當客戶端終止元件就終止，即使是一個可見的表單也一樣。當客戶端仍然在執行，若下列條件全部符合，一個同處理緒元件就會終止。
事實上一個同處理緒元件藉由自身內部的引用保持存活，產生了一個不易處理的問題。舉例來說，如果元件包含兩個互相引用的物件，當客戶端釋放所有對於元件的引用後，則此元件將永遠不會關閉。換句話說，循環引用將使同處理緒元件一直存活著直到客戶端終止。目前沒有簡單的方法解決這個問題，並且要使程式設計人員費力避免產生循環引用。(有關循環引用的更多資訊，見
第七章 )另一個要點是同處理緒元件的狀態可能困擾許多程式設計人員。在ActiveX EXE元件，當所有的客戶端釋放引用，伺服器便終止（提供所有其他所需要的條件），同處理緒元件不是直接終止。一般上，Visual Basic會使元件存活數分鐘（然而,精確的時間可能會改變）所以如果其他客戶端的請求，COM不會去重新載入伺服器。如果元件的停留時間過了，DLL會靜靜的載出並釋放出記憶體。此時一個新的客戶端請求會花較多的時間，因為COM需要重新載入元件。
注意
只有引用到public物件才能保持存活。即使一個同處理緒DLL設法做到傳遞一個指向private物件的指標給予客戶端（舉例來說，使用 As Object 參數或是回傳值），這樣的引用不能保持元件的存活。如果客戶端釋放所有對於Public物件的引用，一段時間之後元件就會載出。由客戶端所擁有的變數變成無效的並且一使用就會使應用程式當機。因此元件不應該傳一個private物件給客戶端。
重覆進入的問題
呼叫一個同處理緒元件的方法或是屬性會直接的服務，即使元件正在服務其他的需求。這些不同於跨處理緒元件的行為並且產生了一些您必須解決的問題：
這兩個問題都發生在當元件正在服務前一項需求的同時，客戶端呼叫元件，這會發生在假使物件執行一個使客戶端再次啟動的DoEvents命令、或是假使元件在客戶端產生一個事件，或是假使客戶端從Timer控制項的 Timer 事件程序中呼叫一個元件。如果您避免這些循環，您應該不會發生重覆進入的問題。另一方法是，您可以實做一個信號機（semaphore），以客戶端的一個全域數判斷是否可以安全地呼叫元件。
ActiveX DLL和標準執行檔程式之間的差異
您應該意識到一個同處理緒元件行為的一些特色；當您從一個標準Visual Basic應用程式的一些類別轉換為一個ActiveX DLL時，這些特色是很重要的。舉例來說，一些物件以及關鍵字與元件的環境有關，而不是客戶端：
一些其他的功能也是它們不能做到的：
DLL中的嵌入式表單
ActiveX DLL伺服器提供一個不錯的方法來重覆使用一般的表單以及對話方塊。如同您所知道的，表單模組不能為Public，所以在專案以外不能被看到，但是您可以建立一個包裹著表單的Public類別，並且提供相同的介面，這樣您就可以從其他的應用程式建立表單。已存在的應用程式只需要小幅的修改或者絲毫不用修改的就可以使用代替表單的元件。事實上，要做到如此唯一的需求就是應用程式永遠不要直接引用表單上的控制項，也就是說無論如何也不要這麼做以保持表單的封裝性（需要更多的資訊，見 第九章 ）
假設您需要建立一個frmLogin表單接受使用者的名稱以及密碼，以判斷使用者的合法性。在這個簡單的例子中，唯一合法的使用者名稱為francesco，對應的密碼為balena。這個表單有兩個TextBox控制項，名稱為 txtUsername以及txtPassword，以及一個cmdOK CommandButton控制項。表單也提供一個事件，WrongPassword，事件是由於使用者按下OK按鈕，但是密碼不合法所產生的。這個事件可以由客戶端的程式碼抓取並且顯示一個訊息對話方塊給使用者，如同您在圖16-14所見到的。這是表單模組的完整程式碼：
Event WrongPassword(Password As String)
Public UserName As String
Public Password As String
Private Sub cmdOK_Click()
'Validate the password.
If LCase$(txtUserName="Francesco" And LCase$(txtPassword) = _
"balena" Then
Unload Me
Else
RaiseEvent WrongPassword(txtPassword)
End If
End Sub
Private Sub Form_Load()
txtUserName = UserName 'Load properties into fields.
txtPassword = Password
End Sub
Private Sub Form_Unload(Cancel As Integer)
UserName = txtUserName 'Load field values into properties.
Password = txtPassword
End Sub
您可以像使用類別一樣來使用這個表單，而不用直接引用到表面的控制項。這是在隨書光碟中範例程式的主表單的程式碼：
Dim WithEvents frmLogin As frmLogin
Private Sub Command1_Click()
Set frmLogin = New frmLogin
frmLogin.Show vbModal
MsgBox "User " & frmLogin.UserName & "logged in", vbInformation
End Sub
Private Sub frmLogin_WrongPassword(password As String)
MsgBox "Wrong Password"
End Sub
| 圖16-14 一個同處理緒元件可以方便地封裝一個表單並且提供其事件給予客戶端應用程式。 |
因為表單不能藉由直接存取其控制項來使用，所以您包裹一個CLogin類別模組在 frmLogin表單上並且封裝兩個類別以及表單模組在LoginSvr DLL中，LoginSvr DLL對外界提供表單的功能函數。底下是CLogin類別的原始程式碼：
Event WrongPassword(Password As String)
Private WithEvents frmLogin As frmLogin
Private Sub Class_Initialize()
Set frmLogin = New frmLogin
End Sub
Public Property Get UserName() As String
UserName = frmLogin.UserName
End Property
Public Property Let UserName(ByVal newValue As String)
frmLogin.UserName = newValue
End Property
Public Property Get Password() As String
Password = frmLogin.Password
End Property
Public Property Let Password(ByVal newValue As String)
frmLogin.Password = newValue
End Property
Sub Show(Optional mode As Integer)
frmLogin.Show mode
End Sub
Private Sub frmLogin_WrongPassword(Password As String)
RaiseEvent WrongPassword(Password)
End Sub
您可以看到，類別的 UserName 以及 Password 屬性以及 Show方法簡單地以相同的名稱代表表單的成員。此外，類別截取從表單而來的 WrongPassword 事件並且在客戶端應用程式中產生一個相同名稱的事件。總之，類別正好提供與原始表單相同的介面。如果您設定類別的Instancing屬性為5-MultiUse，類別（以及表單）可以被任何的客戶端應用程式重新使用。您可以更改原始的客戶端應用程式的幾行程式碼使其可以與代替frmLogin類別的CLogin 類別工作（更改的程式碼以粗體字表示）
Dim WithEvents frmLogin As CLogin
Private Sub Command1_Click()
Set frmLogin = New CLogin
frmLogin.Show vbModal
MsgBox "User " & frmLogin.UserName & "logged in", vbInformation
End Sub
Private Sub frmLogin_WrongPassword(password As String)
MsgBox "Wrong Password"
End Sub
您可以使用這個技巧建立強制回應以及非強制回應的重複使用的表單。然而，您不能在如同MDI應用程式中的MDI子表單的方式嵌入表單在DLL中。
效能
您可以使下列的方法增加您ActiveX DLL伺服器的效能：
傳遞資料
因為DLL與客戶端在同一位址空間執行，COM不需要處理客戶端到元件的外部參數傳遞（marshal）的資料。實際上，COM在同處理緒元件中所扮演的角色比跨處理緒元件簡單，因為COM只要確定當客戶端有請求時能正確地建立元件的執行個體。從此觀點來看，客戶端直接與元件聯繫。當客戶端不再需要元件時，COM將會再次啟動以確保DLL被釋放。
當一個客戶端呼叫跨處理緒元件時，處理緒的轉換會發生在任何時候，這會拖慢 ActiveX EXE元件相當的速度。舉例來說，呼叫一個跨處理緒元件中，空的、不含任何引數的程序，比起呼叫一個同處理緒DLL中，空的、不含任何引數的程序大約慢了500倍。驚人地，呼叫DLL中的方法與客戶端應用程式中Private類別的方法多少有些相同，所以計算呼叫一個同處理緒元件的時間是沒有意義的。
缺乏外部參數傳遞（marshaling）也暗示傳遞資料給予同處理緒元件的最佳規則，可能與和跨處理緒EXE伺服器一起工作所要遵守的規則不太一樣。舉例來說，在同處理緒元件的程序中使用 ByRef 或是 ByVal 的方式傳遞引數並沒有意義上的不同。但是您傳遞長字串時使用傳址的方式比使用傳值的方式佳：筆者建立了一個標準檢查程式（benchmark）（您可以在隨書光碟中找到），比較同處理緒與跨處理緒伺服器。筆者發覺利用傳值傳遞一個1000字元的字串約比利用傳址的方式慢上十倍。越長的字串，利用傳值的方式傳遞會越慢。
設定DLL 基底位址
如果您同時有多個客戶端使用相同的同處理緒元件，不同DLL的執行個體會載入每個客戶端的位址空間。這樣可能浪費許多記憶體空間，除非您做一些預防。
感謝Windows 虛擬記憶體子系統先進的功能，您可以在不同的位址空間載入相同的DLL，而不會比單一DLL執行個體的請求花費較多的記憶體。更精確的說，多個客戶端應用程式可以分享相同從磁碟機載入的DLL。然而，只有當所有DLL的執行個體載入在不同行程的記憶體空間的相同位址，這才是可能的，並且此位址與DLL的基底位址相同。
一個DLL的基底位址（base address）就是Windows試著在客戶端的位址空間內載入DLL的預設位址。如果這個嘗試成功，Windows可以快速地載入DLL，因為Windows只要預設一塊記憶體並且將DLL檔案的內容載入到此記憶體中。換句話說，假如Windows不能將DLL載入到客戶端的基底位址（最常見的是因為整個區域已經分配給其他的DLL），Windows需要尋找一塊沒有使用並且可以容納DLL的記憶體區塊，並且必須重新定位（relocate）DLL的程式碼。重新定位的程序改變DLL機器碼中轉向（jump）以及呼叫（call）指令的位址，將位址加上不同DLL的載入位址。
總結來看，一個DLL在基底位址載入是一個很好的方法的原因有兩個：
Visual Basic在 專案屬性 對話方塊的 編譯 頁籤中讓您選擇一個同處理緒元件的基底位址，如同您在圖16-15所見。此位址的預設值為H11000000,但是筆者強烈的建議您在編譯元件的最終版本之前更改基底位址的值。如果沒有更改，DLL的基底位址會與其他以Visual Basic所寫的DLL衝突。只有一個DLL會贏，其他的必須重新定位（relocated）。
| 圖16-15 您可以更改DLL的基底位址以增加效能。 |
幸運地，其他的程式語言擁有不同的基底位址預設值。舉例來說，以Microsoft Visual C++所寫的DLL的基底位址預設值為H10000000，所以即使其他語言的程式設計人員沒有更改預設值，這些以Visual Basic所寫的DLL也不會與其他的DLL有所衝突。
當您決定應該為Visual Basic DLL更改基底位址時，請將下列幾點列入參考：
舉例來說，一個容納您所能建立的最大的客戶端應用程式，大於1GB (&H40000000) 的基底位址，仍然留下1 GB 給DLL。恰好以64-KB頁面大小來計算，當您設定基底位址給予DLL時，留給您16,384不同的值供您選擇。
以非基本語言（Satellite）DLLs擴展一個應用程式
ActiveX DLL伺服器對於透過稱為非基本語言（Satellite）DLL擴展一個應用程式的功能是非常有用的。要了解非基本語言（Satellite）DLL為何那麼有用，讓我們先來了解什麼是資源檔（resource files）。
資源檔
資源檔就是檔案，通常以.res為副檔名，可以包含字串、點陣圖以及應用程式所使用的機器碼。您以兩個步驟建立資源檔。第一、您準備一個包含資源檔內容的文字檔（副檔名通常為.rc）。這個文字檔要遵循明確定義的語法。舉例來說，這裡有一個定義一個字串以及圖檔的RC檔的片段：
STRINGTABLE
BEGIN
1001 "Welcome to the Imaging application"
1002 "Do you want to quit now?"
END
2001 BITMAP c:\windows\clouds.bmp
第二、將.rc檔編譯成一個.res檔，在命令列以Rc.exe資源編譯器加上 /r參數。（Visual Basic所提供的工具）。
RC /r TEST.RC
當編譯完成以後，會得到一個主檔名與.rc檔相同的.res的檔案（在這個例子中是test.res檔）。現在您可以利用Visual Basic功能表中的「專案」中的「新增檔案」將這個新的.res檔加入Visual Basic的環境中。
說明
Visual Basic 6 使用新的「增益集」非常簡化了資源檔的建立以及編譯過程，Visual Basic資源檔案編輯器，如圖16-16。這個增益集也支援多重字串表格，可以使您的應用程式自動地符合使用者的語言。一個Visual Basic 5版本的增益集也可以由Microsof的網站下載。
| 圖16-16 VB 資源檔案編輯器可以建立點陣圖、小圖像、聲音以及多重字串表格。 |
當您建立好一個.res檔案，您的程式碼可以藉由 LoadResString、LoadResPicture 以及 LoadResData 函數引用資源檔所包含的資源。如下列例子所示：
' Print a welcome message. Print LoadResString(1001) ' Load an image into a PictureBox control. Picture1.Picture = LoadResString(2001, vbResBitmap)
當您建立一個必須在別的國家所發行的應用程式，資源檔是一個很不錯的選擇。原始程式碼完全與程式所使用的字串以及點陣圖獨立開來，當您需要建立一個不同國家新版本的應用程式時，只需要準備不同的資源檔。要學習更多有關資源檔的使用方式，請看Visual Basic 6中的ATM.VBP範例。
然而，即使擁有VB資源檔案編輯器的幫助，處理資源檔會因為下列原因而顯得麻煩：
這兩個問題都可以使用非基本語言（Satellite）DLL來解決。
非基本語言（Satellite）DLL
非基本語言（Satellite）DLL所基於的觀念很簡單。代替資源檔載入字串以及其他的資源，您從ActiveX DLL載入。技巧是您使用 CreateObject 代替New運算子從DLL建立一個物件的執行個體，因此您可以在執行時選擇您所要載入的DLL。這個技巧甚至使您可以在顧客的主要程式安裝好之後，再安裝DLL，如此一旦您準備好新的DLL，您就可以有效的增加對新語言的支援。使用者可以在執行期間轉換到其他的DLL，舉例來說，功能表。
筆者準備了一個範例程式，使用非基本語言（Satellite）DLL建立一個簡單的資料庫程式，其介面本身適應使用者的國家。當應用程式啟動，程式選擇與Windows作業系統所符合的DLL版本，如果沒有找到正確的語言，預設值為English（見圖16-17）
| 圖16-17 一個使用非基本語言（Satellite）DLL多重語言應用程式，支援English以及Italian。 |
一個提供字串、點陣圖以及機器碼的非基本語言（Satellite）DLL至少應該提供三種函數。要使非基本語言（Satellite）DLL看起來如同資源檔，您可以將函數名稱分別叫做LoadResString、LoadResPicture以及LoadResData。底下是範例程式所提供的DLL程式碼的一部份：
'The Resources class module in the Application000 project
Enum ResStringID
rsDataError = 1
rsRecord
rsPublishers
'(Other enumerated values omitted...)
End Enum
Enum ResPictureID
rpFlag = 1
End Enum
Enum ResDataID
rdDummy = 1 'This is a necessary placeholder.
End Enum
Function LoadResString(ByVal ID As ResStringID) As String
Select Case ID
Case rsPublishers: LoadResString = "Publishers"
Case rsClose: LoadResString = "&Close"
Case rsRefresh: LoadResString ="&Refresh"
'(Other Case clauses omitted...)
End Select
End Function
Function LoadResPicture(ByVal ID As ResPictureID, _
Optional Format As Long) As IPictureDisp
'Loads images from the frmResources form
Select Case ID
Case rpFlag: Set LoadResPicture = _
frmResources000.imgFlag.Picture
End Select
End Function
Function LoadResData(ByVal ID As ResDataID, _
Optional Format As Long) As Variant
'Not used in this sample program
End Function
這個特別的DLL只包含一個點陣圖並且不包含任何機器碼。為了簡單的目的，點陣圖在設計階段已經載入frmResources表單的Image控制項。這個表單不會顯示以及工作，它只是一個點陣圖的擁有者。您可以利用這個方法儲存圖示以及游標。
然而，如果您需要儲存其他類型的機器碼，您可以利用資源檔。然而，在這個例子中，每個非基本語言（Satellite）DLL擁有自己的資源檔。
使用非基本語言（Satellite）DLL的技巧是使用主要的（primary）DLL（那就是提供預設語言資源的DLL－在這個例子中的English）當作是介面，其他語言的DLL必須實作。讓我們看看Italian DLL是如何實作的：
' The Resources class module in the Application410 project
Implements MyApplication000.Resources
Private Function Resources_LoadResString(ByVal ID As _
MyApplication000.ResStringID) As String
Dim res As String
Select Case ID
Case rsPublishers: res = "Editori"
Case rsClose: res = "&Chiudi"
Case rsRefresh: res = "&Aggiorna"
' (Other Case clauses omitted...)
End Select
Resources_LoadResString = res
End Function
Private Function Resources_LoadResPicture(ByVal ID As _
MyApplication000.ResPictureID, Optional Format As Long) _
As IPictureDisp
Select Case ID
Case rpFlag: Set Resources_LoadResPicture = _
frmResources410.imgFlag.Picture
End Select
End Function
Private Function Resources_LoadResData(ByVal ID As _
MyApplication000.ResDataID, Optional Format As Long) As Variant
' Not used in this program
End Function
注意到這個類別在主要的介面中沒有成員。Italian DLL儲存成 MyApplication410.vbp，而預設的DLL儲存成MyApplication000.vbp。這個命名結構的原因待會就會清楚明瞭。
本土化﹙Locale-aware﹚客戶端應用程式
讓我們看看一個客戶端的應用程式如何能利用非基本語言DLL的力量以及彈性，自動地適應使用者的國別，同時仍然提供它們在執行時轉換到其他語言的能力。這個秘密就是一個API函數，GetUserDefaultLangID，傳回國別識別碼給互動的使用者。客戶端應用程式利用識別碼建立DLL的名稱然後傳遞給 CreateObject 函數，如下面的範例所示：
' The main BAS module in the client application
Declare Function GetUserDefaultLangID Lib iikernel32lu () As Long
Public rs As New MyApplication000.Resources
Sub Main()
InitLanguage ' Load the satellite DLL.
frmPublishers.Show ' Show the startup form.
End Sub
' Load the satellite DLL that corresponds to the current user's locale.
Sub InitLanguage()
Dim LangId As Long, ProgID As String
' Get the default language.
LangId = GetUserDefaultLangID()
' Build the complete class name.
ProgID = App.EXEName & Hex$(LangId) & "Resources"
' Try to create the object, but ignore errors. If this statement
' fails, the RS variable will point to the default DLL (English).
On Error Resume Next
Set rs = CreateObject(ProgID)
End Sub
這個技巧的主要關鍵在 InitLanguage 程序，也就是應用程式動態建立提供資源給予正確國別的DLL的程序。舉例來說，執行在Italian版本的Windows，GetUserDefaultLangID API函數回傳值為1040，或是&H410。
您可以建立其他語言的非基本語言DLLs然後送給不同國家的顧客。這個方式一直執行的很好，提供您設定一個專案名稱如MyApplicationXXX，而XXX 就是十六進位的國別識別碼。（對於國別識別碼的列表，見Windows SDK ）。專案名稱前面的部分必須對應到客戶端應用程式專案的名稱（在這個例子中的MyApplication），但是您可以發明設計其他的方式動態建立DLL的名稱。如果 CreateObject 函數失敗，rs 變數不會在 InitLanguage 程序中被初始化，但是因為它被設定為自動執行個體化（auto-instancing）的變數，它自動地建立MyApplication000.Resource元件的執行個體。在這裡的關鍵點是對於這個特殊的應用程式中的所有非基本語言DLL實作了相同的介面，所以rs變數可以使用早期連結抓住任何非基本語言DLL的引用。看看在客戶端應用程式的表單中如何使用 rs 變數：
Private Sub Form_Load()
LoadStrings
End Sub
Private Sub LoadStrings()
Me.Caption = rs.LoadResString(rsPublishers)
cmdClose.Caption = rs.LoadResString(rsClose)
cmdRefresh.Caption = rs.LoadResString(rsRefresh)
' (Other string assignments omitted...)
Set imgFlag.Picture = rs.LoadResPicture(rpFlag)
End Sub
因為MyApplication000.Resource類別對於所有非基本語言DLL中的字串以及其他資源宣告為列舉常數，您可以使用IntelliSense來加速發展階段以及在同時產生更具有可讀性以及文件方式的程式碼。
多執行緒ACTIVEX元件
Visual Basic 5以及6都可以建立多執行緒ActiveX元件。然而，在Visual Basic 5第一個發行版本中只有不含使用者介面的元件擁有多執行緒，這是一個嚴重的限制。這個限制在Service Pack 2中解除了。
執行緒模型
概括來說，多執行緒就是在應用程式中同時可以處理不同部分程式碼的能力。許多受歡迎的Windows應用程式都是多執行緒。舉例來說，Microsoft Word至少使用兩個執行緒，Visual Basic發展環境至少使用五個執行緒。當您要在背景執行複雜的工作（舉例來說，為文件標上頁數）或是當您要保持使用者介面而您的應用程式正在做其他事情的時候，多執行緒是您不錯的選擇。當您建立一個必須在同時服務上百個客戶端的scalable遠端元件時，多執行緒特別是必要的。
這裡有兩個主要的多執行緒模型：自由執行緒（free threading）以及公寓執行緒（apartment threading）。在自由執行緒模型中，每個執行緒可以存取整個處理緒的資料區域以及可以分享所有的全域變數。自由執行緒是功能強大並且有效率的，但是它卻是一個惡夢，即使對有經驗的程式設計人員而言，因為您必須仲裁所有的共享資源，包含變數。舉例來說，即使是一個無害的程式：
If x > 1 Then x = x - 1 ' X should always be greater than 1.
都能製造問題。想像這樣的情節：執行緒A讀取x變數的值為2，但是當它執行到 Then的部分，CPU轉換到B。執行緒B開始執行同樣的程式，發覺變數為2，然後減為1。當執行緒A重新得到CPU的控制權，又將變數減為0，這是一個不合法的值並且在稍後的程式生命中可能造成其他邏輯上的錯誤。
公寓模型將每個執行緒封裝在公寓之中以解決這樣的問題。在公寓中的程式碼不能存取其他公寓中的變數。每個公寓擁有自身的變數集合，所以如果有兩個執行緒同時存取變數 x，實際上它們所參考的事不同記憶體位址的變數。這個機制恰好解決之前所提到的同步問題，因此公寓執行緒模型比起自由執行緒模型來的安全。在Visual Basic中，您只能建立支援公寓模型的ActiveX元件。
多執行緒ActiveX EXE元件
Visual Basic 5以及6讓您建立跨處理緒伺服器時，客戶端新建立一個執行個體，就增加一個新的執行緒。將一個正規的Active X EXE轉換成多執行緒的元件，您所要做的就是在 專案屬性 對話方塊的 一般 頁籤選擇一個選項，（見圖16-18）。這裡有三個選項設定。在 執行緒共用區 的預設值為1個執行緒，對應到單一執行緒元件。
| 圖16-18 在「專案屬性」對話方塊中，使用滑鼠點去數下，建立一個多執行緒元件。 |
如果您選擇 獨立的執行緒 選項，您所建立的多執行緒元件，是當有客戶端的請求時，就對每一個物件建立一個執行緒。因為每一個物件擁有各自的執行緒，沒有客戶端會被其他的客戶端阻塞，所以這些元件擁有最快速的反應。這個方式的缺點是，即使是強大的系統也會被拖慢因為Windows要花費許多的時間做執行緒的交換。
執行緒共用區
如果您選擇 執行緒共用區 選項，並且在執行緒欄位中輸入超過1的值，您建立了一個只能允許一定數量的執行緒的多執行緒元件。這是一個變通的解決方式，當您部署您的元件在功能較強的系統時，您可以增加執行共用區的大小。（雖然您要重新編譯）這個設定防止系統花太多的時間在執行緒的管理上，因為執行共用區不能超過您所設定的值。分配執行緒給予物件，共用區使用round robin演算法，總是試著分配最先可使用的執行緒給予每個物件新的請求。
我們假設您建立一個執行共用區大小為10的多執行緒元件。當第一個客戶端請求一個物件時，COM載入元件，在第一個執行緒傳回所建立的元件。當第二個客戶端請求物件，COM再第二個執行緒建立物件，然後照此方式一直下去，直到第十個客戶端得到最後一個執行緒。當第十一個請求來時，元件需要傳回之前已經建立的其中之一執行緒中的物件。這個新物件所使用的執行緒無法在之前預測，因為這是許多因素而定。為這些因素，round robin演算法可以說是不可預測的演算法。
這裡有幾點關於執行緒共用區有性的事項：第一、當物件數量大於執行緒時，每個執行緒服務一個以上的物件，物件可能屬於不同的客戶端。在這種情況下，如果執行緒已經服務其他的物件，則此執行緒目前不能執行此物件的方法。換句話說，一個物件共用區並不能完全地防止物件之間的阻礙（如同單一執行緒物件一般），即使這種問題比發生在單一執行緒元件的頻率少。
第二、物件一但在執行緒中建立起來，它必須一直在此執行緒中執行，這是公寓執行緒模組的必要條件。因此，即使有其他未被分派的執行緒，一個客戶端仍有可能被牽制住。想像一個情節：您擁有十個執行緒的共用區，您建立了二十個物件。在理想的狀況下，共用區維持很好的平衡，每個執行緒服務兩個物件。但是加設1到9執行緒的所有物件都被釋放了，此時仍有兩個物件在執行緒10。在這種情況下，共用區變的極為的不平衡並且兩個物件會互相牽制，即使共用區仍有9個執行緒。
最後，即使公寓模型保證每個公寓有不同的變數集合，在同樣執行緒中的物件分享相同的公寓並且分享相同的全域變數。這可能是一個在物件之間交換資料的簡單方式，但是實際上您不能使用這個方法因為您不能預測哪些物件會分享同一個執行緒。
多執行緒的好處
許多程式設計人員誤認為多執行緒就是好的方式。然而，事實上大多數的電腦都只有一個CPU，要執行系統中所有處理緒中的所有執行緒。如果您在多個CPU的Windows NT平台上執行您的元件，多執行緒是一件好事，在這種情況下，作業系統自動利用多餘的CPU平衡工作負載。然而，在大多數一般的情況中，您是在單一CPU的電腦上工作，並且您會發現多執行緒使您的效能降低。這跟直覺上有點不同，所以筆者在稍後的例子中做解釋。
假設您擁有兩個執行不同工作的執行緒，每個工作需要10秒完成。在單一執行緒的環境中，每個工作需要10秒來完成，另一個工作等待第一個完成後在接著完成工作，因此需要20秒。結果是每個工作平均要15秒來完成。在多執行緒的環境中，兩個工作可以平行地完成並且花費差不多相同的時間完成。除非您有兩個CPU，在這個例子中，平均花費20秒，效能比單一執行緒要差。
總結來看，多執行緒並不總是最佳的解決方式。然而，有時清楚地提供超越單一執行緒好處。
當您在單一執行緒以及多執行緒之間作決定時，不要忘記Visual Basic間接地在某些工作中使用多執行緒－舉例來說，如列印資料。此外，一些資料庫引擎（最顯著地，Microsoft Jet引擎）內部使用多執行緒。
使用者介面的問題
Visual Basic 6讓您建立提供使用者介面的多執行緒元件（您在Visual Basic 5中需要Service Pack 2以提供這項功能）。您可以達到這個目的是因為所有您建立的表單以及ActiveX控制項是安全於執行緒的（thread safe），也就是說在每一個執行緒中的執行個體是不相關的。在ActiveX文件以及設計師也是相同的，例如DataEnvironment設計師，和大部分在package中的ActiveX控制項一樣 - 舉例來說，MaskEdBox 控制項以及所有Windows一般的控制項。
但是有少數的ActiveX控制項天生就是單一執行緒並且不能安全地使用於多執行緒元件中－舉例來說，Microsoft Chart (MSCHRT20.OCX)以及Microsoft Data Bound Grid (DBGRID32.OCX)控制項。如果您試圖將這些控制項加入一個執行緒模型為公寓模型的ActiveX DLL 專案或是加入一個執行緒模型為 獨立的執行緒 或是執行緒數量大於1的 執行緒共用區 的ActiveX EXE 專案，您會得到一個錯誤訊息並且控制項不能加入工具列之中。如果您有一個已經包含一個以上的單一執行緒控制項並且將專案類型更改成與這些控制項不相容，您也會得到一個錯誤訊息。當您購買一個其他廠商提供的控制項，請與賣主核對控制項是否支援多執行緒。
注意
您可以手動編輯VBP檔案讓Visual Basic在多執行緒的專案中強制接受單一執行緒的ActiveX控制項。然而，有許多理由讓您不要這麼做。在多執行緒應用程式中執行單一執行緒的效能很差，並且會產生許多問題以及不可預期的行為。舉例來說，Tab鍵以及Alt+鍵的組合不能如一般的正常工作，點取控制項可能不能啟動表單。此外，有些屬性(最特別的是Picture屬性)的值不能在執行緒之間傳遞，嘗試去做會產生執行時期的錯誤。
這裡有關於多執行緒內的表單的一些小問題：
執行時無使用者介面
如果您的元件不包含一個表單、UserControl或是UserDocument方法，您可以點取 專案屬性 對話方塊中的 一般 頁籤的 執行時無使用者 介面。這表示您的元件執行時沒有使用者的互動關係，當您建立一個遠端電腦的元件時適當的選項。
執行時無使用者介面 抑制任何訊息方塊或是友善的使用者介面（包含錯誤訊息）並且將訊息轉存到記錄檔案或是Windows NT應用程式事件檢視器。您也可以傳送自己的訊息道記錄檔中。對於遠端物件使用此選項是非常重要的因為任何的訊息方塊會停止元件的執行直到使用者關閉訊息方塊，當事當元件在遠端執行時沒有互動的使用者會實際去關閉訊息方塊。
App物件的 StartLogging 方法讓您選擇您的訊息將送到何處。語法如下：
App.StartLogging LogFile, LogMode
LogFile 是記錄檔的名稱，LogMode 表16-2中的一個值。VbLogOverwrite以及vbLogThreadID 的設定可以與表中其他的值結合。當您傳送一個訊息給Windows NT應用程式事件檢視器，"VBRunTime" 當作應用程式的來源，App.Title 屬性出現在描述中。當您在Windows 95或是98執行時，訊息送到預設的Vbevents.log檔案。
說明
小心兩個錯誤。第一、如果您指定一個不合法的名稱，不會有錯誤產生並且不知不覺地將訊息送到預設的地方。並且，vbLogOverwrite選項使得 StartLogging 方法的行為如同vbLogAuto選項被指定。所以您應該總是手動刪除記錄檔並且不要相信vbLogOverwrite選項。
| 常數 | 值 | 描述 |
|---|---|---|
| VbLogAuto | 0 | 若您在 Windows 95 上執行，則這個選項會註冊訊息到 LogFile 屬性所指定的檔案中。但若您是在 Windows NT 上執行，則會註冊到 Windows NT 應用程式 Event Log 中。以「VBRunTime」作為應用程式的來源，並以 App.Title 作為描述。 |
| VbLogOff | 1 | 關閉所有的註冊。從 UI 轉換以及從 LogEvent 方法中的訊息都會忽略並關閉。 |
| VbLogToFile | 2 | 強制登入到檔案中。如果在 LogPath 中沒有可使用的檔案名稱，那麼將忽略註冊，並設定屬性為 vbLogOff。 |
| VbLogToNT | 3 | 強制登入到 NT 事件註冊檔中。若不是在Windows NT 上執行，或事件註冊無效，將忽略註冊，並將屬性設定為vbLogOff。 |
| VbLogOverwrite | 16 | 指示每次啟動應用程式時，應該重新建立註冊檔。若使用 OR 運算子，便可與其他模式的選項並用。而註冊的預設動作為附加到現存的檔案中。在 NT 事件註冊的情況下，這個旗標就不具任何意義。 |
| VbLogThreadID | 32 | 指出在表單 「[T:0nnn]」 中，目前被預設到訊息中的通行 ID 。若使用 OR 運算子，便可與其他模式的選項並用。只有當應用程式為多工使用時，預設動作才會顯示通行 ID (可能是明確標示為安全通行的，或者是作為處理多工使用應用程式的工具，例如多工使用的區域伺服器，其某個屬性設定 Single-Use)。 |
| 表16-2 App物件的StartLogging方法的LogMode引數所有的值﹔這些也是LogMode 唯讀屬性可能傳回的值。 |
一但您已經設定記錄檔，您可以使用App物件的 LogEvent 方法記錄訊息。語法如下：
App.LogEvent LogMessage, EventType
LogMessage 是訊息的文字內容，EventType 選擇性的引述，代表事件類型的狀態（下列值得其中之一：1-vbLogEventTypeError、2-vbLogEventTypeWarning或是4-vbLogEventTypeInformation）。舉例來說，下列程式碼的片段：
App.StartLogging "C:\Test.Log", vbLogAuto App.LogEvent "Application Started", vbLogEventTypeInformation App.LogEvent "Memory is running low", vbLogEventTypeWarning App.LogEvent "Unable to find data file", vbLogEventTypeError MsgBox "Press any key to continue", vbCritical
如果在Windows 95 或是 98 執行，將輸出送到C:\TEST.LOG 檔案，或是在Windows NT執行，則輸出到應用程式事件檢視器。（見圖16-19）
| 圖16-19 Visual Basic應用程式所產生的記錄訊息，出現在一個記錄的文字檔中﹙上面的視窗﹚或是Windows NT應用程式事件記錄器中(底下的視窗)。 |
您可以從App物件唯讀的 UnattendedApp 屬性從程式中測試「執行時無使用者介面」屬性。同樣地，您可以使用App物件的 LogPath 以及 LogMode 屬性分別地取出正確的記錄檔案以及記錄模式。當您使用「執行時無使用者界面」屬性編譯程式，所有的 MsgBox 命令送出輸出給予記錄檔或是Windows NT應用程式事件記錄器，如同 LogEvent 方法加上 vbLogEventTypeInformation 引數的結果。
最後要注意的：如果您在Visual Basic IDE中執行程式，「執行時無使用者介面」 設定沒有影響，所有的訊息方塊如同一般地顯示在螢幕上，並且 App.StartLogging 以及 App.LogEvent 方法不能使用。要啟動記錄模式，您必須將應用程式編譯成單一的應用程式。
多執行緒ActiveX DLL 元件
您可以使用Visual Basic 6建立多執行緒的ActiveX DLL。然而，不同於ActiveX EXE伺服器，Visual Basic的DLL不能建立新的執行緒並且只能使用它們客戶端的執行緒。因此，多執行緒DLL最常使用於多執行緒客戶端應用程式。因為一個ActiveX DLL實際上不能建立任何的執行緒，在 專案屬性 對話方塊中的選項如同一個ActiveX EXE專案所提供的一般。實際上，您只能決定建立一個 單一執行緒 或是 公寓模型執行緒 伺服器。（見圖16-20）。
單一或是多重執行緒元件都是安全的執行緒（thread safe），這表示當一個執行緒中的物件被其他執行緒所呼叫，呼叫的執行緒會暫停直到被呼叫者傳回。這避免了大多數重複進入（reentrancy）的問題並且大量減低程式設計人員的工作。
雖然對多執行緒客戶端使用單一執行緒DLL是相當的安全，但在主應用程式中只有一個執行緒可以直接地呼叫DLL所建立的物件的方法。這個特殊的執行緒是客戶端應用程式第一個建立的執行緒，更精確的說，是第一個內部呼叫 OleInitialize 函數的執行緒。所有單一執行緒DLL所提供的所有物件被建立在這個執行緒中; 當它們被客戶端應用程式中的其他執行緒使用，引數以及傳回值接受稱為執行緒間的外部參數傳遞（cross-thread marshaling），幾乎跟處理緒間的外部參數傳遞（cross-process marshaling）一樣慢。
| 圖 16-20 在在「專案屬性」對話方塊中選擇執行緒模型選項。 |
當您不知道如何您的DLL會如何被使用時，公寓執行緒模型通常是最佳的選擇。事實上，一個多執行緒DLL可以被單一執行緒客戶端所使用，不會有任何問題或重大的系統負擔。在一個例子中，一個單一執行緒DLL可以方便地被一個多執行緒客戶端使用，也就是說，當您想要提供客戶端所有的執行緒一個簡單的方法相互的溝通以及分享資料。關於這個技巧的一個範例在本章稍後的〈測試多執行緒應用程式〉中。
多執行緒Visual Basic 應用程式
許多程式設計人員沒有意識到Visual Basic可以建立多執行緒的正規的應用程式，而不只是元件。老實說，建立如此的多執行緒應用程式並不如使用其他的Visual Basic的特殊功能一樣的直接簡單，並且您要解決一些重要的問題。
建立多執行緒應用程式的秘訣是簡單的：應用程式必須是一個多執行緒的ActiveX EXE伺服器，並且提供一個以上在不同執行緒執行的物件。要建立這樣的應用程式，必須完全符合以下所列出的條件：
當您使用New運算式建立一個應用程式所提供的物件，Visual Basic使用一個內部的建立執行個體的方式，跳過COM並且使用一個更有效率、不接受任何限制的機制。（事實上，您甚至可以從Private或是PublicNotCreatable類別建立物件。）反之，當您使用 CreateObject，Visual Basic總是透過COM建立物件。因此，物件應該是可建立的(MultiUse)。
決定主執行緒
如同之前筆者說明的，在一個Visual Basic多執行緒應用程式中的 Sub Main 程序在每一次一個新執行緒建立時就執行。這通常對於ActiveX EXE或是DLL來說不是一個問題，但是當您建立一個ActiveX EXE多執行緒應用程式時，這卻是一個問題。在這個例子中，很重要的事是您要把第一次的執行與其他所有的執行分別出來。當第一次 Main 程序執行時，程式必須顯示出主要的視窗，反之其他所有的執行不應該顯示任何使用者介面。更精確地說，當程序被執行如同對於一個新物件請求的結果時，應該馬上離開以避免因產生逾時錯誤而請求失敗。因此，您從不應該在 Class_Initialize 事件程序中執行冗長的動作。
要了解 Main 程序之前是否從來沒有執行過並不是一件普通的工作。您不能簡單地使用一個全域變數作為旗標，因為變數並不能被其他公寓中的執行緒看到。在 Main 中建立一個暫存檔案也不是一個可行的方式，因為應用程式可能因為嚴重的錯誤而終止並且在也不會去殺掉這個暫存檔。
這裡有至少兩種方法解決這個問題。第一種是基於Windows的 FindWindow API函數，在Visual Basic的文件中有所描述。在下一頁中，筆者將會展示另一種方法，這種方法筆者相信較不複雜並且較有效率，因為不需要您建立一個視窗。這個方法是基於原子物件( atom objects)，由Windows作業系統整理分類全域變數。Windows API提供函數讓您增加一個atom、刪除一個存在的atom或是查詢一個atom的值。
在多執行緒應用程式中的 Main 程序，您測試一個給予的atom是否存在。如果不存在，這是應用程式的第一個執行緒，並且您需要建立一個atom。要使這個方法順利工作，您必須在應用程式離開時刪除atom。在一個類別中理想的是在 Class_Initialize 程序中建立atom，在 Class_Terminate 程序中毀滅建立atom。這裡是在隨書CD中應用程式範例中Cthread類別完整的原始程式碼。
Private Declare Function FindAtom Lib "kernel32" Alias "FindAtom" _
(ByVal atomName As String) As Integer
Private Declare Function AddAtom Lib "kernel32" Alias "AddAtomA" _
(ByVal atomName As String) As Integer
Private Declare Function DeleteAtom Lib "kernel32" _
(ByVal atomName As Integer) As Integer
Private atomID As Integer
Private Sub Class_Initialize()
Dim atomName As String
' Build an atom name unique for this instance of the application.
atomName = App.EXEName & App.hInstance
' Create the atom if it doesn't exist already.
If FindAtom(atomName) = 0 Then atomID = AddAtom(atomName)
End Sub
Private Sub Class_Terminate()
' Delete the atom when this thread terminates.
If atomID Then DeleteAtom atomID
End Sub
Function IsFirstThread() As Boolean
' This is the first thread if it was the one which created the atom.
IsFirstThread = (atomID <> 0)
End Function
atom的名稱是以應用程式的名稱以及執行個體的handle(App.hInstance 屬性)所建立。後面的值對於同樣應用程式的每個不同的執行個體都是不同的，以確保使用者啟動同樣程式的多個執行個體時可以正常的工作。CThread 類別模阻止提供一個方法，IsFirstThread。以下的程式展示您如何在多執行緒應用程式中使用這個類別了解此執行緒是否為第一個執行緒。
' This is global because it has to live for the entire application's life.
Public Thread As New CThread
Sub Main()
If Thread.IsFirstThread Then
'First thread, refuse to be instantiated as a component.
If App.StartMode = vbSModeAutomation Then
Err.Raise 9999, , "Unable to be instantiated as a component"
End If
'Show the user interface.
frmMainForm.Show
Else
' This is a component instantiated by this same application.
End If
End Sub
實作多執行緒
使用 CreateObject 函數建立一個新的執行緒實際上不足以實作一個多執行緒的Visual Basic應用程式。事實上，Visual Basic所提供的同步處理的技術可以防止一些難以處理的嚴重問題，如在這個例子中所看到的。當一個程式引用一個其他執行緒物件的方法時，呼叫端的執行緒一直停止住直到所呼叫的方法回傳。所以您可能有多個執行緒，但是同時只有一個執行緒在特定的的時間裡執行，這顯然不是您所想要的。
改變這個問題的簡單方法就是使用一個Timer的控制項，在不同的執行緒傳回控制權給呼叫的執行緒之後，「叫醒」這個不同執行緒中的物件。您不需要一個可見的表單來達到此功能。您可以利用新的 CallByName 函數來建立一個表單模組，您可以在所有需要這種回呼技巧的應用程式中重複使用。下面是封裝這種功能的CCallBack表單模組的完整程式碼。
Dim m_Obj As Object
Dim m_MethodName As String
Public Sub DelayedCall(obj As Object, Milliseconds As Long, _
MethodName As String)
Set m_Obj = obj ' Save the arguments.
m_MethodName = MethodName
Timer1.Interval = Milliseconds ' Start the timer.
Timer1.Enabled = True
End Sub
Private Sub Timer1_Timer()
Timer1.Enabled = False ' We need just one call.
Unload Me
CallByName m_Obj, m_MethodName, VbMethod ' Do the callback.
End Sub
CcallBack表單可以在應用程式的其他部分以一個物件模組的方式使用。在隨書光碟中，您將找到一個簡單的多執行緒應用程式範例，應用程式可以建立以及顯示多重的 count-down 表單(見圖16-21。) 這是一個物件類別的部份程式碼，當主應用程式要在另一個執行緒中建立一個新的倒數表單時，程式碼會負責初始化。
(實作回呼技巧的程式以粗體自表示)
Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
Dim frm As frmCountDown
Dim m_Counter As Integer
'The Counter property. Values > 0 display the form and start
' the countdown.
Property Get Counter() As Integer
Counter = m_Counter
End Property
Property Let Counter(newValue As Integer)
Dim cbk As New CCallBack
m_Counter = newValue
cbk.DelayedCall Me, 50, i.Start"
End Property
Sub Start()
Static active As Boolean
If active Then Exit Sub 'Prevent reentrancy.
active = True
' The code that shows the countdown form (omitted...)
' ...
active = False
End Sub
| 圖16-21 多執行緒應用程式的範例countdown。注意每一個window在標題顯示一個不同的執行緒ID。 |
這是 count-down 範例應用程式主表單中的程式碼：
Private Sub cmdStart_Click()
Dim x As CCountDown
' Create a new CCountDown object in another thread.
Set x = CreateObject("MThrApp.CCountDown")
' Set the counter using the value currently in the TextBox control.
x.Counter = Val(txtSeconds)
Set x = Nothing
Beep
End Sub
注意
以實作Visual Basic多執行緒來說，這裡有一個沒有文件記載的要點，您應該特別注意的。如果物件正在執行某些程式碼，而客戶端將最後一個物件的引用直接或是間接地設為Nothing，那麼客戶端會一直等待到物件中的程序終止。這一點很重要的。舉例來說，如果您在前面的程序中刪除了 Set x = Nothing 敘述，那麼當物件已經被回呼程序叫醒並且正在執行 count-down程式碼時，x變數在 Beep 敘述之後會被設為Nothing。這表示客戶端需要等待將近10秒鐘，直到物件完全地銷毀，在此期間主表單無法回應使用者的動作。您可以選擇從以下兩種方式修正這個問題：
測試一個多執行緒應用程式
偵錯一個多執行緒的應用程式或是元件並不像偵錯一般的程式那麼簡單。舉一件事來說，您必須將多執行緒的應用程式或是元件編譯成單一獨立的執行檔，因為Visual Basic的IDE環境只支援單一執行緒的應用程式以及元件。 這表示您需要捨棄所有環境所提供的便利設施，包含中斷點、監看視窗、區域變數視窗以及逐步的追蹤能力。因此，您必須在轉換到多執行緒前，完整地在環境中測試您的應用程式的邏輯，您必須設計出替代的偵錯策略。舉例來說，因為您不能利用 Debug.Print 方法將變數值直接印在即時運算視窗中，您需要寫入一個檔案或是使用簡單的MsgBox命令。一個很好的想法就是在您的訊息中顯示執行緒ID，這樣您可以獲知哪一個特別的執行緒正在顯示訊息：
MsgBox "Executing the Eval proc", vbInformation, "Thread: " & App.ThreadID
單一執行緒ActiveX DLL伺服器對此問題提供一個較好的解決方式。可能您還記得，您可以安全地在多執行緒客戶端使用單一執行緒ActiveX DLL，不管它們是單一的應用程式或是元件。舉例來說，您可以實作一個提供CLog物件的DLL，CLog物件收集客戶端的追蹤資訊並轉向到一個Window。實作這樣的DLL不困難。這裡是 Clog類別的原始程式碼。（在隨書光碟中有完整的，包含附加的功能的展示程式。）
' If this property is nonzero, the ThreadID is added to the message.
Public ThreadID As Long
Sub StartLogging(LogFile As String, LogMode As Integer)
' Note that this refers to the global hidden form reference.
' This form will therefore be shared by all the instances
' of the class.
frmLog.Show
End Sub
Sub LogEvent(ByVal LogText As String)
If ThreadID Then
LogText = "[" & Hex$(ThreadID) & "]" & LogText
End If
frmLog.LogText.SelStart = Len(frmLog.LogText.Text)
frmLog.LogText.SelText = LogText & vbCrLf
End Sub
frmLog 表單屬於ActiveX DLL專案並且包含顯示來自多執行緒客戶端的文字訊息的txtLog TextBox 控制項，一個CheckBox控制項讓使用者啟動以及停止寫入，並且一個CommandButton控制項清除txtLog控制項的內容。在下一頁的圖16-22顯示一個新版本的多執行緒範例，已經加入追蹤的能力。下面是修改過的應用程式的BAS模組。
Public Log As New CLog
Sub Main()
Log.StartLogging "", 0 ' Initialize the CLog object.
Log.ThreadID = App.ThreadID
Log.LogEvent "Entering Sub Main"
'Here is the code that displays the main form (omitted...)
'...
Log.LogEvent "Exiting Sub Main"
End Sub
| 圖16-22 使用一個單一執行緒的ActiveX DLL 增加多執行緒應用程式追蹤的能力。每個訊息包含傳執行緒的ID。 |
對於更複雜的測試，您應該點取 專案屬性 對話方塊中的 編譯 頁籤的產生 Symbolic錯誤資訊 選項，然後重新編譯應用程式並且在一個真實的偵錯器下執行，這樣的偵錯器在Microsoft Visual C++中。
遠端ACTIVEX元件
ActiveX 元件可以在遠端的另一台電腦上執行。這樣一台電腦可以在相同或是不同的機房中、不同的建築物甚至是不同的城市。感謝COM位置透明化的能力，客戶端應用程式總是覺得元件在本機一般。與遠端元件執行的唯一一個問題就是所有呼叫物件方法以及屬性的動作都很慢。
討論有關COM遠端執行一個物件稱做 Distributed COM，或是簡稱DCOM，如同筆者在此章中所介紹的。DCOM第一次是與Windows NT 4發行，並且應該很清楚的表示，WindowsNT是使用遠端物件的選擇，因為Windows NT是唯一在多使用者的環境中，可以提供必要的安全性。在一個分散製作的環境中，Windows 95以及98電腦應該只能做為DCOM客戶端。
Visual Basic也支援其他遠端啟動的限制型表單，Remote Automation。筆者不想在本書中討論這個過時的技術因為這個技術比DCOM慢並且不可靠。如今，使用Remote Automation唯一的理由就是支援16-bit客戶端，這是DCOM不可能做到的，因為DCOM是只適用於32-bit的技術。
此章剩下的部分討論有關遠端的ActiveX EXE元件。您也可以在遠端執行一個ActiveX DLL，可以使用標準的代理處理序，如DllHost.Exe或是使用Microsoft Transaction Server (MTS)。在MTS中建立元件不包含在此書中。
說明
雖然Windows 95或是98的電腦在產品環境來說，不是一個好的DCOM伺服器，但是您仍然可以在發展階段作為伺服器。這不是一個有效率解決方式並且還有其他的缺點。舉例來說，沒有啟動的能力，COM元件必須是已經執行以接受遠端的請求。關於更多的資訊，見Microsoft Knowledge Base article Q165101。
建立以及測試一個遠端元件
如果您已經在本機電腦建立並且測試一個ActiveX EXE元件，轉換成遠端元件不需要重先編譯。您所要做的只是在本機電腦的登錄資料庫中改變幾個機碼，如此所有對於此物件的請求自動轉到其他的電腦。理論上，您可以以專業版的Visual Basic發行遠端元件，然而，實際上，只有企業版的Visual Basic包含可以讓您容易部署元端元件的所有工具。
編譯時的遠端伺服器設定
第一件您所要做的事是當您建立一個遠端物件時，點取 專案屬性 對話方塊中元件頁籤中的 遠端伺服器檔案 核取方塊，如下頁的圖16-23所示。如果選擇此選項，當您編譯專案時，Visual Basic建立兩個附加的檔案。檔案擁有相同的名稱但是副檔名不同：.tlb型態程式庫以及.vbr註冊檔案。這些檔案稍後使用於註冊元件在客戶端工作站的登錄資料庫上，而不用實際安裝EXE檔案。
| 圖16-23 準備一個ActiveX EXE元件於遠端執行。 |
設定伺服器
下一步驟就是在伺服器工作站上安裝以及註冊元件。您可以複製EXE檔案到一個本機磁碟，並且在命令列加上 /REGSERVER 引數執行此檔案來完成這些步驟。將元件放置在本機磁碟機而不是網路磁碟機的做法是明智的，因為這些設定會產生一些安全上的問題。在元件註冊完成後，您可以繼續讓元件在遠端客戶端可以使用。您可以選擇一些工具完成這種工作。
第一個最簡單的工具群組就是Remote Automation Connection Manager。這個程式有一個雙重的目的：您可以使用 客戶端存取 頁籤的命令使本機的元件可以讓遠端的客戶端使用，以及您可以在客戶端的電腦上執行這個工具來更改登錄資料庫中的欄位，如此所有來自特定物件的請求會轉換到伺服器電腦。
當Remote Automation Connection Manager開始時，它顯示所有電腦上所註冊的元件的列表，如圖16-24。使用 客戶端存取 頁籤中的選項，您可以決定個別的元件是否應該由遠端啟動。
不允許建立遠端物件： 此項設定讓所有註冊的元件不能被遠端客戶端所使用。
允許使用索引見建立遠端物件： 您可以讓個別的物件遠端啟動，每個元件的狀態依據 允許遠端啟動 檢查方塊。在Windows 98以及95來說這是一項好的選擇因為作業系統不支援ACLs (見下一個選項)。
| 圖16-24 Remote Automation Connection Manager的「客戶端存取」頁籤 |
允許使用ACL建立遠端物件： 這個選項只有在Windows NT下才可以使用並且讓您決定哪些使者同意或是不允許使用元件。
允許建立所有遠端物件： 所有註冊的元件都可以遠端啟動，這個設定應該只能用於發展以及偵錯階段，因為這個設定會讓伺服器電腦難以防守客戶端惡意的破壞。
測試客戶端
一個快速測試您元件如何遠端地工作的方法是安裝在一個客戶端的電腦如同一個本機元件一般﹙複製EXE檔案並且加上 /REGSERVER 引數執行﹚。啟動客戶端應用程式，確定一切如預期般的運作。這個步驟對於整理分析元件為何不能遠端啟動的問題來說是很重要的。
現在您可以執行Remote Automation Connection Manager以更改登錄資料庫，如此所有的物件請求將轉向到伺服器。在這個例子中，您需要使用程式的 伺服端連結 頁籤，如下頁的圖16-25所示，您選擇 Distributed COM 設定然後利用Ctrl+R或是 註冊 功能表中的 遠端電腦 或是在視窗中按下滑鼠右鍵選取 遠端電腦 使物件成為遠端。要完成此註冊程序，您需要指定元件執行個體所在的網路位置。當您使用DCOM時，這個工具不允許您指定網路通訊協定以及認證等級。
再次執行客戶端並且確定每一件事都正常工作，如果您沒有發生任何錯誤，物件將會在伺服器建立實體。您可能在伺服器的螢幕上看不到遠端物件，但是當客戶端請求時您可以檢查並發現出現在處理緒的列表中。
| 圖16-25 Remote Automation Connection Manager的「伺服端連結」頁籤。 |
CreateObject函數
Visual Basic 6 改進了 CreateObject 函數，提供第二個選擇性的參數，給予客戶端可以指定特定的遠端電腦建立執行個體。如下列程式碼：
Set x = CreateObject("RemoteSvr.TestClass", "ServerNT")
這些功能讓使用者可以寫出更聰明的客戶端，可以實作出一個容錯的機制，並且如果登錄資料庫所指到的電腦不能使用，可以在另外一台工作站建立物件的實體。感謝這項能力，一個分散式的應用程式也可以實作一個精密的負載平衡（load-balancing）的演算法讓負載重的元件可以在閒置的電腦上執行。
部署元件
Remote Automation Connection Manager對於測試連結到元件的客戶端應用程式來說是很好的，但是它的互動式性質卻妨礙了實際將這些應用程式部署到多台工作站上。這個問題的解決方式在客戶端設定工具，CliReg32.Exe。您可以在Visual Studio 主目錄下的Common\Tools\CliReg 目錄中找到這個檔案，並且您應該確定它是在客戶端安裝封包中。
您（或是您安裝的程序）需要執行CliReg32應用程式並且傳遞元件編譯時所產生的VBR檔案給予CliReg32。VBR 檔案只不過是一個不同副檔名以及不同檔案開頭的REG檔案。CliReg32工具讀取這個檔案，使用命令列所給予的設定，將所有相關的機碼加入登錄資料庫中，語法如下：
CliReg32 <vbrfile> <options>
所有可利用的選項列在表16-3。
| 選項 | 描述 |
|---|---|
| -d | 使用DCOM<而不是Remote Automation> |
| -t <typelib> | 指定typelib檔為<typelib> |
| -a | 指定安全認證等級為<a>（1-6） |
| -s <address> | 指定網路位置<s> |
| -p <protocol> | 指定網路通訊協定為<p> |
| -u | 移除<VBRFile>的安裝 |
| -l | 將錯誤訊息記錄至"clireg.log"檔中 |
| -q | 安靜模式：不出現對話方塊 |
| -nologo | 不顯示版本資訊 |
| -h or -? | 顯示本訊息 |
| 表16-3 CliReg32 工具的選項。 |
設定DCOM
DCOMCNFG是設定DCOM主要的工具。當您第一次執行這個工具，它快速掃描系統中已經登錄的元件並且將它們的識別碼加入登錄資料庫中的HKEY_CLASSES_ROOT\AppID，準備將這些元件供給遠端執行。登錄資料庫中的這個位置集合了所有元件的安全性的資訊。雖然有少數的元件自行註冊這些機碼，但這不會發生在Visual Basic所編寫的元件上。注意DCOMCNFG對於每一個ActiveX伺服器顯示一個AppID，甚至於伺服器提供多個類別。
DCOMCNFG啟動以及不啟動DCOM是以一整個整體來看。在 預設屬性 頁籤上，如下一頁的圖16-26，您應該點取 在這台電腦上起用DCOM 。此選項必須被選擇以擁有正確的電腦工作，在DCOM連結中作為伺服器或是客戶端。
您必須重新開機以使設定完成。
預設認證等級以及模擬等級
DCOMCNFG讓您設定DCOM預設安全性以及對於每個特定元件的安全性。這種安全性的種類稱為declarative security，並且可以從元件外部做設定。DCOM 也支援programmatic security，讓程式設計人員可以在元件執行時動態更改元件的安全性，甚至對於每個基礎的方法設定不同的安全等級。不幸地，計劃性的安全性在Visual Basic的能力之外。
| 圖16-26 DCOMCNFG 工具的「預設屬性」頁籤。 |
預設認證 等級選項告訴DCOM應如何檢查實際上來自客戶端的資料。較高的認證等級保護伺服器免於資料竄改，但同時降低了對客戶端的通訊。DCOM所支援的認證等級列於表16-4：
| 值 | 等級 | 描述 |
|---|---|---|
| 0 | 預設 | 對應連結認證 |
| 1 | 無 | DCOM不以任何方式認證資料 |
| 2 | 連結 | DCOM只在第一次連結到客戶端時認證客戶端 |
| 3 | 呼叫 | DCOM 在每一個呼叫方法以及屬性的開始認證客戶端 |
| 4 | 封包 | DCOM認證每一個來自客戶端的資料封包 |
| 5 | 封包完整性 | 跟前一等級相同，但是檢查的技巧確保資料在傳輸中沒有更動。 |
| 6 | 封包加密 | 跟前一等級相同，但是資料加密以確保不會被味精認證的程式所使用。 |
| 表16-4 DCOM認證等級。 |
模擬等級定義了在客戶端元件所能做的動作。較低的模擬等級，客戶端對於行為不端的元件有較多的保護。預設的模擬等級欄位，是測定分派給所有元件的模擬等級，不要以不同的值覆蓋這個設定。DCOM提供四種模擬等級，列於表16-5。
| 值 | 等級 | 描述 |
|---|---|---|
| 1 | 匿名 | 伺服器不知道任何的客戶端，因此不能模擬（這個等級不是正確的支援，預設值為識別） |
| 2 | 識別 | 伺服器有足夠的資訊在ACL中模擬，可以檢查但是不能如同客戶端一般存取系統物件。 |
| 3 | 模擬 | 伺服器可以模擬客戶端的行為 . |
| 4 | 代理 | 伺服器可以模擬客戶端呼叫其他的伺服器(只有Windows 2000.支援) |
| 表16-5 DCOM模擬等級。預設為識別。 |
存取與啟動權限的預設值
在 預設安全性 頁籤，您選擇列表中的使用者使其可以執行或是使用所有的不提供給認證使用者列表的元件。要使用一個元件，一個使用者必須包含在「存取權限」列表中，要啟動一個元件，使用者必須包含在 啟動權限 列表中。兩者都是Windows NT 存取控制列表，如圖16-27。您不應該更改這些列表；您應該更改個別的關於每個元件的ACLs，如同筆者之前所解釋的。重要的是 SYSTEM要包含在存取以及啟動的列表中，否則，元件不能啟動。
預設設定權限 列表包含所有允許更改所有不提供給認證使用者列表的元件的安全設定。您不應該更改這些設定值，因為限制存取登錄資料庫可能引發以Visual Basic所寫的元件的問題，就是在每次啟動時註冊它們自己。
| 圖16-27 DCOMCNFG工具的「預設值」頁籤。 |
身分設定
如果您轉換到DCOMCNFG工具的 應用程式 頁籤並且在一個元件的名稱上按兩下，另一個視窗會出現；這個視窗就是您更改特定元件的安全設定以及其他屬性的地方。舉例來說，在 一般 頁籤中，您可以對於此元件設定一個安全等級，您可以完全地定義哪些使用者可以存取以及啟動此元件以及可以更改設定權限。
最有趣的是設定是 身分驗證 頁籤，如圖16-28。
| 圖16-28 DCOMCNFG工具的「識別碼」頁籤。 |
這裡您決定在何種使用者帳號下元件將會執行。DCOM提供下列三種選擇：
互動的使用者 這個選項分配元件的使用者的安全性憑證是目前登入電腦使用者。實際上這不是一個好的選擇，因為權限同意元件依據登錄使用者的不同而改變。如果沒有使用者登入，元件甚至不可以執行。實際上，此選項只有您正在測試元件時有意義。
所有的元件執行的帳號不同於執行在一個noninteractive window station的互動式使用者的帳號，並且在桌上型電腦上看不到。如果您想要見到元件的輸出，必須執行在 互動的使用者 的 身分驗證 之下。為了相同的原因，除非您百非之百的確定您的元件會執行在互動的使用者帳號之下，您應該使用 執行時無使用者介面 選項進行編譯。如果您沒有這麼做並產生一個錯誤，那麼元件將永遠的等待因為沒有使用者可以點取錯誤訊息方塊。
啟動的使用者 這個選項分配元件的使用者的安全性憑證是正在執行客戶端的應用程式的使用者。這個選項通常也不是一個好的選擇，因為不同的客戶端建立的遠端物件的執行個體必須執行在不同的憑證之下，所以不可能只執行同一元件的多個執行個體。在這種情形中，元件的表現多少像是一個SingleUse元件，甚至元件事編譯成MultiUse。並且，如果一個元件執行在一個遠端客戶端的帳號下，元件將不能呼叫其他電腦上的元件，至少在Windows NT 4 (不支援代理模擬等級)。
指定的使用者 這個選項分配元件的使用者的安全性憑證是元件的。在產品的環境中，這常常是最佳的選擇因為只有一個MultiUse元件的執行個體會被建立。實際上，最好就是為此目的建立一個新的使用者，給予其適當的系統存取權限，然後讓元件與新的使用者憑證一起執行。使用這種方法，您可以利用這個虛擬的使用者更改多個元件的存取權限。
重要的是這個使用者可以如批次檔的方式被分配登入的權限，另外當元件啟動將失敗時，登入程序將不知不覺的啟動。在指定的使用者欄位，DCOMCNFG會自動分配這種權線給予使用者，您所要做的事不要意外地從Windows NT使用者管理工具撤銷這種權力。
實作一個回呼的技巧
您可以大大的增進您遠端元件的效率就是事件通知。雖然您差勁的在DCOM下工作(但是沒有在Remote Automation)，它們是多麼的沒有效率因此筆者強烈建議您不要使用。取而代之的，您應該時做一個回呼的技巧。
回呼的技巧工作方式如下：當客戶端呼叫一個冗長的物件方法，同時傳遞一個定義在客戶端的物件的引用，元件將此引用儲存在區域變數中。物件的引用是使用在當有些事情發生，而元件要回呼客戶端的時候。
早期連結與晚期連結的回呼
回呼技巧在Visual Basic 4的時候就可以使用，但是在Visual Basic 4中只有晚期連結的回呼可以使用，讓我們描述一個回呼的範例，假設您已經建立好一個一般的重複使用的報告列印引擎：任何的客戶端都可以建立實體並且啟動一個列印工作。當列印完成或是有錯誤發生，伺服器就回呼客戶端。
在這種情節中，列印伺服器在編譯時不知道客戶端所傳遞過來的物件類型。元件只能用 As Object 儲存物件的引用，表示這是通知是透過晚期連結來完成。客戶端以及元件必須同意在類別中用於回呼的方法的名稱以及文法。任何客戶端或是伺服器上所發生的文法錯誤只能在執行時才發現。如同您所知的，晚期連結較早期連結沒有效率，所以如果在Visual Basic 5以及6中您應該避免，Implements 關鍵字允許您實行一個在客戶端以及伺服器嚴格的限制。元件包含一個PublicNot-Creatable類別，定義回呼的介面。並且任何要接收伺服器的回呼通知的客戶端需要提供一個實作介面的PublicNotCreatable類別。因此元件可以儲存引用在這樣的變數中，可以使用早期連結。
範例
在隨書光碟中，您可以找到實作一個回呼介面與其他客戶端溝通的多執行緒元件的完整程式碼。這個元件完成一個(模擬) 列印工作並且告訴客戶端工作完成的進度。元件包含定義在介面中的CPrinterCBK PublicNotCreatable類別。
'The CPrinterCBK class module.
Sub Complete(ErrCode As Long)
'
End Sub
Sub Progress(percent As Integer)
'
End Sub
底下是Cprinter類別的原始碼, 它會模擬實際上的列印：
'The CPrinter class module.
Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
Dim SaveCBK As CPrinterCBK
Dim frmTimer As frmTimer
Sub StartPrintJob(Filename As String, cbk As CPrinterCBK)
'Save the callback object for later.
Set SaveCBK = cbk
'Activate the timer that will restart this thread.
Set frmTimer = New frmTimer
With frmTimer
Set .Owner = Me
.Timer1.Interval = 100
.Timer1.Enabled = True
End With
End Sub
Friend Sub StartIt()
Dim totalTime As Single, percent As Integer
Dim t As Single, startTime As Single
'This code is executed when the timer fires.
'Unload the form, and destroy it completely.
Unload frmTimer
Set frmTimer = Nothing
'Simulate the printing process.
totalTime = Rnd * 10 + 5
startTime = Timer
Do
'Inform the client that something has happened.
percent = ((Timer - startTime) / totalTime) * 100
SaveCBK.Progress percent
' In this demo, just go to sleep for one second.
Sleep 1000
Loop Until Timer - startTime > totalTime
' Inform the client that the process has been completed.
SaveCBK.Complete 0
' IMPORTANT: destroy the reference to the client
' so that it won't be kept alive forever.
Set SaveCBK = Nothing
End Sub
元件也包含一個含有時間控制項的表單，這個表單的唯一目的是在元件從StartPrintJob 方法傳回控制權給客戶端時，叫醒元件數微秒。
'The frmTimer form module.
Public Owner As CPrinter
Private Sub Timer1_Timer()
' This procedure is executed only once.
Timer1.Interval = 0
Timer1.Enabled = False
' Yield to the companion CPrinter instance.
Owner.StartIt
End Sub
在隨書光碟中，您也可以找到一個使用這個元件並且在等待模擬的列印工作完成時完成一個CPU密集的工作（找尋質數）的客戶端應用程式。如果您沒有網路電腦，您可以執行多個此應用程式的執行個體，然後見到它們可以不互相影想干擾的多工執行，如圖16-29。
| 圖16-29 多重客戶端透過回呼與範例中的元件溝通。 |
這個客戶端應用程式包含一個PublicNotCreatable 回呼類別模組，它會傳回到伺服器元件：
' The CallbackCls class module.
Implements PrintServer.CPrinterCBK
' This class directly references controls on the main form.
Private Sub CPrinterCBK_Complete(ErrCode As Long)
frmClient.lblStatus = "Completed"
frmClient.cmdStart.Enabled = True
End Sub
Private Sub CPrinterCBK_Progress(percent As Integer)
frmClient.lblStatus = "Printing"& percent & "%"
End Sub
在客戶端應用程式主表單唯一的部分，指出產生元件個體並傳送它的引用到CallbackCls物件中：
Private Sub cmdStart_Click()
Dim prn As PrintServer.CPrinter
' Ask the CPrinter server to spool a fictitious file.
Set prn = New PrintServer.CPrinter
prn.StartPrintJob "a dummy filename", New CallbackCls
End Sub
請注意到客戶端不需要儲存CallbackCls物件的引用在一個區域變數中，因為這個變數伺服器會保持其存活。進一步地，CallbackCls類別模組可以從多重伺服器實作一個回呼技巧下工作，每個定義本身的介面。在這個例子中，類別需要包含多重的 Implements 敘述，每個支援一個回呼介面。
比較回呼與事件
回呼技巧並沒有比事件通知複雜多少。只有一件事，客戶端必須是一個本身提供一個publicCOM物件的ActiveX EXE ，並且元件必須有足夠的權利呼叫這個COM物件中的方法。換句話說，回呼有許多比事件好的特色：
注意這裡所說的回呼技巧並不限於用在遠端元件，也可以有效的使用在本機元件上。
現在您了解建立一個好的同處理緒、本機以及遠端元件的所有事情。但是Visual Basic 6也讓您建立其他類型的元件，稱做ActiveX controls。它們包含在下一章。