David,
Thanks much for the extensive outlay. I will look into it seriously.
Let's say that I like it (and btw I use similar for the other non-VCL app);
What I will do is (seriously) look in the (dis)advantages opposed to how I implemented my stuff in the VCL. For that matter, I coincidentally have a practice example from a few days ago, rather similar to yours :
It is about the SpecialEffect = 2 (HotTracking) which is available in VFP7 (SP1) and wasn't in VFP5. Here is my code changes in order to let it work throughout the whole app :
THSV.SpecialEffect = 2
IF THISFRMV.ActiveControl.Name = THSV.Name
THSV.SpecialEffect = 0
ENDIF
THSV.SpecialEffect = 2
In addition I had to define the default of SpecialEffect = 2 in each of the controls. Lastly I had to feed each of the MouseLeave methods with the call to the UDF.
Note that this provides for a control with the cursor in it (Focus) to retain it's 3D status, which VFP doesn't provide (I think that's stupid : only when the mouse is hovering it becomes 3D. IOW, clicking the control and move the mouse away and it's flat again. So, this is solved more nicely now (I think)).
This was *really* a 5 minutes work, including "invention" time.
Though it's working at a 100 %, it may need another day because of the stupid (non-graphical) checkbox not receiving the flat state. It looks strange. So I guess now I have to create (draw) my own checkbox.
David, my main question would be, how would this compare to your way of working. I guess there is not much difference, but I am not sure yet.
PS: I don't have navbuttons on the toolbar, but on the form (they are not "general" enough :))
Peter
>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 )
>nChangedColor = rgb( 255, 0, 0 )
>
>* 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
>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.
