>I seem to recall an issue with C5 when you toggle the visibility of the main VFP screen. Just for grins, don't set the Visible Property of the screen to .F., and let me know if you still get the C5.
>

JVP, not to step in too close here, but NO. If you're getting a C5 with anything other than VFP6 pre SP3, it is NOT VFP trapping out because DCOM is missing - it's the OS telling you something is happening. There's nothing you can do inside of VFP (short of finding what's causing the anomalous memory access error) to suppress it, because it is not a VFP error message. It's a sign from God (actually, from the Windows Kernel) that your app did something illegal - either it attempted to address memory that doesn't exist, doesn't belong to it, or it doesn't have the necessary permissions to access as requested - ie trying to write to memory it could only legally read or execute. Win32 is letting you know it protected itself by shutting down VFP before it went and terrorized the neighbors.

You can't 'trap' a C5 error within VFP, in a VFP error handler or something like that, because it's a message that VFP was terminated. VFP is an ex-parrot. It is not pining away for the Fiords of Norway.

You may be able to avoid the sequence of events that caused it - that was the case with the DCOM fix to exactly one, narrowly-defined misbehavior that could be traced to an interaction with an OS component. Putting DCOM on a system was never a panacea for all C5 errors. It was for exactly one error that bit a bunch of people.

I've been kicking myself for a year on this. Please folks, don't expect all memory interaction problems, generically reported by the OS as a C5, to miraculously disappear because one narrowly-defined, well-identified problem related to memory was cured by it. If you have SP3, and IE is working OK and you get a C5 in any circumstance other than on closing the main VFP windows where the app started with SCREEN=OFF, sometime between you issuing a QUIT or one of the moral equivalents to it and VFP6 actually terminating, DCOM is not the problem. If IE and COM seem to be working OK, and you're up to date as far as OS patches, DCOM probably is not a problem. Or at least not THE problem.

Memory exception faults are a symptom of a deeper problem than "I forgot to put on some add-on to Windows that acts as a lucky rabbit's foot" or something at this point in time. It's only going to get worse, Upgrade to at least the most recent Shell and patch versions you can. If you're running Win95 or Win95a, upgrade to Win98 or Win2K, or if you insist on staying on Win95, at least to OSR2 version 2.1 or later, with the MS recommended patches. This does not mean a sloppy install of OSR2 over an install of Win95 retail. Back up, blow away that FAT16 partition, do a fresh install of the OS, patch to current levels and reinstall your apps.

If you exhibit extreme religious belief that retail Win95 is a more stable platform than Win98 on anything but inadequate hardware: (Disclaimer:I am not Jeff Marchi)YOU ARE DEAD WRONG


>>I've got an application that has a top-level form width 3 activeX controls on it: Benedict RAS control for Dialing, Marby's FTPx control and a progress bar.
>>
>>Only 50% of the times that I close out using a CLEAR EVENTS, I get a C5 on my READ EVENTS line. DCOM98 is installed and reinstalled, then I triple check the installation and installed it again, and Im also using the latest and greatest SP3 for VS6. I think its a 95 machine, but I haven't tested on 98s yet.
>>
>>If there's a fix, great, but is there even a way of surpressing it? I would be fine with that even.