[Migrated content. Thread originally posted on 17 February 2005]
For the following, unless otherwise stated, an object goes for both COM and
ActiveX.
The very first thing you have to consider when you are about to deploy a control
is the following:
1. Is there an enduser license.
o Check with the vendor.
o Make sure the LICENSE-KEY phrase is filled in with this.
o For the Microsoft Common Controls included on the CD, the end user
license is automatically checked out by the runtime, thus
you do not have to think about license for these controls.
2. File dependency.
o What files are required (if any) to execute the control.
This is something the vendor of the control should be
able to tell you. Don't accept that you have to ship their
entire developers installation. Normally this includes
tons of stuff your endusers won't care about.
o If external files are required, what versions of these does
it have to be?
o Does the dependant have a dependency? If your control is made with
any version of the Visual studio, it may depend on the
presence of the Microsoft Visual C Runtime library, or the
Microsoft foundation classes of a particular version.
Normally you won't have to think about this, as the COBOL
virtual machine already depends on these and provide them.
Have a note of it though, as your component *may* rely on
a different version and may behave odd if there is something
here.
o Note that for the Microsoft Common Controls shipped on the 6.2.0
CD, you will find text files describing their dependency
in the folder with the controls itself. Thus, you do not have
to do inquiries.
3, When to install component and additional files.
o With the introduction of support for ActiveX and COM, the declaratives
section were enhanced to also cover object exceptions, or cases
where an ActiveX or COM object either would not display or
died during execution. We can trap this kind of events in the
OBJECT EXCEPTION part of the declaratives. You should do this
to make sure that you can control the full execution of the
control, and if not for anything else, be able to make a
graceful death of your application.
o With the OBJECT EXCEPTION section in place, you can use the standard
verb DISPLAY or CREATE (COM) to determine if the control you
are about to use is already installed. If you have an
OBJECT EXCEPTION section and create an object that is not
installed, you will be thrown into the declaratives, and using
the library function C$EXCEPTIONINFO you will be able to
determine the cause of the failure, among those for instance
that the component were not installed. Look at the attachment
ExcepDemo.cbl for an illustration of this.
o If it is determined that the control is not installed, you should
copy the files onto the disk. I recommend you copy them into
your application directory (where you have wrun32.exe), this
to avoid interfering with other software and also to ensure the
possibility of an easy cleanup and uninstall.
o If your control is not installed, you can accomplish this from within
your COBOL application provided that your control has the
extension .DLL. If it has the extension .OCX, you may rename it
to .DLL in advance, it will work all the same.
Do load the control then as a DLL like: CALL "MyControll.dll".
Remember ON EXCEPTION of course.
Once loaded, all controls has at least two functions:
DllRegisterServer
DllUnregisterServer
These are parameterless. If your control has not been registered
yet, you register it by doing this:
CALL "mycontrol.dll".
CALL "DllRegisterServer".
Alternatively, you can CALL "SYSTEM" and use the utility
RegSvr32.exe:
CALL "SYSTEM" USING
"RegSvr32 mycontrol.dll".
This is the theory. Next up is a full example.
Very useful, thank you Gisle. This is even better information than what is in ACUCOBOL-GT User's Guide Version 6.2 section
6.10.9 Distributing Applications Containing ActiveX Controls. Is it possible this could be added or worked into that section in future user's guide?
[Migrated content. Thread originally posted on 17 February 2005]
For the following, unless otherwise stated, an object goes for both COM and
ActiveX.
The very first thing you have to consider when you are about to deploy a control
is the following:
1. Is there an enduser license.
o Check with the vendor.
o Make sure the LICENSE-KEY phrase is filled in with this.
o For the Microsoft Common Controls included on the CD, the end user
license is automatically checked out by the runtime, thus
you do not have to think about license for these controls.
2. File dependency.
o What files are required (if any) to execute the control.
This is something the vendor of the control should be
able to tell you. Don't accept that you have to ship their
entire developers installation. Normally this includes
tons of stuff your endusers won't care about.
o If external files are required, what versions of these does
it have to be?
o Does the dependant have a dependency? If your control is made with
any version of the Visual studio, it may depend on the
presence of the Microsoft Visual C Runtime library, or the
Microsoft foundation classes of a particular version.
Normally you won't have to think about this, as the COBOL
virtual machine already depends on these and provide them.
Have a note of it though, as your component *may* rely on
a different version and may behave odd if there is something
here.
o Note that for the Microsoft Common Controls shipped on the 6.2.0
CD, you will find text files describing their dependency
in the folder with the controls itself. Thus, you do not have
to do inquiries.
3, When to install component and additional files.
o With the introduction of support for ActiveX and COM, the declaratives
section were enhanced to also cover object exceptions, or cases
where an ActiveX or COM object either would not display or
died during execution. We can trap this kind of events in the
OBJECT EXCEPTION part of the declaratives. You should do this
to make sure that you can control the full execution of the
control, and if not for anything else, be able to make a
graceful death of your application.
o With the OBJECT EXCEPTION section in place, you can use the standard
verb DISPLAY or CREATE (COM) to determine if the control you
are about to use is already installed. If you have an
OBJECT EXCEPTION section and create an object that is not
installed, you will be thrown into the declaratives, and using
the library function C$EXCEPTIONINFO you will be able to
determine the cause of the failure, among those for instance
that the component were not installed. Look at the attachment
ExcepDemo.cbl for an illustration of this.
o If it is determined that the control is not installed, you should
copy the files onto the disk. I recommend you copy them into
your application directory (where you have wrun32.exe), this
to avoid interfering with other software and also to ensure the
possibility of an easy cleanup and uninstall.
o If your control is not installed, you can accomplish this from within
your COBOL application provided that your control has the
extension .DLL. If it has the extension .OCX, you may rename it
to .DLL in advance, it will work all the same.
Do load the control then as a DLL like: CALL "MyControll.dll".
Remember ON EXCEPTION of course.
Once loaded, all controls has at least two functions:
DllRegisterServer
DllUnregisterServer
These are parameterless. If your control has not been registered
yet, you register it by doing this:
CALL "mycontrol.dll".
CALL "DllRegisterServer".
Alternatively, you can CALL "SYSTEM" and use the utility
RegSvr32.exe:
CALL "SYSTEM" USING
"RegSvr32 mycontrol.dll".
This is the theory. Next up is a full example.
We are continously improving our documentation, it might be that there will be more extensive information about distribution of ActiveX controls.
However, as stated in my post, it is very much dependent on the vendor of the control, what you have to do.
These Microsoft Common Controls are provided for free distribution with the ACUCOBOL-GT runtime as a an extra service, it is not, and likely will not, be a strategic area for Acucorp, Inc. to develop ActiveX controls in general. Thus, I think it is a bit on the side of what we do.
This information thus is a niche and I am uncertain whether it should belong in our mainstream documentation. Remember they are not a product from us.
It is more likely it will remain available in dedicated forums, trainings and articles like this.
