VBCOM TUTORIAL(3)

In Visual Basic, building a COM-compatible object is deceptively easy:  given the class definition for this object, you simply add the class to a particular type of VB project, make the project, and you''''re done.  That''''s it, end of tutorial!  In reality of course, there''''s more to VB COM than just doing make.

First, let''''s define some standard COM terminology.  A coclass refers to a COM class, i.e. a class that is compatible with COM.  What makes VB so powerful is that all classes created in VB are COM-compatible.  It will be helpful if you also think of a coclass as denoting a concrete class, a class that contains functionality / code.  A COM component is synonymous with coclass.

A COM server is one or more coclasses compiled into a single, distributable file.  COM servers typically have the file extension .dll or .exe.   A COM server must be registered on a client''''s machine before that client can instantiate any of the coclasses in the server. 

There are two types of COM servers, in-process and out-of-process.   If a client instantiates a coclass from an in-process COM server, the resulting object lives in the same address space (and process) as the client.   However, if a client instantiates a coclass from an out-of-process COM server, the resulting object will live and run in a separate process --- on the same machine (local) or a different machine (remote).  To build an in-process COM server in VB, you create an ActiveX DLL project, add one or more class modules, and perform make; the result is a file with the extension .dll.   To build an out-of-process COM server, use an ActiveX EXE project type; make will then yield a file with the extension .exe.

The extension DLL stands for Dynamic Link Library, implying that an in-process COM server is linked into the client upon the first instantiation of any of its coclasses.   Note that the entire COM server is linked in, not just the coclasses being instantiated.  For example, suppose a COM server has 3 coclasses, and a client instantiates coclass1 and coclass2.  Here''''s the resulting situation in memory on that machine:

Now suppose the user, on this same machine, starts up another process called Client #2 that instantiates coclass3.  Conceptually, the situation in memory is now:

In essence, each process gets its own copy of COM Server.  Why is this important?   Because if COM Server contains "global" variables, it is important to note that these variables are not shared by the different client processes. 

As we all know, the extension EXE stands for executable program.  Thus, out-of-process COM servers are completely separate processes, running asynchronously until a client makes a method call into one of the server''''s objects (at which point the client object blocks until the server object returns from the method call).  For example, suppose we have an out-of-process COM server with 3 coclasses, and a client object on the same machine instantiates coclass2.  The situation in memory is:

What if multiple clients instantiate coclasses from the same COM server?  Typically, each instantiation yields a different object within the same server process:

However, whether these server objects run concurrently --- i.e. whether method calls from different clients execute at the same time --- depends on how the COM server is configured; we''''ll save this topic for later, when we discuss COM activation.

Note that the configuration of the COM server controls other things as well.  In particular, whether or not:  (1) the different server objects in the above picture can share "global" variables, and (2) instantiation yields multiple objects in the same server (as shown above) or an entirely new server process each time (thus # of processes = # of server objects).

Time for a lab exercise!  The goal is to take an existing application, remove one of its classes, turn that class into a COM component, and produce a new, COM-based application.  First we''''ll build an ActiveX DLL COM server, then repeat the exercise by building an ActiveX EXE COM server.  The application simulates a long-running operation, displaying a progress indicator as it proceeds.  Here''''s a picture of the app, which you can see this for yourself by running \VBCOM\Labs\COM Servers\App.exe  (if you have not already done so, you can download the labs from the Setup page):

It is the progress indicator, defined by the class CProgress in \VBCOM\Labs\COM Servers\App.vbp, that will become a COM component.

1. Startup VB, and create a new ActiveX DLL project.  VB will define an initial class module called Class1.  Select this class, and remove it from the project (Project >> Remove); when prompted, do not save changes.
2. Now add the existing class module file "CProgress.cls" to the project:  Project >> Add Class Module, Existing tab, navigate to \VBCOM\Labs\COM Servers\CProgress.cls, and open.  Likewise, add the existing form "frmProgress.frm" to the project. 
3. Take a moment and review the code in CProgress.   For help understanding this code, jump here.
4. View the project explorer (View >> Project Explorer), expand the Class Modules, and select CProgress.  View the properties window (F4), and change the Instancing property from Private to MultiUse.  This makes the COM coclass publicly accessible to clients. 
5. Modify the project''''s properties (a very important step when building a COM server) via Project >> Properties.  Under the General tab, set the name to "ProgressDLL" and the description to "_Progress Indicator In-Process Server (VBCOM)".  Click OK.
6. Finally, make your COM server via File >> Make, into the same directory as the other files.  Save your work, and exit VB.

Congratulations, you have just built your first COM server!  Your COM server resides in the file "ProgressDLL.dll" that you made; if you cannot see this file in your lab directory, make sure your explorer window is set to display hidden files.   Now, to test your work, let''''s build a client application. 

7. Startup VB, and create a new Standard EXE project.  Remove the initial form module Form1, and add the existing form \VBCOM\Labs\COM Servers\frmMain.frm.
8. Modify the project''''s properties:  set the startup object to be frmMain, and the name to "Client".  Click OK.
9. View the form, in particular the code behind the cmdProgress command button.  The sub creates an instance of CProgress, shows progress in increments of 10, and then destroys the instance: 

10. Now run the application (F5).  Depending on how VB is configured on your machine, you will either get an immediate compiler error ("User-defined type not defined", with CProgress highlighted), or the app will startup and show the main form.  In the latter case, clicking the button will then yield the same error message:  "User-defined type not defined". 
11. The problem is that our new client application is unable to locate the class CProgress.  Whenever you want to use a COM component, you must first reference it so that VB can find it.  Thus, view the list of registered COM components on your machine (Project >> References), and select the progress indicator component we built earlier --- i.e. check the item "_Progress Indicator In-Process Server (VBCOM)".  Click OK.
12. Now re-run the application.  It should work perfectly, merrily showing progress in increments of 10!
13. Finally, make an executable "Client.exe", save your work, and exit VB.

You should be able to run "Client.exe" outside of VB, and it should run identically to "App.exe".  However, the former uses COM, and the later does not.  If you want to run multiple clients and view multiple progress indicators on the screen, you will need to add a call to  DoEvents inside the client''''s For-Next loop, and perhaps pause a bit longer as well. 

[1] [2]  下一页

Copyright ＠ 2007-2012 敏韬网(敏而好学，文韬武略--MinTao.Net)（学习笔记） Inc All Rights Reserved.
闵涛 E_mail:admin@mintao.net(欢迎提供学习资源)

鄂公网安备 42011102001154号

站长：MinTao ICP备案号：鄂ICP备11006601号-18