Hi!

See my comments below...

>Mr. Grynchyshyn
>
>
>My English is not good enough to express, and I am dive into OOP
>just for serval months though i'm a 9 year foxer. I just said what
>i think, please tell me what i miss.
>
>>> First of all, in OOP the main role is for classes. Such thing as objects containership (as used in VFP for controls on eth form) is not a part of OOP - it is a part of the OOP modelling. So OOP here have nothing to the objects you place on the form and want to add a code to them - in OOP code is added to CLASSES, not to Object (instances of classes).
>
>
>A 'form' is actually a class define written by using visual tool(form designer)
>We can got the actual code of a 'form' with object browser by open
>a form then pick 'view class code' .

This is wrong opinion. Yes, the form defining is like a class defining. however, this is only for the FORM, and NOT for objects inside of the form. The objects you include into the form are still objects, referenced by form (contained in the form in run-time and design time). The properties and methods you change for child objects on the form actually are not changes like in class.

In addition, the 'view class code' button show the code, but it actually never works for forms that have 2 or more levels of containership. This is because Add Object statement in VFP does not allow to add object into the container on the form defined by DEFINE CLASS. So I do not think you can take this functionality as ethalone for all other things in VFP.

Think about the interface of the class and its implementation. The form itself is an interface, the objects inside of the form are implementation. You cannot add properties or methods to objects that are in the implementation part - because you can do this for interface part only. Create a class for some object, add a property - and this will be inetrface change for that class. Then on the form tobject of that class will have that property - because new interface is used, and because that object is used on the form, but it is not contained in the form's interface. that is the main point. Objects for form in VFP are just implementation of the form.


>
>When launch 'do form...', the fox may generate a class define from *.scx
>then instantiate an object. So we can explain why 'do form' has
>a subclause 'name', and why the code gen by class browser contain a
>property 'DoCreate=.T.'
>
>
>>>In case of VFP - it allows much more than OOP breaking some restrictions. As opposite, VFP does not have a lot of things from OOP theory. So the OOP is not an issue here at all, and we should not compare it with OOP at all and think if we need the feature you requested using other criteria.
>
>
>But i think vfp is a good oop language, most oop rule i read from books
>is found in it .
>
>
>>>For you, the main criteria here is comfortable work, as I understood, right?
>
>Yes, it is my origin points. Sometimes, we had to wrote many lines of code in
>method of object i.g. a command button, to accomplish complex logic.
>So i want to breaking them into serval function to make it good for
>understand and maintain. It is not good enough to put the functions in
>PRGs because i want the form to be standalone, and it is also not good enough
>to add many methods to the form. I want my app be good organized, easy to
>maitain...
>
>
>>>However, think about a huge number of new VFP developers that are not convinient with OOP at all. They even do not know what is classes.
>
>But fox does not oblige everybody use every featrue of it.
>
>
>>>But this is wrong approach, because in most cases class should be created and re-used on many forms instead of constant adding of code and properties to form components.
>
>In my (many) case, the command button with its long codes, just appear once
>in that form, so i don't want subclass from a vfp base class and subclass
>again by drag it to form.
>
>
>>>I hope you can understand now why this feature is not a good one. Even if MS will add it, I can bet it will be deeply hidden so only experiensed programmers will be able to use it (as now you can use it in classes defined in PRG by DEFINE CLASS).
>
>when create a new form with form designer, it means we subclass a form
>from vfp form, the new can override its parent and have new
>method,property. But why other object can not ?
>
>max.