Greetings,
I'm having a hell of a time getting various objects to play fair. Here's some things I've noticed:
- If an object finds a locked file, it will not trigger a reboot. I've tried catching this via the object status; the number is never caught by an if statement, and the description is always ""
- If you have two objects that install the same shared file, it's a crapshoot who wins. It looks like an install-uinstall-install (or install-repair) cycle is necessary to get my app to run.
Basically, my app invokes the Access 97 Runtimes. With the new install, it's failing in an interesting way just after loading up our .mdb. It throws up a blank (!) messagebox, which I can click through. My form is "dead" however. I can only click File->Exit.
Our app also depends on the MFC 6.2 libraries. It looks like msvcrt.dll is locked (no surprises) and the install is copying the new msvcrt.dll as a ".rra" file, which is then copied to the right name on reboot. This _never_ triggers a reboot.
However, even a reboot does not cure the Reporter problem -- they may be unrelated. The point is, if I reinstall in some manner (a repair run w/o rebooting the first time triggers a reboot...) Access 97 runs w/o a problem. Our Access stuff uses VBA and JET 3.5 pretty heavily, but everything we need appears to be installed by the Access 97 Object.
I know this sounds a bit convoluted, but does this ring any bells for anyone? IS help is pretty thin on this subject.
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Fun with InstallShield Objects
Started by
clvrmnky
, Mar 12 2002 01:22
1 reply to this topic
Blake Miller Wonder
-
- Members
- 121 posts
Posted 12 March 2002 - 18:45
For whatever it is worth, we ran into similar problems with different applications.
What was happening for us is that our programs required the MFC files before our setup could complete. Our files required the new MFC files in order to register properly as COM objects. As a result, we install the MFC files and then check for a reboot. If that is required, then we exit, and after the reboot the rest of the setup can continue.
I suspect that perhaps the newer Access files might need part of the newer MFC to properly 'install'. If you can not get the new MFC installed first, without the reboot, then there is no reason to believe that the Access files will also install correctly at the same time- especially if it needs to register COM objects during its installation.
Since perhaps sometimes MFC is okay or not, or it runs first (before th Access object) or not, then you are seeing the various results.
We finally created a separate install for the MFC files and run that from within our primary setup. If the MFC is okay, we continue, if not, we ask user to reboot and then run our setup again.
What was happening for us is that our programs required the MFC files before our setup could complete. Our files required the new MFC files in order to register properly as COM objects. As a result, we install the MFC files and then check for a reboot. If that is required, then we exit, and after the reboot the rest of the setup can continue.
I suspect that perhaps the newer Access files might need part of the newer MFC to properly 'install'. If you can not get the new MFC installed first, without the reboot, then there is no reason to believe that the Access files will also install correctly at the same time- especially if it needs to register COM objects during its installation.
Since perhaps sometimes MFC is okay or not, or it runs first (before th Access object) or not, then you are seeing the various results.
We finally created a separate install for the MFC files and run that from within our primary setup. If the MFC is okay, we continue, if not, we ask user to reboot and then run our setup again.