>Mr. Brown,
>
>Thank you for your coherent and knowledgable response. It is perfectly fine that AMEMBERS() does not function with COM objects (which is what we were discussing and not UI). However, it is not OK that a C5 error is the result of trying to use AMEMBERS() on a COM object. The C5 error is indicative of some problem (referred to, in some circles, as a bug) in VFP.
>
Actually Richard, you weren't discussing it; just complaining about it.

It's strange that, of all the behaviors we've seen hunting down what was happening when running AMEMBERS() against a COM object (I tried several common ones, including Shell.Application, MSCOMMLib.MSComm and Wscript.Shell) a C5 wasn't the net result - it simply didn't identify all the PEMs in a reliable and predictable fashion in all environments. And the behavior varied under the debugger, in some cases exposing all the methods miraculously within the debug environment. Can you provide a short snippet of code that will reliably produce a C5 error by attempting to run AMEMBERS() against a specific COM object?

A C5 error is indicative of problems in memory management, which can be caused in a large number of ways; some have workarounds now, others will hopefully be addressed in an upcoming release. The C5 is the moral equivalent of a GPF at the moment. It's rumored that an upcoming release will address some of the memory management issues for us and reduce the problem.

>By the way, what is COM, short for comedy?
>

No.