>Thank you Sergey and Naomi for your lightening quick response to my query.
>
>So my question was not as dumb as I feared. I wonder why VFP doesn't include such a tool.
>
>Jim

Perhaps simply because of the danger of exchanging something with a wrong/incompatible class. And even if you would be limited to only use a class based on the same baseclass...

But in fact there is such a tool within vfp. In the class browser you can redefine classes. As far as I've used it you cannot redefine the class of subobjects (eg change a control's class on a form), only the outer class (the form itself).

Mostly the situation occurs, if you use base classes for objects. Otherwise you're perhaps doing too little design/planning or your class hierarchies are forking too much or too early.

Think about the purpose of subclassing, that is specialising a class. Typical levels are framework classes, client specific classes, application specific classes (when maintaining an application suite for a client). You'd then use only classes from the application level in your application. If you need to use a framework class, you'd first make a client subclass and an application subclass, not changing anything in the subclasses. That enables you to later specialise on the appropriate abstraction level of your class hierarchy.

an example: your framework has a fw_textbox, for your client abc you have a subclass abc_textbox using a certain font, for client xyz you use a different font in xyz_textbox, a client mno does not want a specific font, still you subclass fw_textbox to mno_textbox. Then you create an app and subclass the textbox to app_textbox. In your forms you should only use app_textbox. it inherits the properties and methods of your framework, the specialisation for a certain client and then you can add a specialisation needed for the application.

That's just an example, you could rather have other main levels of the classes you can think of, eg you rather work on one application you specialise for each of your clients, then you'd rather have client level classes based on app level classes based on framework level classes. Additional to that all those main levels can have a fine structure of classes and subclasses, eg you'll perhaps have a date textbox and a time textbox both based on the framework base textbox, still being framework textboxes before you subclass these to the next level.

Bye, Olaf.