Thank you for your message.
The only ActiveX control my app uses is the DbiTech Toolbar, ctToolbar. Strange thing is that the application has been running for years without any problem. The problem started a few weeks ago.
You could be right that the Toolbar was registered in a certain way that causes the problem. The questions I have (for myself):
1. What prompted the problem now?
2. How to fix it.

We tried the following. We ran the new setup.exe (that basically registers the Toolbar ActiveX); tried it as Elevated (kind of like run as admin). Right after running this setup, we tried the app and the problem went away.
We did it before, some weeks ago. And next day the problem started again.
I don't know if the problem will go away now or just a temp solution for one day.


>This almost sounds like that error you sometimes got whenever a VFP program (using one of the older versions of VFP) would utilize one of the ActiveX components and cause the launching of a setup program (often one for Microsoft Office). Apparently this was occurring because of how the ActiveX component had been registered into the system -- the VFP application was expecting a registry key to contain some information, while Office would be registering the compoenent using some form of encrypted key (which looked like gibberish). Since this registry key didn't look right, Windows would fall back on the last installer that "touched" these components (in the particular case it was often MS Office).
>IIRC the "fix" was to change the registry keys to what would be expected whenever the VFP application expected to find. This would generally not be a problem with MS Office (or whatever application that used this encrypted key).
>
>>Hi,
>>
>>My application is installed on the VM server. Each user's desktop has a shortcut pointing to the executable (GPMWIN.EXE) on the VM.
>>This one customer has the following problem:
>>Whenever any person from a different desktop starts the application, a call to old version of SETUP.EXE starts. The old version of SETUP.EXE used to install run-time DLLS for VFP 9.
>>An IT guy did some testing and found that whenever the application starts it calls a Key in the Registry that does not exist. Hence, the start up of SETUP happens. User clicks cancel and goes on. But it is annoying.
>>
>>The IT found that the application (GPMWIN.EXE) calls the following key:
>>

>>1:38:24.7972746 PM gpmwin.exe 7552 RegOpenKey HKLM\SOFTWARE\WOW6432Node\Microsoft\VisualFoxPro\9.0\Setup\VFP NAME NOT FOUND 
>>Desired Access: Maximum Allowed
>>

>>
>>I know that GPMWIN.EXE (main program of the app) does not do it.
>>
>>Could one of the VFP?? file do it:
>>For example, VFP9ENU.DLL or VFP9.EXE?? I believe that the VFP 9 application uses these file (located in the application folder).
>>
>>TIA.