Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. file info. rss.
 From: Rick C. Hodgin
  Where is Rick C. Hodgin?
 Indiana - United States
 Rick C. Hodgin
Subject: (Object) has inaccessible members-SOLVED
Thread ID: 365532 Message ID: 365532 # Views: 54 # Ratings: 0
Version: Visual FoxPro 9 SP2 Category: Errors & Debugging
Date: Thursday, December 27, 2012 7:09:51 PM         

UPDATE: SOLVED! Freaky. The problem existed because the object *WAS* included as part of the container class at instantiation. By removing that object from the class, and then programmatically adding it to the class in the class's Init event, it now works properly and as expected (and as it did on the form when it was included on the form as an object at instantiation -- interesting that VFP handles instantiated container objects and instantiated form objects differently in that regard).

This is a new one for me...

I have code that's been in use for months. It was code I developed and put on a form. I had form methods, form objects, etc. I refactored that code today and moved it to its own class. But, something I've never seen before is happening.

I had some code which executed this:

* The code for mth_delete contained (amongst other things)

This worked fine when it was on the form. The object is/was deleted. When it's in the class, however, the object *IS* deleted (that line of code is executed without error), but it goes into a weird state.

After the removeObject, the object still exists, but is inaccessible. Typing "? TYPE('thisForm.myClass.theObjectsName')" returns "O". Every member shows up in the debugger, but they all say "Expression cannot be evaluated". And none of them can be accessed programmatically. It's like it's a "ghost object".

If I try to addObject(sameName, "sameClass") it works, and adds the new object again. If I test for the object after removeObject() it says it exists, yet it lets me add it.

Am baffled ... unless this is because the class contains that object as a member at instantiation (it's not programmatically added later on). However, it was also included on the form and did not exhibit this weird "ghost object" behavior. Is it because it's in the container class object now as its parent instead of a form?

EDIT: One other possibility: I have a custom added class property which is linked to that object (has as its value "=this.objectName.Property") ... Is it possible VFP is keeping that object in memory in this "ghost" form because of that class property reference? UPDATE: This was *NOT* it.

Any thoughts?

Best regards,
Rick C. Hodgin


(Object) has inaccessible members-SOLVED Posted by Rick Hodgin @ 12/27/2012 7:09:51 PM
RE: (Object) has inaccessible members-SOLVED Posted by Rick Hodgin @ 12/27/2012 8:20:49 PM
RE: (Object) has inaccessible members-SOLVED Posted by Rick Hodgin @ 12/27/2012 9:12:03 PM