>Fred,
>I think we are communicating. I'm saying you are wrong about VCX class creation. (Not that I haven't been wrong a ton and might be wrong here too. :-)
>I'm saying at runtime a VCX based class will inherit from the parent you specified at design time, regardless of SET CLASSLIB's setting at runtime. I tested the scenario you detailed just to be sure. I did not build those VCX files into a Project, but I would be very surprised if that was a factor. I do agree that PRG work as you indicated. I was unaware that SET PROCEDURE TO could work in such a confused manner, but it does make sense that it would. When you say:
>DEFINE CLASS Sub AS SomeThing
>it can only hope that SomeThing is available. This instance has no knowledge of the original file the developer was using when Sub was conceived.

I did some further checking myself and you are indeed correct. I apologize. :(

SET CLASSLIB has no bearing on instantiating sub-objects, the CLASSLOC field within the VCX does control that. If there is a classlib specified there it *always* tries to use that library to locate the class. If you have the CLASSLOC field empty, it's a sure way to generate a C...5 error! < bg >

>
>>
>>I think you missed my point and I didn't exactly make it too clear, anyways. <g> The order you specify things DOES have an effect at runtime, but not at design time. When you modify a class for editting, it inherits things according to the location in the CLASSLOC field of the VCX. At runtime, it will inherit things in the order specified. Either that, or I'm not quite getting a handle on what you're describing...
>>