>>>It was the STEP = ON in my config.fpw. When I remove that line then amembers returns 0. Interesting.
>>>
>>
>>It's more than enabling the browser - it seems to be stepping through it that makes it work. Forget the beer - vodka seems more appropriate.
>
>I don't think that step through in the debugger makes a difference either (at least in Win95). I've tried everything I can think of and can't replicate the results. I thought it might be the actual location of the STEP= statement, but it didn't make a difference. Oh, this strange.
>
>>As a matter of intellectual curiousity, anyone got a better answer? The current state of affairs doesn't cause me a problem, since I don't use AMEMBERS() in conjunction with an OLE Automation server at the moment to do anything interesting, but it would seem to pose a problem for someone writing builders for classes based on generic servers created outside of VFP?
>
>Maybe it's just that Nancy has the magic touch. I dunno.

Wanna really get ill? The following proves that AMEMBERS() doesn't work with SET STEP ON correctly - it ignores the two read-only properties. Try this with a glass of Bromo nearby:

oShellObj = CREATEOBJ('Shell.Application')
?type('oshellobj') && Returns "O"
local x(1) && Creates single element array
a= oShellObj.Parent
a=oSShellObj.Application
y = amembers(x,oshellobj,1)
?y && = 23!!!!
?alen(x,1) && = 23!!!!!!
?alen(x,2) && = 2
?alen(x) && = 46 !!!!!!!!!!!!!!!!!!!


and if you examine the array, Application and Parent, both properties, appear from off-stage. Something's broke...