COM and the Registry
Mention "ok, let's run regedit now and go take a look at the Registry" to developers and visions of angry network admins dance through their heads. [The operative word here is "look", not "willy-nilly modify configurations so that the machine will not run again no matter how many stale doughnuts you sacrifice to it".] Some view the system registry as the monster in the basement - it's there and we acknowledge that it's there, but that doesn't mean we want to go down there and play. [I know this from experience: my grandmother's house had/has a monster in the basement.1 Whenever Grandma sent me downstairs to fetch a can of creamed corn or some such item I would carefully descend the stairs, creep into the pantry, frantically grab the can and wildly dash back up the stairs, monster snapping at my heels....]
At any rate, the information kept in the Registry is at the heart of COM. In the beginning there were .ini files. They worked okay but had/have some limitations:
- .ini file information usually only available to the application that put it there
- text file format allows "casual manipulation by potentially naive end users" (how's that for polite??) - no way to secure files
- .ini files do not support multiple users or multiple versions of same application
- .ini file data restricted to text strings - no binary storage allowed
Windows 3.1 introduced the Registration Database for applications that used OLE (what they used to call COM). Eventually, Windows NT and Windows 9x were released with full-fledged Registries that are the central repository for all configuration information dealing with all hardware and software. The Registry is accessed in a consistent manner, is able to hold binary as well as string data and support multiple users and versions of software. It's securable and can be administered over a network. If it gets corrupted (it's a database and that's why you have to shut down as opposed to flipping the power switch - databases get corrupted if you don't close them properly), you're in trouble, but that's why we keep backups.... To access the Registry, we use the Run command, "regedit" (yes, NT/2000 has another editor but we won't worry about that one right now.) Let's try using regedit right now:
The Registry is structured as a tree with keys and subkeys. The key we're interested in is the topmost one, HKEY_CLASSES_ROOT (actually an alias for HKEY_LOCAL_MACHINE/Software/Classes). Expanding this key shows a bunch of subkeys, including file extensions, and if you scroll down a bit, Programmatic ID entries - ProgIDs - yes, these are what goes into the string argument for CreateObject and GetObject. These are the warm and fuzzy way to refer to your components: ProjectName.ClassName. Because the human imagination is limited, it's possible for duplication in ProgIDs. That's why there's another way of referring to components (in fact, if you do ActiveX control coding on HTML pages, it should look familiar...).
Let's go to the one that says Access.Application.10 (yours might say .8 or .9 - I'm using Office XP) and click the CLSID folder. Off to the right we see a long code. This is the Class ID, or GUID (Globally Unique Identifier) - think of it as a Social Security number for components. (Again, your CLSID may be different depending on your version of Office.)
So, thinking like your computer (I know, that could be a very scary thing...), when a request comes in for
Dim x As Access.Application.10
Set x = CreateObject("Access.Application.10")your computer saunters into the Registry and says, hey, I need one of these Access.Application.10 thingees. The Object Manager (think of this like the guy who works at the police evidence counter) says, sure, let me get you one of those. The OM looks up Access.Application.10 and sees that its Class ID is {73A4C9C1-D68D-11D0-98BF-00A0C90DC8D9}. cool. OK, but how is that information useful to anybody or anything? Let's see what we can find that matches this code. First, the OM copies the code to the clipboard by double-clicking the value.
Now, the OM knows that all Class IDs are kept in a special subkey called, wittily enough, CLSID. (This is found alphabetically near the "C" ProgIDs.) He scrolls down and clicks that folder, and then brings up the Find dialog.
Deep within the CLSID subkey lurks the code:
Because Access.Application.10 is an out-of-process server (ActiveX exe), the OM knows to look under the LocalServer32 subkey to find...(drum roll please...)
...the path to the executable that opens MS Access!
So, there we have it: how the ProgID leads to the executable that actually runs the desired component. This is why components have to be "registered" - the Registry contains the path to the executable. If you move a program, the Registry needs to know about it.
One more thing - you may have wondered about the .10 (or .9 or .8) appended to Access.Application. Perhaps you've always used just Access.Application. The .10 is the specific version. If you don't use the specific version, it's okay, there is a subkey called Access.Application and it has a current version subkey which points to... .10 (or the last installed version of Access). You save a little bit of time by specifying the version you want to start with.
1The monster in the basement tale is a bit changed from the standard Registry mini-lecture - Grandma's basement DOES have a monster, too :-) (Actually, don't all basements have monsters?...)
Alrak's Course Resources ©2002-2007 Karla Carter. All rights reserved. This material (including, but not limited to, Mini-lectures and Challenge Labs) may not be reproduced, displayed, modified or distributed without the express prior written permission of the copyright holder. For permission, contact Karla.