>Therefore, you have not subclassed all the classes. Why? Have you bet to the hipotetical fact of not needing to >change that classes in the future (because doing so would be apply the change on every application -which may not be >a problem for you, indeed-).

Originally I didn't subclass every class because when I started using MM's (version 4, I think), I was just starting to program in VFP. I wasn't in a position to make those kinds of decisions.

As I've worked with various frameworks and VFP I've found that I haven't had much of a need to modify absolutely every class included with it. Since I haven't had the need, there hasn't been any really pressing reason for me to do it. It's relatively painless to hack the VCX's to point to a different parent if I needed it (and force me to test each app. w/those changes). VCXEdit works OK, HackCX (http://g2tools.com) also works nicely.

I'm really cautious with company-level changes to the framework. It's really, really easy to break another project and not realize it until much later (usually 6 mos. after, when you need to compile a new version of the other app.). A lot of the types of things I might add to those other classes (that I've decided to not subclass) are things I'd want included in the framework anyway. So, in those cases, I've gone ahead and modified the framework and send Kevin an e-mail w/my changes.

>- At least, have you subclassed ALL the classes involved in the Generic project that have to do with the frame -menu classes, form classes, etc.-? OR when you build a new application, the application menues -those which are constructed automatically by the Qstart.app- are childs of the menues FRAMEWORK classes, same with the Users form, etc.?.
>

I haven't changed the menus. However, changes to the "A" level classes in the Generic project should be copied correctly when creating a new project. I'd just use the VCXEdit utility included with the framework to point the classes to my new ones.

>- If the last point was not clear enough: you have modify EVERY place in Qstartma.prg, Setup.prg, Generic project, etc., so the new application can inherit COMPLETELY from your layer, or you have a kind of "MIXED-INHERITED" application?
>

Nope. Not completely. In my case, it just hasn't been necessary.

>Now a last paragraph about my situation: I'M REALLY SCARED OF THE IDEA OF BEGINING TO MODIFY THE QTSTART.APP AND THE GENERIC PROJECT. With all the problems I did TO AVOID modifying both -not other goal have pursued the experiments explained in the first message- I don't want to start to fight with the research, errors, etc. that all this would imply.

I can't help you there. The source to QStart is included so you CAN customize to your exact needs. It doesn't sound like anyone has done EXACTLY what you want to do, so I don't think you can avoid the research necessary to see what will work, and what won't.