o = CREATEOBJECT("nested") ? PEMSTATUS(o,"inner1",5) ? VARTYPE(o.inner1) ? TYPE("o.inner1") ? o.inner1.name DEFINE CLASS nested as Container ADD OBJECT inner1 as innercontainer ENDDEFINE DEFINE CLASS innercontainer as Container PROCEDURE Init() RETURN .F. ENDDEFINE
The PEMSTATUS says the inner1 object exists, yet it does not due to RETURN .F. from init. In the real world case, this is not that simple of course, there are condition checks, that may or may not lead to a subobject removing itself from a compound class. In my case it's a visual class, but it doesn't matter, the problem also exists in PRG.
I assume this bug is "by design", the inner1 clearly is a member of the class definition of nested, so it is a defined member, it is just not existing at runtime.
To overcome the issue I had to replace PEMSTATUS calls to TRY CATCH statements making use of the probably not existing sub object. As Vartype and Type also tell this unknown element is of type "O" (object), you can't do any precheck as caution about using such an object. Also the locals window will list "inner" as a node of the "o" object, if you start the debugger after creating o. So actually this most probably is no bug of the PEMSTATUS function itself, but of how objects and information about them are managed by VFP.
I wouldn't consider this a serious bug simply by seeing how many VFP software still works, as it may not make much use of such situations, but classes already put together at design time that eventually remove some of their inner components may cause trouble. And this time it's not about the infamous "zombie" objects as dangling object references are sometimes called, that remain if objects are not released correctly. RETURN .F. from init is a correct way of saying you don't want the object to become alive at all. Any objects init finally decides about it's existence with the .T. or .F. return value, .T. is just a default you don't even have to write into the code as RETURN .T.