Hi david,

>>I know... yes you can do that, but in fact because of encapsulation issues you don't want to do this either, so basicly I endend up putting the same object into different subclasses of baseclasses. In fact in order to solve this problem VFP should support multiple inheritance in which all the major behaviour is inherited from the baseclass, but some methods and properties could be inherited from a custom class.

>No VFP should not allow multiple inheritance of implementation. It's a bad thing. There's a significant reason that new O-O languages (Java, C#) are not allowing it.

>VFP, could benefit from multiple inheritance of interface like Java.

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).

>>I guess you can. My problem with this strategy is that the contols become less independent (self contained). I want to avoid (as much as possible) on one object depending on another, esspecially for basic UI classes.

>Is it really any less self contained compared to the delegation off to a UDF? I don't think so.

You're right it is not. An object (especially a GUI object) should be as much self containt as possible and not be depended on any external procedure or UDF. If for some reason (mainly for frameworks) they have connections to other objects (like the applic object, business object, etc) the object should check if it is available; if not, then it should disable all the functionality which requires the connection. So, yes, if these are the rules, you might end up in writing the same code more than ones for each baseclass.

>>OK, that is you vision. Personally I like to develop database apps like they were just applications like outlook or excell. Just see the application as a document holder. Therefore toolbars are neccesary. For example: if my reports (Crystal Reports) were generated they show in a new window like a document: You can search through the document, Adjust the view (zoom), have a document view (the group tree), can archive, print, export and mail it.
>
>But those are basically menu replacement type toolbars. Toolbars are one click items that do the work of several menu or dialog box selections.

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.

Walter,