| Title: | Microsoft Visual Basic |
| Moderator: | TAMARA::DFEDOR::fedor |
| Created: | Thu May 02 1991 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2565 |
| Total number of notes: | 10453 |
OK folks, today is the day for brain melters! Apart from the SETUP.EXE problem that I have in 2545.* I now have another user who has another strange problem. Bearing in mind that the software has been successfully installed literally hundreds of times and is working correctly on hundreds of PC's .... (and these problems have to happen on PC's that might as well be on the other side of the world. I will never get to see them ...) The latest problem comes after a completely successful installation (no errors reported, installation kit created by VB wizard - in case this is important to any of you readers out there). The user fires up the application, and after some of the screens have been loaded, and some of the initialisation has been done, the following error is displayed: Error 429: You do not have an appropriate licence to use this functionality. Tracing the problem, it appears that the error occurs on a line Load frmMyForm A message-box displayed just prior to this line is displayed successfully, but a message-box displayed on the first line of the Form_Load routine of the form is not displayed. This error is simply trapped by my error handler. 429 is held in Err, and Error$ holds the text. This is an error generated by VB at runtime. I am not doing anything special here. Looking at the error list for VB, 429 seems to be "OLE Automation server cannot create object", and not what is being reported. I may be barking up entirely the wrong OCX here, but the problem seems to appear as soon as I go anywhere near a form that has a Grid (GRID32.OCX) on it. I have checked in SWDEPEND.INI and the only thing stated as being required is OCX Runtime Support. I assume that the necessaries have been done with whatever that equates to a) Because the kit was created with the wizard (okay, dangerous assumption I know), and b) hundreds of installations have been done on machines with all sorts of configurations and they are up and running fine. I have really had enough of today .... Steve
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2546.1 | Bad Registry Entry | CHEFS::geyzuh.reo.dec.com::Steve_Marshall | Thu May 01 1997 13:07 | 6 | |
This was down to an incorrect registration of the Sheridan Tab control supplied with VB4 Enterprise. Steve | |||||
| 2546.2 | EVTSG8::TOWERS | Fri May 02 1997 13:01 | 44 | ||
Steve, I've been there and done that. The way I got the problem was by
upgrading some of the controls, including the grid control, for which
new stuff was made available on the web. Then I built a new exe and,
instead of building a new kit I just gave somebody the new exe. Hey presto
I got the same problem you did.
This suggests to me that when you talk about the kit having been
successfully installed on lots of machines you mean *a* kit has been
successfully installed etc., and that this kit is not identical to the
one you're struggling with at the moment.
It helps if you understand more about what's going on. The Setup.exe
program is just a bootstrap program which performs a few menial tasks
(related to the fact that the target machine probably doesn't have VB
installed) before firing up setup132.exe. This program is generated from
the setup132.vbp project somewhere in the setupkits (or whatever it's
called) directory off VB.
Setup132 then processes the file setup.lst which tells it which files
to install and how (where they go, whether they're self-registering DLLs,
exes, what comparisons to make regarding replacing existing files, how
much disk space the file takes so it can check available disk space etc.).
This file (setup.lst) is key and you should look at it and try to
understand what is going on for your application.
If you want to do anything out of the ordinary then copy the setup132
project to another directory, study it (it is well commented by
Microsoft), make your changes to it, build the exe, compress it, add
it to your kit and then test it.
When I've used the wizard in the past I've generated a kit, customised
the setup132 project and saved it off somewhere. Then when I make
changes or updates I just compress the new/changed files, copy them
into the kit directory and update setup.lst. This is a lot easier than
running setup wizard every time but requires care.
Needless to say every project has been different. On one I hand crafted
InstallShield 3 scripts, on another I customised VB Install Wizard
output and on my current project we're using Wise. Of them all Wise is
probably the best, but they're all useable with a bit of effort.
Cheers,
Brian
| |||||