MFC ActiveX Controls: Distributing ActiveX Controls
The new home for Visual Studio documentation is Visual Studio 2017 Documentation on docs.microsoft.com.
The latest version of this topic can be found at MFC ActiveX Controls: Distributing ActiveX Controls.
This article discusses several issues related to redistributing ActiveX controls:
ANSI or Unicode Control Versions
Installing ActiveX Controls and Redistributable DLLs
Registering Controls
Note
For additional information on redistributing ActiveX controls, see Redistributing Controls.
ANSI or Unicode Control Versions
You must decide whether to ship an ANSI or Unicode version of the control, or both. This decision is based on portability factors inherent in ANSI and Unicode character sets.
ANSI controls, which work on all Win32 operating systems, allow for maximum portability between the various Win32 operating systems. Unicode controls work on only Windows NT (version 3.51 or later), but not on Windows 95 or Windows 98. If portability is your primary concern, ship ANSI controls. If your controls will run only on Windows NT, you can ship Unicode controls. You could also choose to ship both and have your application install the version most appropriate for the user's operating system.
Installing ActiveX Controls and Redistributable DLLs
The setup program you provide with your ActiveX controls should create a special subdirectory of the Windows directory and install the controls' .OCX files in it.
Note
Use the Windows GetWindowsDirectory API in your setup program to obtain the name of the Windows directory. You may want to derive the subdirectory name from the name of your company or product.
The setup program must install the necessary redistributable DLL files in the Windows system directory. If any of the DLLs are already present on the user's machine, the setup program should compare their versions with the versions you are installing. Reinstall a file only if its version number is higher than the file already installed.
Because ActiveX controls can be used only in OLE container applications, there is no need to distribute the full set of OLE DLLs with your controls. You can assume that the containing application (or the operating system itself) has the standard OLE DLLs installed.
Registering Controls
Before a control can be used, appropriate entries must be created for it in the Windows registration database. Some ActiveX control containers provide a menu item for users to register new controls, but this feature may not be available in all containers. Therefore, you may want your setup program to register the controls when they are installed.
If you prefer, you can write your setup program to register the control directly instead.
Use the LoadLibrary Windows API to load the control DLL. Next, use GetProcAddress to obtain the address of the "DllRegisterServer" function. Finally, call the DllRegisterServer function. The following code sample demonstrates one possible method, where hLib stores the handle of the control library, and lpDllEntryPoint stores the address of the "DllRegisterServer" function.
HINSTANCE hLib = LoadLibrary(pszDllName);
if (hLib < (HINSTANCE)HINSTANCE_ERROR)
{
AfxMessageBox(IDS_LOADLIBFAILED); //unable to load DLL
iReturn = FAIL_LOAD; //unable to load DLL
}
// Find the entry point.
lpDllEntryPoint = GetProcAddress(hLib, "DllRegisterServer");
if (lpDllEntryPoint != NULL)
(*lpDllEntryPoint)();
else
;// Unable to locate entry point
The advantage of registering the control directly is that you do not need to invoke and load a separate process (namely, REGSVR32), reducing installation time. In addition, because registration is an internal process, the setup program can handle errors and unforeseen situations better than an external process can.
Note
Before your setup program installs an ActiveX control, it should call OleInitialize. When your setup program is finished, call OleUnitialize. This ensures that the OLE system DLLs are in the proper state for registering an ActiveX control.
You should register MFCx0.DLL.