Delphi通過向導可以非常迅速和方便的直接建立實現COM對象的代碼，但是整個COM實現的過程被完全的封裝，甚至沒有VCL那么結構清晰可見。

一個沒有C++下COM開發經驗甚至沒有接觸過COM開發的Delphi程序員，也能夠很容易的按照教程設計一個接口，但是，恐怕深入一想，連生成的

代碼代表何種意義，哪些能夠定制都不清楚。前幾期 “DELPHI下的COM編程技術”一文已經初步介紹了COM的一些基本概念，我則想談一些個人

的理解，希望能給對Delphi下COM編程有疑惑的朋友帶來幫助。

COM (組件對象模型 Component Object Model)是一個很龐大的體系。簡單來說，COM定義了一組API與一個二進制的標準，讓來自不同平臺、不

同開發語言的獨立對象之間進行通信。COM對象只有方法和屬性，并包含一個或多個接口。這些接口實現了COM對象的功能，通過調用注冊的COM

對象的接口，能夠在不同平臺間傳遞數據。

COM光標準和細節就可以出幾本大書。這里避重就輕，僅僅初步的解釋Delphi如何進行COM的封裝及實現。對于上述COM技術經驗不足的Delphi程

序開發者來說，Delphi通過模版生成的代碼就像是給你一幅抽象畫照著畫一樣，畫出來了卻不一定知道畫的究竟是什么，也不知該如何下手畫

自己的東西。本文能夠幫助你解決這類疑惑。

再次講解一些概念

“DELPHI下的COM編程技術”一文已經介紹了不少COM的概念，比如GUID、CLSID、IID，引用計數，IUnKnown接口等，下面再補充一些相關內容

：

COM與DCOM、COM+、OLE、ActiveX的關系

DCOM（分布式COM）提供一種網絡上訪問其他機器的手段，是COM的網絡化擴展，可以遠程創建及調用。COM+是Microsoft對COM進行了重要的更

新后推出的技術，但它不簡單等于COM的升級，COM+是向后兼容的，但在某些程度上具有和COM不同的特性，比如無狀態的、事務控制、安全控

制等等。

以前的OLE是用來描述建立在COM體系結構基礎上的一整套技術，現在OLE僅僅是指與對象連接及嵌入有關的技術；ActiveX則用來描述建立在COM

基礎上的非COM技術，它的重要內容是自動化（Automation），自動化允許一個應用程序（稱為自動化控制器）操縱另一個應用程序或庫（稱為

自動化服務器）的對象，或者把應用程序元素暴露出來。

由此可見COM與以上的幾種技術的關系，并且它們都是為了讓對象能夠跨開發工具跨平臺甚至跨網絡的被使用。

Delphi下的接口

Delphi中的接口概念類似C++中的純虛類，又由于Delphi的類是單繼承模式（C++是多繼承的），即一個類只能有一個父類。接口在某種程度上

可以實現多繼承。接口類的聲明與一般類聲明的不同是，它可以象多重繼承那樣，類名 = class (接口類1，接口類2… )，然后被聲明的接口

類則重載繼承類的虛方法，來實現接口的功能。

以下是IInterface、IUnknown、IDispatch的聲明，大家看出這幾個重要接口之間是什么樣的聯系了嗎？任何一個COM對象的接口，最終都是從

IUnknown繼承的，而Automation對象，則還要包含IDispatch，后面DCOM部分我們會看到它的作用。

IInterface = interface

??? [''''{00000000-0000-0000-C000-000000000046}'''']

??? function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;

??? function _AddRef: Integer; stdcall;

??? function _Release: Integer; stdcall;

end;

IUnknown = IInterface;

IDispatch = interface(IUnknown)

??? [''''{00020400-0000-0000-C000-000000000046}'''']

??? function GetTypeInfoCount(out Count: Integer): HResult; stdcall;

??? function GetTypeInfo(Index, LocaleID: Integer; out TypeInfo): HResult; stdcall;

??? function GetIDsOfNames(const IID: TGUID; Names: Pointer;

????? NameCount, LocaleID: Integer; DispIDs: Pointer): HResult; stdcall;

??? function Invoke(DispID: Integer; const IID: TGUID; LocaleID: Integer;

????? Flags: Word; var Params; VarResult, ExcepInfo, ArgErr: Pointer): HResult; stdcall;

end;

對照“DELPHI下的COM編程技術”一文，可以明白IInterface中的定義，即接口查詢及引用記數，這也是訪問和調用一個接口所必須的。

QueryInterface可以得到接口句柄，而AddRef與Release則負責登記調用次數。

COM和接口的關系又是什么呢？COM通過接口進行組件、應用程序、客戶和服務器之間的通信。COM對象需要注冊，而一個GUID則是作為識別接口

的唯一名字。

假如你創建了一個COM對象，它的聲明類似 Txxxx= class(TComObject, Ixxxx)，前面是COM對象的基類，后面這個接口的聲明則是：Ixxxx =

interface(IUnknown)。所以說IUnknown是Delphi中COM對象接口類的祖先。到這一步，我想大家對接口類的來歷已經有初步了解了。

聚合

接口是COM實現的基礎，接口也是可繼承的，但是接口并沒有實現自己，僅僅只有聲明。那么怎么使COM對象對接口的實現得到重用呢？答案就

是聚合。聚合就是一個包含對象（外部對象）創建一個被包含對象（內部對象），這樣內部對象的接口就暴露給外部對象。

簡單來說，COM對象被注冊后，可以找到并調用接口。但接口不是僅僅有個定義嗎，它必然通過某種方式找到這個定義的實現，即接口的“實現

類”的方法，這樣才最終通過外部的接口轉入進行具體的操作，并通過接口返回執行結果。

進程內與進程外（In-Process, Out-Process）

進程內的接口的實現基礎是一個DLL，進程外的接口則是建立在應用程序（EXE）上的。通常我們建立進程外接口的目的主要是為了方便調試（

跟蹤DLL是件很麻煩的事），然后在將代碼改為進程內發布。因為進程內比進程外的執行效率會高一些。

COM對象創建在服務器的進程空間。如果是EXE型服務器，那么服務器和客戶端不在同一進程；如果是DLL型服務器，則服務器和客戶端就是一個

進程。所以進程內還能節省內存空間，并且減少創建實例的時間。

StdCall與SafeCall

Delphi生成的COM接口默認的方法函數調用方式是stdcall而不是缺省的Register。這是為了保證不同語言編譯器的接口兼容。

雙重接口（在后面講解自動化時會提到雙重接口）中則默認的是SafeCall。它的意義除了按SafeCall約定方式調用外，還將封裝方法以便向調

用者返回HResult值。SafeCall的好處是能夠捕獲所有異常，即使是方法中未被代碼處理的異常，也可以被外套處理并通過HResult返回給調用

者。

WideString等一些有差異的類型

接口定義中缺省的字符參數或返回值將不再是String而是WideString。WideString 是Delphi中符合OLE 32-bit版本的Unicode類型，當是字符

時，WideString與String幾乎等同，當處理Unicode字符時，則會有很大差別。聯想到COM本身是為了跨平臺使用，可以很容易的理解為什么數

據通信時需要使用WideString類型。

同樣的道理，integer類型將變成SYSINT或者Int64、SmallInt或者Shortint，這些細微的變化都是為了符合規范。

通過向導生成基礎代碼

打開創建新工程向導（菜單“File-New-Other”或“New Items按鈕”），選擇ActiveX頁。先建立一個ActiveX Library。編譯后即是個DLL文

件（進程內）。然后在同樣的頁面再建立一個COM Object。

實例模式與線程模式

接著你將看到如下向導，除了填寫類名外（接口名會自動根據類名填充），還有實例創建方式（Instancing）和線程模式（Threading Model）

的選項。

實例模式決定客戶端請求后，COM對象如何創建實例：

Internal：供COM對象內部使用，不會響應客戶端請求，只能通過COM對象內部的其他

方法來建立；

Single Instance：不論當前系統內部是否存在相同COM對象，都會建立一個新的程序

及獨立的對象實例；

Mulitple Instance：如果有多個相同的COM對象，只會建立一個程序，多個COM對象

的實例共享公共代碼，并擁有自己的數據空間。

Single/ Mulitple Instance有各自的優點，Mulitple雖然節省了內存但更加費時。即Single模式需要更多的內存資源，而Mulitple模式需要更

多的CPU資源，且Single的實例響應請求的負荷較為平均。該參數應根據服務器的實際需求來考慮。

線程模式有五種：

Single：僅單線程，處理簡單，吞吐量最低；

Apartment：COM程序多線程，COM對象處理請求單線程；

Free：一個COM對象的多個實例可以同時運行。吞吐量提高的同時，也要求對COM對象

進行必要的保護，以避免多個實例沖突；

Both：同時支持Aartment和Free兩種線程模式。

Neutral：只能在COM+下使用。

雖然Free和Both的效率得到提高，但是要求較高的技巧以避免沖突（這是很不容易調試的），所以一般建議使用Delphi的缺省方式。

類型庫編輯器（Type Library）

假設我們建立一個叫做TSample的類和ISample的接口（如圖），然后使用類型庫編輯器創建一個方法GetCOMInfo（在右邊樹部分點擊右鍵彈出

菜單選擇New-Method或者點擊上方按鈕），并于左邊Parameters頁面建立兩個參數（ValInt : Integer , ValStr : String），返回值為BSTR

。如圖：

可以看到，除了常用類型外，參數和返回值還可以支持很多指針、OLE對象、接口類型。建立普通的COM對象，其Returen Type是可以任意的，

這是和DCOM的一個區別。

雙擊Modifier列彈出窗口，可以選擇參數的方式：in、out分別對應const、out定義，選擇Has Default Value可設置參數缺省值。

Delphi生成代碼詳解

點擊刷新按鈕刷新后，上面類型庫編輯器對應的Delphi自動生成的代碼如下：

unit uCOM;

{$WARN SYMBOL_PLATFORM OFF}

interface

uses

Windows, ActiveX, Classes, ComObj, pCOM_TLB, StdVcl;

type

TSample = class(TTypedComObject, ISample)

protected

??? function GetCOMInfo(ValInt: SYSINT; const ValStr: WideString): WideString;

????? stdcall;

end;

implementation

uses ComServ;

function TSample.GetCOMInfo(ValInt: SYSINT;const ValStr: WideString): WideString;

begin

end;

initialization

TTypedComObjectFactory.Create(ComServer, TSample, Class_Sample,

??? ciMultiInstance, tmApartment);

end.

引用單元

有三個特殊的單元被引用：ComObj，ComServ和pCOM_TLB。ComObj里定義了COM接口類的父類TTypedComObject和類工廠類

TTypedComObjectFactory（分別從TComObject和TComObjectFactory繼承，早期版本如Delphi4建立的COM，就直接從TcomObject繼承和使用

TComObjectFactory了）； ComServ單元里面定義了全局變量ComServer: TComServer，它是從TComServerObject繼承的，關于這個變量的作用

，后面將會提到。

這幾個類都是delphi實現COM對象的比較基礎的類，TComObject（COM對象類）和TComObjectFactory（COM對象類工廠類）本身就是IUnknown的

兩個實現類，包含了一個COM對象的建立、查詢、登記、注冊等方面的代碼。TComServerObject則用來注冊一個COM對象的服務信息。

接口定義說明

再看接口類定義TSample = class(TTypedComObject, ISample)。到這里，已經可以通過涉及的父類的作用大致猜測到TSample是如何創建并注

冊為一個標準的COM對象的了。那么接口ISample又是怎么來的呢？pCOM_TLB單元是系統自動建立的，其名稱加上了_TLB，它里面包含了ISample

= interface(IUnknown)的接口定義。前面提到過，所有COM接口都是從IUnknown繼承的。

在這個單元里我們還可以看到三種ID（類型庫ID、IID及COM注冊所必須的CLSID）的定義：LIBID_pCOM，IID_ISample和CLASS_Sample。關鍵是

這時接口本身僅僅只有定義代碼而沒有任何的實現代碼，那接口創建又是在何處執行的？_TLB單元里還有這樣的代碼：

CoSample = class

class function Create: ISample;

class function CreateRemote(const MachineName: string): ISample;

end;

class function CoSample.Create: ISample;

begin

Result := CreateComObject(CLASS_Sample) as ISample;

end;

class function CoSample.CreateRemote(const MachineName: string): ISample;

begin

Result := CreateRemoteComObject(MachineName, CLASS_Sample) as ISample;

end;

由Delphi的向導和類型編輯器幫助生成的接口定義代碼，都會綁定一個“Co+類名”的類，它實現了創建接口實例的代碼。CreateComObject和

CreateRemoteComObject函數在ComObj單元定義，它們就是使用CLSID創建COM/DCOM對象的函數！

初始化：注冊COM對象的類工廠

類工廠負責接口類的統一管理——實際上是由支持IClassFactory接口的對象來管理的。類工廠類的繼承關系如下：

IClassFactory = interface(IUnknown)

TComObjectFactory=class(TObject,IUnknown,IClassFactory,IClassFactory2) TTypedComObjectFactory = class(TComObjectFactory)

我們知道了接口ISample是怎樣被創建的，接口實現類TSample又是如何被定義為COM對象的實現類。現在解釋它是怎么被注冊，以及何時創建的

。這一切的小把戲都在最后initialization的部分，這里有一條類工廠建立的語句。

Initialization是Delphi用于初始化的特殊部分，此部分的代碼將在整個程序啟動的時候首先執行。回顧前面的內容并觀察一下

TTypedComObjectFactory的參數：ComServer是用于注冊/撤消注冊COM服務的對象，TSample是接口實現類，Class_Sample是接口唯一對應的

GUID，ciMultiInstance是實例模式，tmApartment是線程模式。一個COM對象應該具備的特征和要素都包含在了里面！

那么COM對象的管理又是怎么實現的呢？在ComObj單元里面可以見到一條定義function ComClassManager: TComClassManager;

這里TComClassManager顧名思義就是COM對象的管理類。任何一個祖先類為TComObjectFactory的對象被建立時，其Create里面會執行這樣一句

：

ComClassManager.AddObjectFactory(Self);

AddObjectFactory方法的原形為procedure TComClassManager.AddObjectFactory(Factory: TComObjectFactory);相對應的還有

RemoveObjectFactory方法。具體的代碼我就不貼出來了，相信大家已經猜測到了它的作用——將當前對象（self）加入到ComClassManager管

理的對象鏈（FFactoryList）中。

封裝的秘密

讀者應該還有最后一個疑問：假如服務器通過類工廠的注冊以及GUID確定一個COM對象，那當客戶端調用的時候，服務器是如何啟動包含COM對

象的程序的呢？

當你建立ActiveX Library的工程的時候，將發現一個和普通DLL模版不同的地方——它定義了四個輸出例程：

exports

DllGetClassObject,

DllCanUnloadNow,

DllRegisterServer,

DllUnregisterServer;

這四個例程并不是我們編寫的，它們都在ComServ單元例實現。單元還定義了類TComServer，并且在初始化部分創建了類的實例，即前面提到過

的全局變量ComServer。

例程DllGetClassObject通過CLSID得到支持IClassFactory接口的對象；例程DllCanUnloadNow判斷DLL是否可從內存卸載；DllRegisterServer

和DllUnregisterServer負責DLL的注冊和解除注冊，其具體的功能由ComServer實現。

接口類的具體實現

好了，現在自動生成代碼的來龍去脈已經解釋清楚了，下一步就是由我們來添加接口方法的實現代碼。在function TSample.GetCOMInfo的部分

添加如下代碼。我寫的例子很簡單，僅僅是根據傳遞的參數組織一條字符串并返回。以此證明接口正確調用并執行了該代碼：

function TSample.GetCOMInfo(ValInt: SYSINT;const ValStr: WideString): WideString;

const

Server1 = 1; Server2 = 2; Server3 = 3;

var

s : string;

begin

s := ''''This is COM server : '''';

case ValInt of

??? Server1: s := s + ''''Server1'''';

??? Server2: s := s + ''''Server2'''';

??? Server3: s := s + ''''Server3'''';

end;

s := s + #13 + #10 + ''''Execute client is '''' + ValStr;

Result := s;

end;

注冊、創建COM對象及調用接口

隨便建立一個Application用于測試上面的COM。必要的代碼很少，創建一個接口的實例然后執行它的方法。當然我們得先行注冊COM，否則調用

根據CLSID找不接口的話，將報告“無法向注冊表寫入項”。如果接口定義不一致，則會報告“Interface not supported”。

編譯上面的這個COM工程，然后選擇菜單“Run – Register ActiveX Server”，或者通過Windows下system/system32目錄中的regsvr32.exe程

序注冊編譯好的DLL文件。regsvr32的具體參數可以通過regsvr32/？來獲得。對于進程外（EXE型）的COM對象，執行一次應用程序就注冊了。

提示DLL注冊成功后，就應該可以正確執行下列客戶端程序了：

uses ComObj, pCOM_TLB;

procedure Ttest.Button1Click(Sender: TObject);

var

COMSvr : ISample;

retStr : string;

begin

COMSvr := CreateComObject(CLASS_Sample) as ISample;

if COMSvr <> nil then begin

??? retStr := COMSvr.GetCOMInfo(2,''''client 2'''');

??? showmessage(retStr);

??? COMSvr := nil;

end

else showmessage(''''接口創建不成功'''');

end;

最終值是從當前程序外的一個“接口”返回的，我們甚至可以不知道這個接口的實現！第一次接觸COM的人，成功執行此程序并彈出對話框后，

也許會體會到一種技術如斯奇妙的感覺，因為你僅僅調用了“接口”，就可以完成你猜測中的東西。

創建一個分布式DCOM（自動化接口）

IDispatch

在delphi6之前的版本中，所有接口的祖先都是IUnknown，后來為了避免跨平臺操作中接口概念的模糊，又引入了IInterface接口。

使用向導生成DCOM的步驟和COM幾乎一致。而生成的代碼僅將接口類的父類換為TAutoObject，類工廠類換為TAutoObjectFactory。這其實沒有

太大的不同，因為TAutoObject等于是一個標準COM外加IDispatch接口，而TAutoObjectFactory是從TTypedComObjectFactory直接繼承的：

TAutoObject = class(TTypedComObject, IDispatch)

TAutoObjectFactory = class(TTypedComObjectFactory)

自動化服務器支持雙重接口，而且必須實現IDispatch。因討論范疇限制，本文只能簡單提出，IDispatch是DCOM和COM技術實現上的一個重要區

別。打開_TLB.pas單元，可以找到Ixxx = interface(IDispatch)和Ixxx = dispinterface的定義，這在前面COM的例子里面是沒有的。

創建過程中的差異

使用類型庫編輯器的時候，有兩處和COM不同的地方。首先Return Type必須選擇HRESULT，否則會提示錯誤，這是為了滿足雙重接口的需要。當

Return Type選擇HRESULT后，你會發現方法定義將變成procedure（過程）而不是預想中的function（函數）。

怎么才能讓方法有返回值呢？還需要在Parameters最后多添加一個參數，然后將該參數改名與方法名一致，設置參數類型為指針（如果找不到

某種類型的指針類型，可以直接在類型后面加*，如圖，BSTR*是BSTR的指針類型）。最后在Modifier列設置Parameter Flags為RetVal，同時

Out將被自動選中，而In將被取消。

刷新后，得到下列代碼。添加方法的具體實現，大功告成：

TSampleAuto = class(TAutoObject, ISampleAuto)

protected

??? function GetAutoSerInfo(ValInt: SYSINT;const ValStr: WideString): WideString; safecall;

end;

遠程接口調用

遠程接口的調用需要使用CreateRemoteComObject函數，其它如接口的聲明等等與COM接口調用相同。CreateRemoteComObject函數比

CreateComObject 多了一個參數，即服務器的計算機名稱，這樣就比COM多出了遠程調用的查詢能力。前面“接口定義說明”一節的代碼可以對

照CreateComObject、CreateRemoteComObject的區別。

自定義COM的對象

接口一個重要的好處是：發布一個接口，可以不斷更新其功能而不用升級客戶端。因為不論應用升級還是業務改變，客戶端的調用方式都是一

致的。

既然我們已經弄清楚Delphi是怎樣實現一個接口的，那能否不使用向導，自己定義接口呢？這樣做可以用一個接口繼承出不同的接口實現類，

來完成不同的功能。同時也方便了小組開發、客戶端開發、進程內/外同步編譯以及調試。

接口單元：xxx_TLB.pas

前面略講了接口的定義需要注意的方面。接口除了沒有實例化外，它與普通類還有以下區別：接口中不能定義字段，所有屬性的讀寫必須由方

法實現；接口沒有構造和析構函數，所有成員都是public；接口內的方法不能定義為virtual，dynamic，abstract，override。

首先我們要建立一個接口。前面講過接口的定義只存在于一個地方，即xxx_TLB.pas單元里面。使用類型庫編輯器可以產生這樣一個單元。還是

在新建項目的ActiveX頁，選擇最后一個圖標（Type Library）打開類型庫編輯器，按F12鍵就可以看到TLB文件（保存為.tlb）了。沒有定義任

何接口的時候，TLB文件里除了一大段注釋外只定義了LIBID（類型庫的GUID）。假如關閉了類型庫編輯器也沒有關系，可以隨時通過菜單View

– Type Library打開它。

先建立一個新接口（使用向導的話這步已經自動完成了），然后如前面操作一樣建立方法、屬性…生成的TLB文件內容與向導生成_TLB單元大致

相同，但僅有定義，缺乏“co+類名”之類的接口創建代碼。

再觀察代碼，將發現接口是從IDispatch繼承的，必須將這里的IDispatch改為IUnknown。保存將會得到.tlb文件，而我們想要的是一個單元

（.pas）文件，僅僅為了聲明接口，所以把代碼拷貝復制并保存到一個新的Unit。

自定義CLSID

從注冊和調用部分可以看出CLSID的重要作用。CLSID是一個GUID（全局唯一接口表示符），用來標識對象。GUID是一個16個字節長的128位二進

制數據。Delphi聲明一個GUID常量的語法是：

Class_XXXXX : TGUID = ''''{xxxxxxxx-xxxxx-xxxxx-xxxxx-xxxxxxxx}'''';

在Delphi的編輯界面按Ctrl+Shift+G鍵可以自動生成等號后的數據串。GUID的聲明并不一定在_TLB單元里面，任何地方都可以聲明并引用它。

接口類聲明與實現

新建一個ActiveX Library工程，加入剛才定義的TLB單元，再新建一個Unit。我的TLB單元取名為MyDef_TLB.pas，定義了一個接口

IMyInterface = interface(IUnknown)，以及一個方法function SampleMethod(val: Smallint): SYSINT; safecall;現在讓我們看看全部接口

類聲明及實現的代碼：

unit uMyDefCOM;

interface

uses

ComObj, Comserv, ActiveX, MyDef_TLB;

const

Class_MySvr : TGUID = ''''{1C0E5D5A-B824-44A4-AF6C-478363581D43}'''';

type

TMyIClass = class(TComObject, IMyInterface)

??? procedure Initialize; override;

??? destructor Destroy; override;

private

??? FInitVal : word;

public

??? function SampleMethod(val: Smallint): SYSINT; safecall;

end;

TMySvrFactory = class(TComObjectFactory)

??? procedure UpdateRegistry(Register:Boolean);override;

end;

implementation

{ TMyIClass }

procedure TMyIClass.Initialize;

begin

inherited;

FInitVal := 100;

end;

destructor TMyIClass.Destroy;

begin

inherited;

end;

function TMyIClass.SampleMethod(val: Smallint): SYSINT;

begin

Result := val + FInitVal;

end;

{ TMySvrFactory }

procedure TMySvrFactory.UpdateRegistry(Register: Boolean);

begin

inherited;

if Register then begin

??? CreateRegKey(''''MyApp\''''+ClassName, ''''GUID'''', GUIDToString(Class_MySvr));

end else begin

??? DeleteRegKey(''''MyApp\''''+ClassName);

end;

end;

initialization

TMySvrFactory.Create(ComServer, TMyIClass, Class_MySvr,

????? ''''MySvr'''', '''''''', ciMultiInstance, tmApartment);

end.

Class_MySvr是自定義的CLSID，TMyIClass是接口實現類，TMySvrFactory是類工廠類。

COM對象的初始化

procedure Initialize是接口的初始化過程，而不是常見的Create方法。當客戶端創建接口后，將首先執行里面的代碼，與Create的作用一樣

。一個COM對象的生存周期內，難免需要初始化類成員或者設置變量的初值，所以經常需要重載這個過程。

相對應的，destructor Destroy則和類的標準析構過程一樣，作用也相同。

類工廠注冊

在代碼的最后部分，假如使用TComObjectFactory來注冊，就和前面所講的完全一樣了。我在這里刻意用類TMySvrFactory繼承了一次，并且重

載了UpdateRegistry 方法，以便向注冊表中寫入額外的內容。這是種小技巧，希望大家根據本文的思路，摸清COM/DCOM對象的Delphi實現結構

后，可以舉一反三。畢竟隨心所欲的控制COM對象，能提供的功能遠不如此。

（本文所有代碼在Delphi6、Delphi7下編譯執行通過）

全文完。

轉載于:https://www.cnblogs.com/Handll/archive/2009/09/24/1573642.html

總結

以上是生活随笔為你收集整理的Delphi下的COM编程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。