I wanted to share some software with a friend, but when I give him the exe file, he gets a missing ocx file error. I do use some third party ocx files in the software. Is there an option to include these ocx files for distribution in the exe?
That includes a link to our Application Deployment FAQ, which includes links for downloads and documentation for various installers (including Package & Deployment Wizard, which comes with VB).
In many cases you can just supply the EXE and the OCX files and tell your friend to put everything in the same directory. I have done this many time over without any problems. People would go to my website and download the zip file that contained only the EXE and the OCX files and there was no problem.
In many cases you can just supply the EXE and the OCX files and tell your friend to put everything in the same directory. I have done this many time over without any problems. People would go to my website and download the zip file that contained only the EXE and the OCX files and there was no problem.
This is a Very Bad Idea.
The point of DLLs is that they are normally shared among applications. This is less true of a custom DLL/OCX created as part of a specific application, but even more true for standard components like the Winsock control which is widely used.
Putting a COM DLL or OCX next to a VB6 application risks having the program invoke the library's DLLRegisterServer entrypoint, which will register the library in place.
If you do this and subsequently the user installs another program that uses the same library everything will be fine until the first program is deleted or moved. The now-faulty registry entries are still there but the library can no longer be found. This leaves the second program broken (and possibly the first) as well as other programs the user subsequently tries to install.
Well, what can I say. I have downloaded many programs (EXE) with the OCX's and have not had any problems and like I said above have allowed many zip files with only the exe's and ocx's and again without any problems.
Maybe it is a bad idea; I didn't say it was or wasn't I just said what I said and I have never had anyone complain about it and furthermore complain about the application not working. In the case of the OP if all he wants to do is to give a copy to his friend then what the heck give him the exe and the ocx and if it works leave it at that. If it doesn't work then that's another issue.
That is marginally better, but even if you install to the correct location (which the user may not have permission for) it is still likely to be missing out part(s) of the process.
Not getting complaints is due to the problems appearing to be caused by other programs
You're making it sound as if some problem is caused by other programs where I said there was no problems.
OK, to make it short, yes it is not a good idea but then you need to tell that to the thousands of people who put their programs and ocx's in a zip file and then allow you to download them from many different sites. I personally have never had any problems whatsoever downloading any zip (exe and ocx's and dll's) file into a folder and running the application. For large scale applications and large scale distributions then no it shouldn't be done that way but for perhaps a one or two time only thing, bad or not bad, it will probably work.
Correct me if I am wrong here.
Let's say there is an OCX (or a DLL) in the system's directory of your friend and you want to send a copy of your application (which includes either an older or a newer version of the same file or at least with the same name) and you don't want to have your file overwrite the one already in his system's directory and you want to make sure your application uses the OCX/DLL that you supplied then putting that OCX/DLL in the same folder as the application will insure that it will be used instead of the one in the system's directory and you have not overwritten the original file. VB will first look in the application's folder before it looks in the system's directory.
Last edited by jmsrickland; Sep 25th, 2008 at 11:21 AM.
You didn't say there were no problems, you said that you haven't had any, and nobody has reported any to you.
In what you "quoted" (there are proper quote tags you know ) I was pointing out that the reason people wouldn't report problems is that they don't think the problems are caused by your program, as they appear when doing something with a different program (and thus they assume it is the other programs fault).
If you really want to do XCopy-style deployment there is an approved way to do it for Windows XP (especially SP2+) and later. It's the "isolated application with private assemblies" approach described in that MSDN article I linked above.
Sadly Microsoft never has and probably never will provide tools for doing this with VB6 programs, even though the technology was developed specifically with VB6 in mind.
Applies to:
Microsoft Windows Server 2003
Microsoft Windows XP Service Pack 2
Microsoft .NET Framework version 1.1
Microsoft Visual Studio .NET 2003
Microsoft Visual Basic 6.0
A few 3rd party tools exist to facilitate this with VB6 programs and components. The Mage and MageUI tools in more recent versions of the Windows SDK might be useful as well - be sure if you use Mage/MageUI you get versions contemporary with VS 2005 SP1 (older ones have fatal flaws).
None of the tools make the process a "no brainer" since you still have to understand what to deploy. Some common VB6 dependencies do not have DEP files for example, so neither the PDW nor an XCopy deployment packager will always be able to locate sub-dependencies. They may also pick non-deployable dependencies that you must manually skip.
Some other tools for XCopy-packaging VB6 programs include:
These can be used to create a set of files you can distribute as a ZIP archive or even a self-extracting archive.
Unlike using an installer technology they won't create Start Menu shortcuts, etc. or install into Program Files. They will let you package DLLs and OCXs alongside your programs without ever altering the registry though.
The resulting programs are "portable" in the sense you can move the application folder around or even onto a USB flash drive. The caveat is you cannot deploy the VB6 runtime components this way, which means you really should test your programs against the versions of the runtimes that come with XP SP2 and SP3 (XP SP3 has the same VB6 runtimes as Vista and Vista SP1). In some cases you may find that your programs will work fine even in XP and XP SP1 depending on the specific dependencies involved - OCXs tend to be more problematic than DLLs.
You didn't say there were no problems, you said that you haven't had any, and nobody has reported any to you.
In what you "quoted" (there are proper quote tags you know ) I was pointing out that the reason people wouldn't report problems is that they don't think the problems are caused by your program, as they appear when doing something with a different program (and thus they assume it is the other programs fault).
How do suppose a problem could/would occur with another program? No way since no other programs would use the OCX that was placed in the directory of the application for which it was intended. That the whole idea; to keep it isolated from the rest of the system. The only way other programs would have problems would be if they loaded that same OCX and that would be the fault of the user because he was suppose to keep it in only one directory and not let it get into the main stream of the system files or other directories.
Putting the application and it's associated files in one directory insures that nothing else in the system can be affected by it. The risk comes in when the associated files are placed in the system's directory, not in the application's directory. Besides, you are supoosed to stay out of the system's directories.
Any way, I was just stating that you could do it that way; not to argue good, bad, or whatever
Last edited by jmsrickland; Sep 25th, 2008 at 12:42 PM.
I think Microsoft would have disabled this auto-registration long ago... if it wouldn't break so many VB applications. I don't know how far it goes back, maybe even to VB4 32bit programs but probably at least to VB5 programs.
One of the hazards of classic VB development is getting by with no support from the vendor. So even as things that seemed like a good idea at the time are found to be less so later on... it is up to us to deal with them on our own.
Most people probably don't even realize they aren't supposed to be using regsvr32 runs as part of installing an application. Some of the reasons are described in the Windows Installer documentation at SelfReg Table. This is why the PDW, Inno Setup, and the like aren't the best packaging tools to use. They only know how to use component library self registration.
Of course that doesn't stop us from using them, and you can do the very same "wrong" thing in an Installer MSI too. Installation/setup is quite a minefield.
Well if I had written a program which required a third party DLL or OCX or even if I made the DLL or OCX and I was just going to give a copy to my friend I would just give him the exe and the ocx. The heck with wrapping it up in a distribution package. My first post was made based on that pretense. Now on the other hand if it was going to be widley distributed it then I would give second thought. I am quite amazed however that most of the applications I download (and I mean commercial stuff) are all nicely placed in their own directories with all the DLLs and OCX's in there too. I do not see these same files in my system directory. I agree with post #7 but for just what the OP wanted I just simply stated that you could do it that way and save yourself the trouble for that one time only occurance. Is it a bad idea? Based on post #7, yes, based on giving your friend a copy and it's a one time only thing then who cares.
[RESOLVED] Icluding OCX files in VB6 executable
Reply With Quote
Originally Posted by jmsrickland
) I was pointing out that the reason people wouldn't report problems is that they don't think the problems are caused by your program, as they appear when doing something with a different program (and thus they assume it is the other programs fault).
2009 - 2016