>>>>>I have a readme file from Microsoft that says you can send users to a website to get DCom98 or distribute it with your application.
>>>>>
>>>>>I would like to distribute it with my application and I am using the VFP 6 setup wizard. If DCom98 is not installed on the machine I get the "Fatal Error" when the setup program is executed but the install will continue.
>>>>>
>>>>>Does anyone have any suggestions on how I can detect if DCom98 needs to be installed and install that first?
>>>>
>>>>DCOM has been installed if the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\OLE has a registry value EnableDCOM present with a value of "Y". It may have been installed explicitly from the DCOM executable, or as a part of the IE 4.0 installation.
>>>>
>>>>>
>>>>>Microsoft says that the machine needs to be rebooted after the install . . . Is that capable in the VFP 6 setup wizard?
>>>>
>>>>The VFP Setup Wizard install is not capable of managing a split install; I've usually used an InstallShield or Windows Scripting Host script to manage the DCOM install, or left it as a responsibility of the installer prior to performing the VFP install.
>>>
>>>Hello Ed!
>>>
>>>Where did you find this info about DCOM98?
>>
>>LOTS of experimenting. I've known about the reboot issue with DCOM for a while (it's not the only canned component from Microsoft that may cause a reboot) and have come up with a couple of approaches to incorporating the DCOM setup into my installations. All are based on a similar approach; split the installation into two separate parts, once before and up to the DCOM install, and the remainder afterwards. If DCOM needs to be installed, copy down the folder structure necessary to complete installation after DCOM gets installed (this often involves writing an INF file or some other readable file that can hold values like target directories and program groups to be used in the second part of the install), and place a RunOnce key under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion (depending on sequencing and operating system, I write either a RunOnce, a RunOnceEx or a RunServiceOnce key value) to start the second part of the installation. I then fire the DCOM
>>installation .EXE as appropriate. If control is retuned to my script after DCOM completes, the user elected not to reboot, so I remove the RunOnce (or whatever) key value and fire the second script myself, and set it to force a reboot after the installation completes. If control is not returned to my script, DCOM triggered a reboot, and the RunOnce starts the second script for me. It's messy, and requires really thinking through the sequencing and packaging of installs (not a bad thing to do in any case.)
>>
>>Since this involves things that must fire before a post-setup executable, particularly one written in VFP, can be executed, the Setup Wizard really isn't capable of doing the job, even hacking the .INF and .STF files. So I write wrappers (InstallShield Pro, and I've experimented with WSH) to handle sequencing component installs, including DCOM, the appropriate VFP Runtime install from the Setup Wizard and other canned install packages, and to provide the scripting needed for things that require custom actions. A fair amount of the custom activity involves running applets written in VFP once the necessary VFP (and DCOM) components are in place to set up files, dynamically build shortcuts and the like (I rely more and more on the automation objects from Wscript like Wscript.Shell and Wscript.Network, and the Shell.Application object, and have experimented with some ADSI object manipulation.)
>>
>>Incorporating WSH into the install process gains lots of flexibility; you can build dynamic scripts using VScript and JScript and use these scripts in your install process. I use a fair amount of dynamically constructed VBScript with WSH for my more involved Admin installs, where I put a network install out for workstations to use to install my application; VBScript lets me build things for the workstation based both on decisions made during the Admin install and on values found on the local machine. You can do some amazing things with scripting.
>>
>>
>>>
>>>TIA TIA
>>>
>>>BB
>
>Hello Ed!
>
>Thanks for your detailed answer!!!!!
>I have two more questions:
>Where can I read about DCOM98? When does it need to be installed? Do all VFP exe need it, or only those, that Com DLLs?

What do you want to know about DCOM? There are a ton of whitepapers related to DCOM/COM+, as well as a number of KB articles whose answer to the problem is 'Install DCOM98'.

When does it need to be installed? From our perspective, at a minimim, it needs to be installed on Win95 systems that do not have IE 4.01 installed; Win98 systems all have IE 4.0 or later on them already, and keeping up with the patches on Windows Update has kept me from seeing any instance of this problem on Win98 boxes. I've also never seen it on NT 4.0 boxes with at least SP3 installed, and installing SP3 or SP4 will load DCOM support for NT.

The specific problem being answered is any VFP .EXE that starts with a CONFIG.FPW entry SCREEN=OFF or _SCREEN.VISIBLE = .F. that doesn't have DCOM support installed will generate a C0000005 exception on program termination following all files being closed but before the VFP process is destroyed. Someone reported that another workaround was to issue _screen.visible=.F. before issuing the QUIT (or whatever, I use a call to ExitProcess() in preference to using QUIT, and still get the error.)

It does not seem to matter if it is a COM or standalone .EXE, or if any ActiveX components are included in any forms. So there's something in VFP code that uses one of the DCOM support files during shutdown if the main VFP window starts in a hidden state.

Again, the registry key for DCOM was found as a result of experimentation with installing DCOM on systems that hadn't had it before; we went hunting for indicators that DCOM support was both installed -and- enabled on the system.

The use of the various RunOnce keys I found through some of the half-dozen or so references on the Windows Registry I have lying around here.

>
>Where can I read about these tricky Registry keys? I searched MSDN but I didnot find them.
>
>TIA TIA
>
>BB