A few years back I was project testing a large and complex VB6 project which employed hundreds of ActiveX DLLs and OCXs.
I learned there is a right way and a wrong way to do things when developing COM objects.
Every COM object has a certain number of Publicly exposed member functions which take a fixed number of arguments. If you make changes to the existing interface, it will in effect, change that object's signature (interface). This is called breaking compatibility.
Note: adding new public members to the interface will not break compatibility.
When this happens, you have 2 entries in your registry. The old object (with the old signature) and the new object. Repeat this procedure and you will wind up with hunderds of dangling entries in your registry which can lead to problems and bloat up your registry (bad).
So when we are working with a COM object we are smart and set up our IDE to be Binary Compatible, so that as long as our interface does not change, we will keep using the same registry entry. So what happens when we must break Compatibility?
Follow these steps to keep your registry clean as a whistle. Ideally, there should be one and only one entry for any given COM object.
1) Create a new project and develop an ActiveX OCX or DLL.
2) Compile the binary.
3) The IDE does this for you, but we can do it anyway. Register the Binary (regsvr32 Path\FileName)
4) Go to Project...Settings...Component and choose Binary Compatibility - using the previously compiled binary as a reference.
5) Recompile the binary.
6) Oops! After further testing you see you have to change an existing Public Function, or add an argument to an existing function.
7) You are ready to Break Compatibility.
8) You must now UnRegister the old binary. (regsvr32 -u Path\FileName)
9) Delete the old binary from disk (one could back it up somewhere safe) 10) Resume at step (2) above with the COM object's new signature.
So what happens when we are working with an ActiveX EXE? No problem! We simply replace step (8) with a command-line execution (Path\exeName /unregserver)
Steps (3) and (8) can be made much easier if you set things up a little smarter. We can automate the Registry/UnRegistry of an object type using Windows Explorer.
1) 2x click the OCX file on disk, bringing up Window's "File Association" applet
2) Instead of choosing a program, we have to Browse for it
3) Browse to C:\Windows\System32 and choose the file REGSVR32.EXE
4) Now we can 2x click any OCX file and Register it. How do we get it to UnRegister? Continue on...
5) Open up your favorite registry editor (I use regedit) go to Start...Run and enter REGEDIT
6) Go to the root hive and go to Edit...Find
7) Type in regsvr32
8) It should take you to HKEY_CLASSES_ROOT\Applications\regsvr32.exe
9) Open up the [+] symbol. The tree expands out to Shell...Open...Command 10) Copy the Default String under the command key item to the clipboard
11) Create a new Key under the shell key and call it UnRegister
12) Under the new Unregister key, create another key called command
13) Paste the clipboard contents into the default string, and make it look like this: "C:\WINDOWS\system32\regsvr32.exe" "-u" "%1"
The above should also be applied to DLLs.
Well, your done! Now you can use Windows explorer to Register and Unregister DLLs & OCXs with a couple mouse clicks! Try it: Right click on any DLL or OCX and you can painlessly Register and UnRegister them from the context menu.
You will notice I put my binaries in C:\Program Files\Common Files. This is a great place to put your binary ActiveX components. Even better - you could make your own folder matching youR Project Name, and put your binaries in there.
Well, follow the above guidelines and you will be practicing COM & DCOM Clean Living!
Last edited by Dave Sell; Dec 1st, 2004 at 12:35 AM.
Sorry for my reaction, but you should NEVER EVER break compatiblity, if you must change the interface, the only way to go is to create an second Interface for youre COM object which will house the changed public members.
And the old routine could be redirected to the new one if needed.
This is done because if old applications where distrobuted with the old COM object and this old COM object could be updated to the new one, the old app doesnt crash because it still expects the old interfaces and it's members.
Rule of thumb number 2 :
NEVER EVER Change publicly released Interfaces, this is an very bad habit, and could cause old app's to crash.
That's why, there are com objects which have numberd interface, like 1,2,3 etc etc.
I was referring to your early develpoment stage, where you are "feeling" your way aroud a new project. In this stage I tend to reshape my COM's interfaces regularly.
I would consider that to be Alpha phase.
You are absolutely correct, once you've settled on an interface, then you can go Beta. In Beta phase, you are allowed to break compatibility 1 time, only in an extreme circumstance.
However, once you are out of Beta and into full-fledged distribution of your COM objects, then you never-ever-ever break compatibility!
Last edited by Dave Sell; Sep 25th, 2004 at 12:54 PM.
10 easy steps to COM & DCOM Clean Living
Reply With Quote
