>>The main.prg does have a code that creates an object based on the ActiveX control. But if the control is not found or not installed, the main.prg does not know how to deal with it.
>>Note that this case is a very rare instance. Most customers run the SETUP.EXE only one time and after that they forget about it.
>>Please note that the ActiveX control is installed on the desktop, not on the server. So each user has to run the SETUP.EXE one time.
>>I think what happens is that the server has something that "attached" the setup.exe to the main application .exe. So, when the main application starts, it also starts the setup.exe. Even though there is nothing wrong with the activex control on the desktop. Because I can't imaging that more than one desktops had the ActiveX control damaged or uninstalled. It is that the application .exe starts both.
>>I am still waiting for the customer when we can have a GoToMeeting so that I can view the problem and investigate it.
>
>No, it's the local comp and Installer-hell. Close as Dragan says. There is an odd lot of installers like Inno out there fiddling files into the system while ignoring Microsofts way to deal with it. If you like to know how MS expects it, send me a keg of beer.
Why, isn't the m$ famous by always having open and freely available specs & documentation, to which it religiously sticks?
I've had instances of M$ stuff being impossible to uninstall, because for that it required the setup first (which was not just setup.exe or an .msi, it usually came with hundred megabytes of stuff) but couldn't find it. Why? M$ provided the setup as a self-extracting zip, which would delete itself when done. And if you extract it again, it's no use, it was stored in registry with full path, which included the temp folder where it was extracted, and that folder had a randomized name. How could it happen? Because the original setup, which needs to be present when uninstalling, and the self-extracting one were written by two companies who don't speak to each other, M$ and M$.
>The reg storing it, the msi database providing it and the MS Installer system is sophisticated and reliable and keeps the system stable. If there would not be those with the cheap installers and those installing code in user data space.
Exactly where m$ told them to put it, a couple of windowses ago.
>The good on a msi is, the internal database holds the info for info install as for uninstall.
The inno also provides an uninstaller by default. Don't remember whether it keeps several versions of the things-done file or only the last one, but it does know what it did the last time, at least. Of course, if you ran it a dozen times, for each new version, I guess it remembers only the last one. But then I think msi isn't better in that respect.
And, ah, BTW, if you could still have a proper firewall, you'd see that each run of a .msi actually calls home, no matter what.
