At this point, it is very important to observe the following: no special programming was required to use COM with VB!  The only differences from the original "App.exe" were configuration-oriented --- the use of a different project type in the server and setting a project reference in the client.  On the surface, COM programming in VB is that easy.

For completeness, let''''s build the progress indicator into an out-of-process COM server.   Once again, the only changes will be the use of a different project type for the server, and a different project reference in the client:

14. Repeat steps 1 .. 6 above, except create an ActiveX EXE project, set the project name "ProgressEXE" and the description to "_Progress Indicator Out-of-Process Server (VBCOM)".  After you make your project, you should end up with a COM server in the file "ProgressEXE.exe".
15. Reopen the "Client.vbp" project, and under project references uncheck the in-process COM server and check your new "_Progress Indicator Out-of-Process Server (VBCOM)".  Now run your client (F5), and it should function as before!
16. To convince yourself that the COM server actually runs as a separate executable, insert a Stop statement in the client immediately after the instantiation of CProgress:

Now run the client from inside VB, and click the command button to execute the above code.  VB should enter break mode with the Stop statement highlighted.  Bring up the Task Manager on your computer, and you will see that ProgressEXE is running!  Switch back to VB, continue execution, and let the client run (i.e. let the processing of cmdProgress''''s Click event run to completion).  Return back to the Task Manager, and observe that ProgressEXE is no longer running.  Why not?  Because the client no longer has a reference to a CProgress object, and when the last object in a VB COM server is destroyed the server is stopped.

17. If you want to play...  To keep the COM server running, we need to keep at least one object alive in the server.  This means we need to keep the object''''s reference count > 0.  One way to do this in our clients is to keep object references in global variables, which never go out of scope.  In the client app, first move the declaration of the progress variable from the Click event to the Declarations section (top) of the main form.  Then, instead of instantiating CProgress in the Click event, now do this in the form''''s Load event.  Finally, move the "Set progress = Nothing " statement from the Click event to the form''''s Unload event.  Now when you run the client, the COM server will be started as well, and this same process will continue to run until the client terminates.  Confirm this behavior using the Task Manager.

That''''s enough lab work for now, good job!

As mentioned in the introduction, a COM server must be registered before a client can instantiate any of the coclasses in that server.  However, in the above lab the client app (e.g. "Client.exe") ran just fine without any kind of explicit "registration" step.  How can this be?  Who registered the progress indicator COM server?  And what does it mean for a COM component to be registered?

In short, registering a COM server means updating the Windows registry database on that computer.  The registry enables COM to locate coclasses in response to client instantiation requests.  To ease component development, VB automatically registers --- on your development machine --- any COM server you make (i.e. File >> Make).  Thus, each time you do make, VB unregisters the previous version (if any) and registers the new version. 

As evidence, let''''s break the "Client.exe" application by simply unregistering the COM server on which it depends.  First, in preparation, locate the file \VBCOM\Misc\regsvr.reg and double-click to execute; this file adds some entries to your registry database that makes server registration and unregistration easier.  Next, run your "Client.exe" in the lab directory \VBCOM\Labs\COM Servers\ and convince yourself that it shows progress without error.  Now right-click on the file "ProgressDLL.dll" --- the in-process progress indicator COM server --- and select "Unregister COM Server" from the pop-up menu.  Finally, re-run "Client.exe" and click the command button to show progress:  this should yield "Run-time error 429:  ActiveX component can''''t create object."   In other words, the requested COM server is not registered on this machine.  [ Note: if you did not receive an error, perhaps your client is instantiating the out-of-process version of the progress indicator.  Unregister "ProgressEXE.exe" and try again. ]  To fix the application, simply re-register the COM server by right-clicking on the appropriate file.  

How can you find out what COM servers are registered on your machine?  One way is to view project references.  Startup VB, select Project >> References, and you should see something similar to:

This list is produced by VB using information culled from the machine''''s registry database; recall we used this dialog in the lab to configure the client. 

COM servers can also be registered via the command-line.  To register / unregister an in-process COM server, use the REGSVR32 utility:

In the case of out-of-process COM servers, run the server itself:

These approaches make it easy to automate the registration process, in particular during application installation on a client machine.  This task is typically performed by the install program itself.

For now, we can safely ignore the registration problem since VB will automatically register COM servers for us.  However, you need to keep this in mind when it comes time for deployment.  We will revisit this issue in more detail when we present COM activation.

When developing a COM component, you are faced with an immediate decision:  create an in-process server, or an out-of-process server?  The short answer is that in-process COM servers offer better performance while out-of-process COM servers offer greater flexibility.  The former are more efficient since the server objects live in the same address space as the client, enabling a much cheaper communication mechanism (a simple subroutine call).  The latter are more flexible since they can be deployed remotely on server machines, without having to recompile any of the code. 

At first glance, it would appear that multi-tier applications are best designed using out-of-process COM servers.  However, it is becoming quite common to develop in-process COM servers and then deploy these components using surrogate processes.  A surrogate process acts as a host for an in-process COM server, allowing it to run in an address space separate from the client --- just like an out-of-process COM server.  However, the advantage is that the surrogate can provide services to its server objects, such as support for sharing state (i.e. "global variables").   The most important example of a surrogate process is Microsoft Transaction Server (MTS), which among other things provides support for distributed transactions.  Thus, if you want to build COM components that work with MTS, you must create in-process COM servers.

What''''s next?  A discussion of client-side COM programming. 

上一页  [1] [2]