Cetin,

Thanks again for the feedback..

I guess I "will" have to look at replacing them all.

What I'd really like though, is a definite, "this is the cause" and "this is why it happens" (pipe dreams I suppose..)

- Aaron.

>As per Codemine I have no idea.
>IMHO replacing them all with "NEWOBJECT" seems like a necessary evil :)
>VCX'es are tables and like any other table they need to have aliases. Default alias for a table is its tablename. But if that's in use as an alias and you don't explictly specify a new alias VFP assigns one for you.
>You should check existence of a classlib before trying to open it and I suggest to explictly assign an alias. Aliasing also lets you to use same classname from 2 different classlibs. ie:
>
>set classlib to myVCX1 alias c1
>set classlib to myVCX2 alias c2 additive
>o1 = createobject('c1.myClass')
>o2 = createobject('c2.myClass')
>
>This way or that way you need to control that you're referring to correct classlib. IMHO NewObject() is simply the best way to control it. IOW checking each 'set classlib' is not easier than replacing them with NewObject().
>
>PS:As you might know I've FoxyClasses ( a series of classlib and classes for developers ). It was designed to handle VFP5 and up. So it uses 'set classlib' as per need. Whenever it does it explicitly checks if it's loaded already, if not loads. In first version I was caught with problems you describe and then honestly applied all those checks (and source code has NewObject() versions too, commented).
>Cetin
>
>>Cetin,
>>
>>Thanks for the response, I'm using VFP6
>>
>>We're talking about a huge application, which is also based on the CodeMine framework, so there are lots of "CREATEOBJECT" calls.
>>
>>Replacing them all with "NEWOBJECT" seems like an unnessecary evil, that I'd rather not undertake unless absolutely necessary.
>>
>>Do you know "why" this is happening?
>>
>>Thanks,
>>
>>- Aaron.
>>
>>>
>>>Aaron,
>>>If VFP6 or later use NewObject() instead.
>>>Cetin