MS or any programming language vendor could add a few methods you might use, but it depends on the specific case, you also don't get a bunch of suggested function names doing nothing before you don't provide code.
Every existing event has a base behavior and even the structure of methods often is not only foreseen as "for you". Programming always is about adding your own structure and so Doug's paper also only is one way of doing things.
A last good discussion about OOP design was in
I'll point out two things Tom Borgman said there in his post from Wednesday, August 22, 2018 7:57 PM referencing the three numbered questions Alieneko had:
Tom Borgmann said:
1. Add the method to your form. Forms are the only VFP-Class where you can add new properties and methods at design time without creating a subclass first.
Well, that's a) the lazy solution and b) only a local solution to this form
But as I said here and as Tom says in point 3:
Tom Borgmann said:
...some time in the future you'll have a main textbox class with so many functionalities that would better be placed in special subclasses.
His conclusion to sometimes solve the problem with a form method and using the form as an event handler that way is better than always adding behavior to the one subclass you made. It's a good step you did subclass the native classes, but it's not sufficient, as you not always will have the need to call the same routine from LostFocus and Click.
The conclusion should not be to use the form as it's technically the only simple and fast solution but to create a hierarchy of subclasses of the controls for specific cases. And in this case you better not just create a specific ComboBox, your situation rather asks for a control or container based class, which has both the lists of countries and their regions.
In this case, the mix of thoughts you need to have is about encapsulating everything, which belongs together into one class. In the case discussed in the MSDN thread, the need was to have an indicator for unsaved changes and that is much more common, in that case, you could define a data modification form that in the very general case would need to care for that topic of detecting and saving changes. Indeed it's not really a form job, it's located in the middle tier, but you have to make your way from each single control to that layer and it's one strategy to let each single control have a reference to the business data access layer implemented as some container or first escalate this to the form level which talks to the data access components.
VFPs direct data binding of controls to DBFs always makes you think 2 tier only, but once you use (remote) views or cursor adapters or data access business objects the layer to which controlsource binds isn't the database backend directly, its the cursor you fetched from the DB an which is then saved to the DB after biz rule checks from the layer of the data access components.
You don't get along well if you only make one subclass of everything, true OOP will have a hierarchy of classes. So you cannot rest on your laurels because you did that, what was suggested, always think in the most central concerns of OOP, encapsulation, reusability but also simplicity, not having one god class, one culmination point of everything only needed sometimes in some cases.
The more layers you have the harder it is to extend something, the more it branches the less you keep together things and VFP has no inheritance from multiple parents, that makes it hard to later create something merging classes from two branches. That's a balancing act. A composition from two or more base classes or in this case controls is one way to get to that type of inheritance.
This case is still quite simple you don't put together two different types of combo boxes from different branches, you simply put together two of your subclassed ComboBox into a container so they are combined in one class and can reference each other via their common container parent without any complex mechanism like a mediator to which one registers as parent level responsible for countries and the other as child level for regions. It's simpler, it's hardwired, but even when you would expect a country to have a hierarchy level between the whole country and region, then you could extend that class easily with another ComboBox. Eg in Germany we have the country and states and regions would perhaps best compare to what we call "circle", so there are three levels.
The essence is, you do add more than just the one subclass, just life is more complex your OOP hierarchy should reflect that. You can delay some class design for later refactoring as long as you only have a use for something once, then you start with a form level method. But you have to keep in mind this form level method exists for the two controls which are in fact one unit or should be one unit. If you always o for form methods you'd lose that coupling. If you always put all things into one class hierarchy level you're burdening everything with something you only need in some cases.
You can have a set of additional methods making general sense, a set of properties as Doug Hennig proposes, but in the end the meat of the whole structuring is neither common methods and properties or PEM in general, but the way you structure your hierarchy and are not lazy to define some new controls and compositions reusable in several places.
For example, the next generalization thought about a region picker with country/region list could be about that type of hierarchy. You come across that in many places, You have formula/recipe, order/order details, house/room, etc. you could use a control with two lists of which the choice in one filters the other as a very generic drill-down control.
Bye, Olaf.
Olaf Doschke Software Engineering
![[hammer]](/data/assets/smilies/hammer.gif "[hammer] [hammer]")
