>>>why AMEMBERS() doesn't search out all the PEMs for a VFP instance of COM >>object (as opposed to an instance of a native VFP class) in a consistent >>fashion.
>
>I am sure it deals with the fact that the Amember function is not equiped to work with a typelib. Now, if Amembers could be rigged so that it could interpret the typelib..... now that would be cool.

I agree, and that's what wish lists are for. Clearly, VFP knows it's a COM object and not a VFP-native class derived object, so I'd think it would be easy enough to probe the typelib information via the IUnknown or IDispatchEx interfaces; what I'm not certain of is the cost of doing so. But it doesn't promise to do that in the docs, and that'd be a change in the behavior we've had since VFP added the AMEMBERS() function. I don't know what goes on internally in VFP, and had no input on the design and functiuon of AMEMBERS(), so anything I come up with is, at best, a SWAG based on knowing a bit about how to get information from a COM object outside of the VFP environment.

As mentioned before, I'm not upset that it doesn't do what it doesn't explicit promise to do; what got all this started is that different people abusing the function got widely different results, none of which were the desired behavior. I'd just like it to fail in the same way across the board, or be able to track down why we have at least three different behaviors from the same build of VFP on a cross-OS basis.

It's only a matter of intellectual curiousity. I have plenty of other things to make me toss and turn at night...