The very first thing that needs to clear is that all control project and ocx names have been initialized to something different than the original names. The reason for this, if not obvious, is that if you made some changes to the source code and re-compiled the source using the same names (i.e. ciaXPButton40.ocx), then we would have a conflict anywhere you distributed your control where the original control may also reside.

Let's examine the following scenario:

A developer with a licensed copy of XPSuite 4.0 creates an application, call it app1, using the retail version (cia* controls), and sells their app to a customer. When the customer installs app1, the original controls will be installed, and whenever app1 runs, it will use the installed controls. Now you decide to modify the XPButton and change the way it works, or delete some functions, etc., and create your application, call it app2. And you happen to sell it to the same customer. So the customer performs a normal install, and since your version and\or date is newer, your install package overwrites the original controls, required by app1, with your controls, required for app2. Now we have a situation where only app1 or app2 will function, depending on how the customer removes and installs the app's.

The way to ensure this never happens is to never distribute modified controls which have an existing name. To make sure any modifications you make do not cause a conflict with our XPSuite products, we have initialized all names of importance with "xxx" at the beginning of the name, removing the "cia" letters. So for example, what use to be ciaXPButton40, is now xxxXPButton40.

Now we can't stop here, and start compiling some new controls! Nope, sorry to say, you will have to create your own name, and replace the "xxx", or even the whole name. The reason for this, is that other developers who have purchased the source code, are doing the same thing as you, and therefore if everyone releases the same name, we are no better off than we were when they were named "cia". The good news is that we will show exactly what has to be changed in order to quickly rename a control to your very own.

Time to jump hip deep into the nitty-gritty of how to get from point A to point B, and get you ready to distribute your own controls. For purposes of this discussion, let's assume we are working on the XPButton40 control. Looking at the folder layout for this control we find the following:

All control's folder begin with their type (i.e. "CIA XP Button"). The first sub folder for all controls is called "OCX Source". This folder contains all the source code required for the particular control, and the latest release of of active-x control (i.e. xxxXPButton40.ocx ). Looking at the list of file types, you'll find the Visual Basic Project file or *.vbp. For our example, the file would be "xxxXPButton40.vbp". This is the file that is started to open the control's project, loading all source files. Associated with the project file, is the project workspace file which is automatically created and updated by Visual Basic. Three other files comprise the active-x control, and have the following extensions; "*.exp, *.lib, and *.ocx. The first two files are the object files while the *.ocx is the actual file you distribute. However, as a developer, you need to treat all three of these files as one, as you will see in the following paragraphs.

A sub folder under the "OCX Source" folder called "Original OCX ", contains the three control files which Visual Basic compares to for binary compatibility whenever you compile the control. Later in this discussion, we will talk about the use of these files.

Step 1 - Removing the Initial Active-X Files

As we stated earlier, the source code package is shipped to you with all controls initialized with a "xxx" at the beginning of the name for various files, specific to the control. In addition, we have compiled both binary compatible and release active-x controls to show you how the final control structure will look after you have made your changes.

Whether this is your first name change, or one down the road, the following steps should always be taken whenever you are changing the name of the control. For cases where you are simply updating or changing the source code, but maintaining the control's name, and therefore are maintaining binary compatibility, the steps taken will be discussed later.

The first thing we need to do, in general, is make Windows think the old control has never existed. This is a critical series of step s, so please do it properly and in the order specified. Before getting started, you will need a good registry cleaner, one that really digs deep into the registry for such things as missing custom controls, and especially unused typelibs! We have found, and have had great success with "Registry Mechanic", by PC Tools Software, www.pctools.com. This product does a fantastic job in cleaning the registry without disturbing or making working programs unusable.

The first step is to delete all references of the active-x control and it's object files, in both the "OCX Source" and "Original OCX" folders. In addition, look for any dependency files which will have a file type called "Control Typelib Cache" and delete these as well. These files created automatically whenever you first use your control, say during testing in a test project. Typically you will always find this file under the "OCX Source" folder. Naturally after deleting the files, they will be placed in the Recycle Bin. And believe it or not you will have to make sure you remove these files or empty the bin before you run the registry cleaner!

The next and final step you'll need to accomplish prior to running the registry cleaner is to zip up the entire "CIA XP Button" folder, then delete the entire contents of the official folder. In this step, we must remove anything associated with the control, as the registry cleaner checks paths and associations before it will remove or clean the registry item.

Now run the registry cleaner, and you will notice several entries from the registry determined to be no longer valid. These are usually typelibs.

After running the registry cleaner, unzip the source files back to their original location. Now you have a system with all source code files, and a registry which has no references to the control.

Step 3 - Renaming the Files

As part of the renaming process for the controls, please consider you have two options to do it. First, you can open the project, and change all names within the properties tab. Secondly, you can manually open certain files in Note Pad, and change the text. We have found Visual Basic to be very "quirky", to put it nicely, when trying option 1, changing the project name within VB. We have found, thru years of experience dealing with VB and active-x controls, that the second option, although slower and more tedious, is the safest and only guaranteed method for success. In source files, change the name of visual project, and visual basic workspace files to the desired name. In our example we will change them to "abcXPButton40".

Step 4 - Start it Up!

At this point, your project is ready for an initial start up using the new name. Open the VB project (*.vbp). More than likely you will receive an error message that the project could not locate the binary compatible file (which is because we deleted it). This is ok, and what we want, since we are in effect starting over. VB will automatically set the Binary Compatibility type to No Binary Compatibility.

Any further errors received during the project loading must however be fixed. If you receive any errors, continue thru the load process so that VB can generate a log file detailing the error. After the project has loaded, and all errors have been received, shutdown the project, without saving!.

Open the log files, determine the cause, and correct the issues directly from Note Pad. Continue this process until you can open the project without any errors. This may seem tedious, but after you have done it a few times, it will become second nature, and soon the projects will load without errors every time.

Step 5 - Start it Up!, and Let's go Coding

Make all your desired changes to the project. Remember, since we are starting from scratch, we do not need to worry about compatibility issues. Add a new project (standard exe project) to the solution to test your new control.

Step 6 - Build Your New Active X Control!

Now that you have made your changes and everything functions properly in the test project, it's time to compile your control and set your control for Binary Compatibility use.

On the initial creation of your new control, we will be compiling the control twice; once for the binary compatibility file, and second the final release. Go to the File menu, and click Make *ocx as shown below.

At some point in time, you will want or need to modify your control. Modifications can be tricky, with respect to maintaining Binary Compatibility. In general, problems can arise if you try any of the following:

• Deleting a Public Interface, such as a Public Property, Public Sub or Function, Public Enums, Public Structures, etc.
• Changing any parameters within a Public Property, Public Sub or Function, Public Enums, Public Structures, etc.
  

However, changes to the code within property, sub, or function whether Private or Public will not cause any adverse effects.

If while making your changes, you do create a situation where the resultant re-compile would break Binary Compatibility, VB will let you know by displaying a dialog page detailing where the break is, and whether you want to continue. If you answer yes, then VB will set the Version Compatibility to No Compatibility, and you will have to rename your control and go thru above process again, to ensure the new control- does not conflict with any controls are already distributed.

For purposes of this discussion, let's assume you make minor changes which will not break compatibility. Before you can re-compile your changes, you must first set your computer up, namely the Windows registry, so that the re-compile is successful, and to ensure VB does not use any erroneous references. The process for this is very similar to the steps above for creating a new control, except we will not be deleting or renaming any file contents.

The next and final step you'll need to accomplish prior to running the registry cleaner is to zip up the entire "CIA XP Button" folder, then delete the entire contents of the official folder. In this step, we must remove anything associated with the control, as the registry cleaner checks paths and associations before it will remove or clean the registry item.

Now run the registry cleaner, and you will notice several entries from the registry determined to be no longer valid. These are usually typelibs.

After running the registry cleaner, unzip the source files back to their original location. Now you have a system with all source code files, and a registry which has no references to the control.

Step 3 - Build Your Active X Control with the Modifications!

Now that you have made your changes and everything functions properly in the test project, it's time to compile your control. Since we already have created the Binary Compatibility ocx files, we will only be required to re-compile the release version located in the OCX Source folder.