Image of Navigational Panel mapped to Contents / Home / Search VB 4.0 / Jet Runtime
Tech Support Question

Image of Line Break

Q. My company markets an application which involves a group of VB 3.0 runtime EXEs, which utilize a Microsoft Access 2.0 database using JET Engine. The package runs on a mobile laptop, and users dial into a host application (non-VB) on a regular basis to download new data to update their databases.

In addition to the data files, the software will also sometimes download EXE files to upgrade their software (users are generally on the road on a continual basis, and therefore cannot acquire new update disks from a home base; this system allows us to ensure that remote users are always using the latest version of the software).

Recently, we have developed a need for developing a few EXEs in VB 4.0 (16-Bit), due to its new database manipulation features (modifying integrity constraints, improved Repair Database method, etc.). I understand that in order for a machine that has never run a VB 4.0 application before to run such an application, several new DLLs, OCXs, and the like are required in the /windows/system path.

Our upgrade program can take care of downloading these additional files and moving them to the /windows/system directory, but apparently this is not enough. I used the VB 4.0 Application Setup Wizard to generate a list of DLLs, OCXs, etc., which my application will need to run properly, but even after the upgrade program has moved all of these files into the /windows/system directory, the VB4.0 programs don't work (I get an 'Object Required' error message).

If, after running this process, I then run the Setup program generated by the VB 4.0 Application Setup Wizard, everything works great. However, for various reasons we are not in favor of using the VB 4.0 Application Setup Wizard to perform the upgrade process for us.

Obviously, the Setup Wizard is doing something that our upgrade program isn't. Any ideas?

A. It sounds like your problem here is that not all the OLE objects you are installing are registering. The easiest way to register everything depends on your installation software.

If you are using WISE by Great Lakes Business Solutions (which is my personal favourite - very choice), it is a simple matter of checking a checkbox in a dialog. This tells it that the file it is installing is a self-registering DLL/OCX.

Otherwise, the easiest option is to call the LoadLibrary API call. The act of bringing each self-registering DLL or OCX into memory will trigger its SelfRegister function, and you should end up with the correct OLE registrations.

In the case of VB4 we have observed that you need to register _every_ JET DLL you ship as well as each OCX. This may be a real pain dependent upon your Install software, but in general, load them all into memory and let them take care of themselves.

If you do use WISE you should be aware that there is a patch available for users of Version 4, that will upgrade you to 4.0g (www.glbs.com). It includes some additional smarts about shipping VB4 apps.

Good Luck.

Reply from Recipient:

Thank you very much for your helpful reply. Since I wrote to you with my question, I have managed to solve my problem through use of the DLLSelfRegister API included with STKIT416.DLL, which I believe comes with VB4 (I learned how to do this by reviewing the source code for VB4's supplied application setup project, \vb\setupkit\setup1\sequp1.vbp).

With my fairly limited knowledge of VB and the concept of DLLs I was able to register all of the appropriate DLLs/OCXs and successfully set up my application as a stand-alone EXE.


Image of Arrow to Previous Article Image of Arrow to Next Article

[TECH SUPPORT TOC]
Image of Line Break
[HOME] [TABLE OF CONTENTS] [SEARCH]