Codejock ActiveX components are standalone .OCX files that must be copied and registered on the target computer where they will be used. One component (.OCX) file exposes a set of classes and interfaces necessary for using controls it provides. The controls can be used from any development environment and with any programming language that supports ActiveX technology.
The way to work with ActiveX components and related language dependent concerns are beyond this article as it is unique to each programming language. It is assumed that a developer is familiar with ActiveX concepts and best practices related to a programming language of his choice.
This article explains the following related concerns:
Each Codejock ActiveX component comes in 3 configurations:
Component file names reflect its configuration, e.g.:
It is important to choose the correct configuration that is compatible with your host application as Windows does not allow mixing the bitness of modules in one address space old programming languages do not support Unicode character set.
The possible installation options are:
Components may be installed to any location that is at least read-only accessible for all potential users of the installed components.
It is not enough to just copy component files to the target location to be able to use it, they must be registered and license included (described in the next section). Even after installing either SuitePro or a standalone ActiveX component on a development machine the necessary configurations must be registered prior to using the components.
Component registration on the development machine can be done using the Registrator tool included in the installation package. Typically it can be found at the following location: %ProgramFiles(x86)%\Codejock Software\ActiveX\Xtreme SuitePro ActiveX v18.0.1\Bin\Registrator.exe
If a component is distributed along with the application every .OCX module must be registered during application installation. Typically this can be achieved by using %SystemRoot%\System32\regsvr32.exe tool executed as Administrator, for example using this command line for silent Calendar registration:
regsvr32.exe /s Codejock.Calendar.v18.0.1.OCX
or this command line for unregistering Calendar component silently:
regsvr32.exe /s /u Codejock.Calendar.v18.0.1.OCX
It is important to understand that a target machine where components should be registered may already have Codejock components of the same version registered. While there is no harm to re-register components of the same version, but in case an application that uses Codejock components gets uninstalled, unregistering components may break other applications that depend on those components. There are 2 ways to work around this issue:
If necessary to review Codejock component registration manually the standard OLE View tool from Windows SDK can be used:
Every ActiveX component has a set of unique class, interface and type library IDs associated with it registered to the system. In order to avoid version collisions all Codejock components have their IDs regenerated with each new version.
While this ensures that 2 or more installations of the same component but different versions can co-exist in the same system independently, it makes component upgrade process on a development machine a bit more complicated than just installing a newer version. Depending on the development environment and programming languages this situation can be resolved in different ways and with different side-effects.
For example, Visual Basic 6 IDE during project loading can determine that a referenced component have a newer version available and prompt to upgrade existing components automatically. Unfortunately Microsoft Office is not as flexible as Visual Basic 6 IDE when it comes to ActiveX component upgrade, it does not prompt to upgrade automatically, instead it just uses the current component version or does not instantiate a control at all if its registration does not exist, even if a newer version is available. In such a case the only way to upgrade controls is removing old controls and insert new ones with re-storing previous properties.
All Codejock ActiveX components require to have a valid license in order to function. ActiveX license should not be confused with paid subscription, it is just a small text file .LIC , one per .OCX file that has to be distributed along with .OCX file, it does not imply any additional fee.
There are two ways of including license when you distribute Codejock components along with your application:
This is a preferable and the easiest way of distributing the license. All is needed is just to copy .LIC file for each .OCX component into the same location. Using this method guarantees that the license will be picked up by the component if exists. Unlike embedding a license into an application, no cross-module issues are possible.
For example, you install Codejock Calendar ActiveX components for both 32- and 64-bit platforms as part of your application to %ProgramFiles(x86)%\<YourCompanyName>\<YourApplicationName>\bin directory, then bin directory should contain the following files:
Should you want to include CommandBars components, you also need to copy Codejock.CommandBars.v18.0.1.LIC to the same location.
There are cases when distributing a separate .LIC file is not possible, e.g. when you develop an ActiveX component for a web-browser or any other sort of a remote client. In this case the only option is to embed the license text into the application.
In a cross-module scenario this method should be used with extreme caution and is prone to unexpected behavior as different environments manage such scenarios in different ways. For example, if you develop a Visual Basic application that does not use the Report control, but instead it uses another custom control that does use the Report control, the license for the Report control must be set from the hosting application, not from the custom control. In such cases it is recommended to distribute license as a separate .LIC file.
The way it works, each component exposes its own
GlobalSettings class which has the string
License property. This property must be set to the verbatim value of the first 3 string of the corresponding .LIC file up to the first empty line, including all spaces and new lines. It is important to use CRLF as a new line separator (
0Ah byte sequence, or
"\r\n" escape sequence) as it is used in .LIC file.
The property must be assigned as early as possible in the application initialization flow. For Visual Basic it can be the beginning of
Form_Initialize, for .NET applications it can be the beginning of the main window constructor. It is important to assign this property before any other explicit or implicit call to the component is made.
Here is an example of how to do it:
In some cases when a project that references Codejock ActiveX components is opened on a computer other than it was created on, or a project was created with an older version of Visual Studio, or if only a newer version of components is available, form initialization flow may fail at the end with COM exception. There can be various reasons, the most common one is that Interop assemblies created for Codejock ActiveX component by another Visual Studio instance do not match available components. The steps below may help with resolving this issue:
OcxStatefor a property named as