One way or another, the Sieve client program is going to need all the information it can get about its Sieve components. The client needs the settings and the information from Figure 10-5.
How can the server share the information and how can the client find it? Part of the information is shared through the system registry. Figure 10-5 shows all the data in the registry related to the SieveBasExeN program. This is the god’s-eye view; you can’t really see all these entries at one time in the Registry Editor.
If you haven’t used the Registry Editor, you’d better load it up and follow along. I find the Windows 95 version (REGEDIT.EXE) to be more user-friendly than the Windows NT version (REGEDT32.EXE), and it works under Windows NT.
Figure 10-5. An ActiveX component in the system Registery.
If you have access to both operating systems, try copying REGEDIT.EXE to your Windows NT system directory. The Windows NT version has one advantage: it monitors and automatically updates registry entries made from the outside. With the Windows 95 version you have to use the Refresh command to get recently changed values.
If you check all the cross-links in Figure 10-5, you’ll start to get an idea of what’s going on. Some of the registry entries are named, and some are GUIDs. Named entries have GUID subentries, and GUID entries contain data such as the title and location of the server. If, at run time, Visual Basic knows only the name of the component it needs to use, it goes to the registry and looks up the name. Visual Basic retrieves the GUID item and then looks up the GUID entry. It uses data under the GUID to load the correct DLL or EXE server. This is what happens when you call CreateObject to connect to a public class. If you load a type library, Visual Basic already knows the GUID. It can skip the name lookup and go directly to the data from the GUID. Furthermore, it can read the COM data it needs out of the registry at design time rather than at run time.
There’s a lot more to this process than I care to get into here. COM has functions that take care of the details of registering servers, handling class IDs, and looking up data in the registry. Visual Basic has functions that take care of calling those COM functions. You simply fill in dialog boxes, declare objects, and call properties and methods. In theory, you should never have to worry about registering and unregistering components and type libraries, but if you ever deal with beta software, you should get used to the idea of sometimes examining or removing COM registry entries by hand.
In theory, you could even register components by hand by adding all the appropriate registry entries yourself in the Registry Editor. No thanks. It’s not out of the question, however, to write Visual Basic code that automatically handles examination, modification, and cleanup of COM registry items. But you need to understand normal registration before you try to mess with it.