[VB6] Tutorial: Using OCX Files with SxS Technology-VBForums
Results 1 to 18 of 18

Thread: [VB6] Tutorial: Using OCX Files with SxS Technology

Threaded View

  1. #1

    Thread Starter
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    3,040

    [VB6] Tutorial: Using OCX Files with SxS Technology

    A Tutorial for Using OCX Files with SxS Technology in VB6

    Contents




    Introduction & Scope

    This is a somewhat esoteric/advanced topic for VB6. If you’re willing to distribute your VB6 compiled applications with an installer, and you’re not concerned about using whatever version of an OCX file is found in the C:\Windows\System32 (or C:\Windows\SysWOW64 if you’re installing on a 64 bit system) folder when you execute your compiled program on a user’s computer, then you don’t need to concern yourself with any of this.

    SxS is short for Side-by-Side. There’s a Wikipedia page that describes it in detail.

    If I were starting a new project, I’d take a serious look at Krool’s work found here and here. I’d tend to just include the source in whatever project I was developing, and be completely done with OCX files (not using them at all). However, this is not necessarily a practical solution for existing projects that are well developed, for which you may wish to make portable, or just have more control over your OCX files.

    In this tutorial, we shall be discussing how to specify exactly which OCX files your application is using. Furthermore, we will only be discussing how to use these OCX files once your application is compiled into an executable (EXE file). We will not be discussing how to manifest the actual VB6 IDE. In other words, when you’re developing (on your development computer), you will still most likely be using whatever OCX files are found in your C:\Windows\System32 (or C:\Windows\SysWOW64 for 64 bit) folder when in the VB6 IDE. If you intend to use different versions of OCX files for IDE development than you intend to use for manifesting your executable, it is contingent upon you to do appropriate testing to make sure there are no functional differences in these different OCX files. The easiest thing to do is to have the same set of OCX files registered on your development machine that you intend to use for SxS manifest distribution and execution.

    As a note, it’s my understanding that you can also reference ActiveX DLLs with the SxS technology. However, under Advanced Topics, I discuss an alternative way to reference ActiveX DLLs which I consider to be cleaner (and easier to maintain) than the SxS approach. Therefore, using ActiveX DLL files with the SxS technology will not be part of this tutorial.


    Assumptions

    The Command Prompt (aka, Command Window): It will be assumed that you know how to get around in a Command (CMD) prompt window. Just briefly, you can call up a Command prompt by typing in “CMD” (no quotes) in either your Windows Run box or your Windows Search box. Once the Command window is open, you can use the CD (chdir, change directory) command to navigate around in your computer’s file system. And, from any Command window prompt, you can execute any command (executable) that is either on the environment’s path or in the folder you are in. (Alternatively, you could specify the path of the command (on the same line) before you specify the actual command.) Most commands also have arguments that you can type in on the same command line. Hopefully, all of this is already core knowledge for you.

    Where are the OCX files located: I’m going to write this tutorial for both 32 bit versions of Windows as well as 64 bit Windows versions. The primary difference between the two is the location of your registered OCX files. If everything is as it should be, and you’re on a 32 bit version of Windows, all of your registered OCX files should be in the C:\Windows\System32 folder. If you’re on a 64 bit version of Windows, these OCX files should be in the C:\Windows\SysWOW64 folder. However, if you’ve been “playing around” with these OCX files, the registered version can “in theory” be anywhere on your system. For the purposes of this tutorial, it will be assumed that they are in the “correct” folder as stated.


    Justification

    There are a few different reasons you may want to consider using the SxS technology:

    1. You maintain strict control over which OCX files your application is using when you use the SxS technology. In other words, your application doesn’t dig through C:\Windows\System32 (or C:\Windows\SysWOW64) to find these OCX files. Rather, it goes directly where you direct your program to go to find these files. This assures that you know what functionality your OCX files will have. In the Windows world of shared DLL files (and OCX files are just a special type of DLL files), programs installed subsequent to yours may replace and “update” the OCX files that you installed. Furthermore, during your installation, if an OCX file found in C:\Windows\System32 (or C:\Windows\SysWOW64) has a later version stamp than the one you are distributing, it will not be replaced (unless you have an installer that doesn’t follow accepted protocols). That’s all part of installation protocol. However, problems arise when OCX files of later versions don’t operate precisely as you want. This is specifically known as DLL hell. This has become such a problem that even major portions of the Windows OS (from Vista forward) use this SxS technology.

    2. The VB6 core runtime files have been installed as part of the Windows OS since Windows 2000, and continue to be a part of the Windows OS through Windows 10. In other words, a simple VB6 compiled program is completely portable (no installation required; it’ll just directly execute). However, once we include OCX files (via IDE_Menu/Project/Components…), this is no longer true. However, by using the SxS technology with our OCX files, we can again achieve portability for even the most complex VB6 programs.

    3. If you embrace the SxS technology when using OCX files, you will have gone a long way toward staying completely away from your user’s computer’s registry. This is essentially another aspect of being portable. I’m sure many of us have somewhat negative feelings about the Windows’ registry, so this will be a plus for many.
    Last edited by Elroy; Sep 18th, 2017 at 01:08 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width

Survey posted by VBForums.