Walter,

(and Peter I'm coming down with some kind of crud so I'm only going to reply to the easier of the three posts in the thread tonight, more tomorrow)

>Just help me and the lurkers, what is the difference between the two ? Can you point out what the objection against "multiple inheritance of implementation" is and how this relates to VFP (for all that is applicable, since VFP is a total different language than C++ in which strict typing and overloading might be issues).

Check these two Wiki articles:

http://fox.wikis.com/wc.dll?Wiki~MultipleInheritance
http://fox.wikis.com/wc.dll?Wiki~InheritanceInJava

In the context of this thread here's some rough pseudo code bear with me on the actual code and syntax used...

define interface iDataChangeColoring

* interface properties

nUnchangedColor = rgb( 0, 0, 255 ) && control ForeColor when data has not been changed
nChangedColor = rgb( 255, 0, 0 ) && control ForeColor when data has been changed

* interface methods

public function ChangeColor()
* abstract method no code implementation allowed
endfunc
enddefine


define interface i3DFocus

* interface methods

public function ChangeFocus( plGettingFocus )
* abstract method no code implementation allowed
endfunc
enddefine


define class cTextbox as TextBox implements iDataChangeColoring, i3DFocus

public function ChangeColor()
* interface method must provide implementation code

if ( getfldstate( this.ControlSource ) > 1 )
   this.ForeColor = this.nChangedColor
else
   this.ForeColor = this.nUnchangedColor
endif
endfunc

public function ChangeFocus( plGettingFocus )
* interface method must provide implementation code

if ( plGettingFocus )
   this.SpecialEffect = 0
else
   this.SpecialEffect = 1
endif

function GotFocus()
dodefault()
this.ChangeFocus( .t. )
endfunc

function LostFocus()
dodefault()
this.ChangeFocus( .f. )
this.ChangeColor()
endfunc

endfunc


define class cCheckbox as Checkbox implements iDataChangeColoring, i3DFocus

public function ChangeColor()
* interface method must provide implementation code

if ( getfldstate( this.ControlSource ) > 1 )
   this.ForeColor = this.nChangedColor
else
   this.ForeColor = this.nUnchangedColor
endif
endfunc

public function ChangeFocus( plGettingFocus )
* interface method must provide implementation code
* null implementation, we really don't want to change this appearance
* of course we could simple not implement this interface, but we
* do to provide consistency across controls
endfunc
enddefine

Ignore the replication of code it's only in here as an example.

Now the lowest level cTextbox and cCheckbox classes have had two interfaces (properties and methods) added to them. To the outside world they both support the iDataChangeColoring and i3DFocus interface. I can say ? thiform.txtFirstName.nChangedColor if it's an instance or subclass of the cTextbox.

This is a cool thing, if I change the interface definition, all of the classes that implement it see the change. Of course if this means adding/removing a method all classes that implement it need to be touched. But consider the alternative with the current state of VFP if we were simulating interface inheritance. We'd have to open every class and invoke the Add Property/Method dialogs and make sure that we typed the name and comments identically every time. This is a much bigger effort.

Now if two interfaces define the same method:

define interface iXYZ as iMyCoolInterface && yes interfaces support inheritance
public function MethodX
* abstract method no code implementation allowed
endfunc
enddefine


define interface iQWERTY
public function MethodX
* abstract method no code implementation allowed
endfunc
enddefine

it doesn't matter to a class that implements both interfaces, because all they are getting from the interface is the method name. The method is will have code in only one place in the class.

Contrast this to multiple inheritance (MI) of implementation that C++ allows. If the two parent classes have code in MethodX, which one does the child class inherit? all of them? how does it know which one(s) will execute? These are the problems associated with this type of MI.

Another good resource is to look at COM objects in the Object Browser. You can see all of the interfaces that the object inherits.

The above implements code would let VFP do one thing better than Java. Java interfaces are not allowed to have properties they can only have methods. Personally I think this is a significant problem with Java interface defintitions.

>I'm just talking about menu replacement type toolbars. In virtually all commercial programs I know off, this is the case. I wonder what you're talking about. Can you give an example of the kind of toolbar button you talk about ? If about common actions directly related to the form. They should be available via a custom menu that becomes active when the form is activated and/or via a menubutton on the form itself. If a menubutton is overkill, then a simple commandbutton on the form should do also.

Buttons like table navigation etc are the ones that I dislike as toolbars. I have a container class of those that I drop onto every form that needs them and never have to worry about them.