Highlighted
Absent Member.
Absent Member.
253 views

[archive] The process of determining if a control is installed

[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.
0 Likes
2 Replies
Highlighted
Absent Member.
Absent Member.

RE: [archive] The process of determining if a control is installed

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?
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] The process of determining if a control is installed

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.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.