Hi Charlie,

There are a number of potential problems that come with using the FROM clause of DEFINE CLASS. We could probably start a wiki topic about this to localize the pros and cons, but off the top of my head here's why I never use the FROM clause of DEFINE CLASS

1) Can't use the invocation stack for sensibly locating class definitions. (I do this a lot).

2) Thereafter moving classes from one PRG to another breaks code. (I do this a lot).

**--** Steve

>Hi Steve,
>Perhaps I misunderstand. I'm pretty sure I can't handle the flexibility of not knowing exactly who my parent is. VCXs have the parent class hard-coded. Do you wish they didn't?
>
>BTW, FROM RatFace.PRG fails in an EXE due to a confirmed bug. Jim Saunders (MS) verified this. VFP says it can't find the PRG. FROM RatFace.FXP works in an exe, but fails when just running PRGs if there's no RatFace.FXP, (IOW, it won't generate it automatically as it would if you ran Go.PRG.)
>So I use FROM RatFace.FXP, and ensure that the compiled code is available during testing... And I like having the class assured of it's parentage. What am I missing?
>
>
>>Bill, see http://fox.wikis.com/wc.dll?Wiki~VisualFoxProInvocationStack
>>
>>Say I have a class definition XX in RatFace.PRG
>>
>>I would *never* recommend
>>
>>

>>DEFINE CLASS YY AS XX from Ratface.PRG
>> * ..
>>ENDDEFINE
>>

>>
>>(Just because you can do something doesn't mean you should. When you hard-code the parent class location, you loose all the ability of flexibly use your invocation stack.)
>>
>>Instead, in your Main.PRG or shortly thereafter in startup
>>
>>

>>SET PROCEDURE TO Foo, Bar, ..., Ratface, ...
>>

>>
>>
>>Then anywhere
>>
>>

>>DEFINE CLASS YY AS XX
>> *  ..
>>ENDDEFINE
>>

>>
>>