Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Class Design Question
Message
From
08/12/2006 07:45:03
 
 
To
07/12/2006 04:40:03
Lutz Scheffler (Online)
Lutz Scheffler Software Ingenieurbüro
Dresden, Germany
General information
Forum:
Visual FoxPro
Category:
Classes - VCX
Miscellaneous
Thread ID:
01174970
Message ID:
01176013
Views:
7
Well, I think about the situation where you want something to happen at container.Mouseenter, but that is not raised, if you eg put a textbox directly to the right border of the container and enter ther (unfortunately that's the way it is!), so in a first approach you call the cntainer.Mouseneter in the text.Mouseenter. But you may have a label left of the textbox, alos inside the conteiner, and the container may have a bigger height than the textbox, so in some situations the container.Mouseneter works, in others not.

In this situation the Bindevent method is a good way to handle each MouseEnter in a central method. That also may be Container.MyMouseEnter(), but then this needs to be bound to text1.mouseenter() and container.mosueenter().

Regarding the outer container, I was talking about the control baseclass. This is in itself some kind of container, a very special container. That taken aside.

Tthe user (in this case a developer) of that compositioned control (no matter how it's composed) should have the right to add to the MouseEnter event whatever he needs in his special use of the control.

VFP base classes are partially done in a way, that overloading an event will stop the standard behaviour to happen, in other situations you need to explicitly call NODEFAULT to suppress the standard behaviour. So if you want to have such a behaviour on the one side you need to protect your code from not being overridable and on the other side need to enable the developer subclassing it or overloading it to add the behaviour he wants/needs. Then binding all MouseEnter events to "myMouseEnter" is a good way, as it still enables the overloading of the MouseEnter event without preventing the standard (myMouseEnter) behaviour.

The simples solution might be to advice the developer overloading events, that he should issue a Dodefault(). And in the end the last developer adding code to something is responsible for his code to work, so you should have a good reason to try to prevent overloading of standard behaviour.

Bye, Olaf.
Previous
Reply
Map
View

Click here to load this message in the networking platform