Even though you'd think it would, NEWOBJECT() won't solve this problem...
>Hi Dave ----
>
>That does blow. If you're into VFP6, you can avoid that whole SET CLASSLIB stuff with NEWOBJECT()....otherwise, I guess you could maintain an array of the objects instanced from the released classlib and release them 1 by one via ASACN().
>
>
>>I hope I'm wrong but I think I've found a glitch in the way VFp appears to clear a class definition from memory. If no instances of a class exist and SET CLASSLIB TO is issued then all the class definitions should also be released. However this doesn't appear to be true...
>>
>>Here's an app that demonstrates the problem (you'll need to build a project t1 as described below before running this)...
>>
>>* Here's the code from t1.app's main program...
>>* set classlib to tshell
>>* local x
>>* x= CreateObject('MyClass')
>>* * this class should be created visually and added to t1
>>* project - simply a generic "custom" class
>>
>>* === Test Program Start ===
>>cs= 't1'
>>build app (m.cS) from (m.cS)
>>
>>do (m.cs + '.app')
>>set classlib to
>>
>>ok= .T.
>>on error ok = .F.
>>x= CreateObject('MyClass')
>>if ! m.ok
>> * this is what we expect of course
>> MessageBox('Cannot create a "MyClass" object', 64, 'TShell')
>> * so it looks as if the class library has been properly cleared
>>endif
>>
>>ok= .T.
>>erase t1.app
>>* will fail
>>messagebox('Erase before clear class: ' + iif(m.ok, 'Succeeded', 'Failed'), 64, 'TShell')
>>
>>* This shouldn't be necessary, but is!
>>clear class myclass
>>ok= .T.
>>* will succeed
>>erase t1.app
>>messagebox('Erase after clear class: ' + iif(m.ok, 'Succeeded', 'Failed'), 64, 'TShell')
>>
>>on error
>>
>>
>>
>>The problem this creates is that I can't easily run a 'shell' program which self installs new versions of a program because any module which does get released properly remains bound up in memory. So even though I can actually fire up the new app the old app remains 'somewhere in the ether'. I would imagine that this issue would have implications for things like COM objects as well but I've yet to play with those.
>>I can work around this by explicitly clearing every single class. But I know of no command/function that will list the classes that have been instantiated at some point.
Eric Shaneson
Cutting Edge Consulting