>>Okay, it's not the same. What I was referring to was identically named classes in *different* classlibs -- from what I recall, which class you ended up with depended on which one was instantiated first. As for a case where you've got two identically-named classes within the *same* classlib -- I'm not sure which one you'd get. I'd hazard to guess it's dependent on order in which the classes appear within the classlib.
>>
>>>This is not he same as the same class twice. Those are objects that point to something strange.
>>>
>>>>I'm not sure if the key sequence was intended to be a solution to the problem, but I believe it was rather fielded as a possible explanation of how you might end up with the problem (key sequence is select all, copy, then paste). If you start with a form that uses the old class, copy some objects from it, then paste into a new form, then rebuild the project, you could end up with a reference to the class library with the older outdated class.
>>>>
>>>>>does not work on any vcx. :(
>>>>>
>>>>>>Ctrl +A Ctrl+C Ctrl+V
>>>>>>
>>>>>>>Thanks Lutz,
>>>>>>>
>>>>>>>I don't know how a second class got in there. Deleted the obsolete one.
>
>SET CLASSLIB is a bad idea generally. Because you don't know what you are getting. As you found out.
>
>NEWOBJECT() avoids your problem.
>

Don't think NewObject() would make a difference in the case here (where somehow a classlib has two identically-named classes). Beyond that, though I prefer self-contained code and thus NewObject(), there are speed consequences. That's what my March FoxRockX article is about.

Tamar