Perhaps you need to recompile the classlib.

I have found that kind of problem (though not with the classlib) when the time of source change and compilation come from two diferent machines. It seems that VFP uses the server time for one thing and the terminal time for another. I try to keep all machines synched to internet time but sometimes they get out of step.

Alex

>Hi Dragan,
>
>thanks for your answer, but this is exactly what puzzles me: The source of UserDefinedClass (there has been a typo in my previous message) is accessible at least when the form runs. To prove, whether I have access to the source of that class, I issued
>

MODIFY CLASS UserDefinedClass of UserDefinedClassLib.vcx

>in the command window and I had immediate access to the UserDefinedClass and all of its source.
>
>So there is still a gap in the reasoning, why the debugger cannot have the same access.
>
>Greetings
>
>Hans
>
>>You probably don't have the source for your UserDefinedClassLib accessible to the debugger (could be one of components that come without source code), but as soon as you step over such a piece, or step out of it (shift+f7 or click the step out icon), you get back into the parts for which you do have source.
>
>>>

Thisform.AddObject('cntUpperSelector','Container')

>>>which is nicely shown in the Trace window. Some lines further down again Addobject(..) is used, this time placing an object, based on a user defined class contained in a class library, which is accessible. (Without the >Set Step On< this method does its job nicely, so the class lib must be accessible.) The command line is
>>>

Thisform.cntUpperSelector.AddObject('NextObject','UserDefinedClass')

>>>As soon as the debugger comes across this line, it displays
>>>

Source not available

>>>After some experiments and some cups of coffee I found the solution: By hitting F5 I could have the code to continue, but this is not what I wanted. So I made some experiments and finally found it:
>>>
>>>Just hitting > Enter + F7 < (Step out) does it!