Hi Walter,

>>>But then I think this might be closest as possible to the VFP code.
>>I would question being as "closest as possible to the VFP code" to be a worthwhile target ;-)

>>From a pure OOP point of view I'ld have gone for an interface as the solution for the question of "one method" as well. If you have different "clumps" of functionality to add to different branches of GUI controls, the OOP answer would probably be to create objects implementing the "clumps" of functionality you identified and aggregate these to (or decorate with those) your GUI controls.
>
>Not sure I got all of this straight. You just mean as I said to add all needed interfaces to the GUI controls?

Nope. In statically typed languages design a "companion object" inheritance tree (the objects might be implementing a decorator pattern) to implement all your functionality and bridge one object of this class tree to each of the GUI controls. I should not have typed "control" to characterize an object of this class tree accompaning the GUI-controls.

>
>>When thinking of such an approach in vfp I'ld calculate that some of my convoluted forms for insurances have more than 400 GUI controls and nearly all of them (because of common customer GUI) have more than 100 GUI elements. Now I have to take users into account who start at least 4 of such forms simultaneously, giving me 1000 GUI controls running. Adding even one "custom" control of my own implementing the different functionality wished for to each control doubles that number and is decidedly unfriendly to the resources of vfp and the poor machine running the app. Since I know vfp, I'ld create a way to seamlessly subclass each control and either call common behaviour in a few global behaviour classes by delegation (no code redundancy but slight runtime overhead) or create a builder to keep the work of changing redundant code in common methods across diferent branches to a minimum.
>
>Again, I'm not sure if I got this all. First of all, I'm in the same position as you having forms with lots, and lots of controls on it. I'm not sure what you mean with "double up that number".

Adding [1..n] companion controls to each GUI control at least doubles the number of instantiated objects needed for pure display, where at least 50% are the "companion objects" and the rest are the GUI controls.

>The controls I'm talking about are subclasses of other controls, but exposing additional functionality. I guess I don't see the resource argument here.

Because using inheritance (only) as extending strategy for GUI controls is the best way in the vfp world when priorizing internal resources. If I were to implement companion objects in vfp, I'ld probably choose containers as base class, which I mentally subsumize under "controls" - hence my choice of words.

Other "behaviour enhancing/extending" strategies like aggregation or the decorator pattern, which give you further benefits like less redundancy, are impossible from a practical point of view in the vfpwhen there is a resonable danger 1000 GUI elements will be used simultaneously. But just because this pattern is the best way in vfp, it doesn't follow that this is the pattern of choice in .Net/java.

>Of course there is an issue where certain functionality occurs in different classes of different baseclasses. And though I could use deligation, I choose to use redundency (Also because the implementation of the new functionality ussually differ a bit accross different baseclasses) because of better encapsulation.

Agreed, I also see both approaches under vfp as valid and best choosen by personal preference.

>>BUT - such a strategy is appropriate for vfp's relativly slow object instantiation and non-linear resource consumption. Calculating the object instantiation in statically typed languages to be between 30 and 50 times faster for small "helper" objects, I get an overhead of the instantiation time of 20 to 30 small vfp classes for adding one helper object to each GUI control for 1000 GUI controls in a statically typed language - And yes, I am NOT talking first time start here for JIT's. So I'ld probably build some kind of GUI-companion object, keeping code redundancy down and somewhat nearer to my first "design reaction".
>
>Though I understand difference in performance in object creation, that is really not something what I consider as a problem in my case. I'm just looking how the obvious flexibility as shown in the VFP example can be solved in a strict typed environment.

There is some quite a bit of flexibility missing in statically typed languages, but if you choose a strategy more fitting [and nearly impossible in vfp because of the mentioned performance characteristic differences] you get other benefits. When driving a ferrari you don't have the "luxury" of filling the tank with cheaper diesel fuel, but the ferrari might give you other benefits. Even though there are high class BMW's and Mercedes cars giving you inordinate amounts of power with diesel engines.

>I don't want to drift off the arguments of resource consumption and first time JIT compilation overhead. I've seen messages that this is a problem in .NET esspecially on not so recent hardware, but I doubt whether it is relevant at all in this dicussion.

I don't won't to give the impression that all problems vanish as soon as you use another runtime <g>. I also see that not all is roses in .Net/java - but given the different characteristics of the language another strategy than the one causing the question is more appropriate in those runtimes. Thinking example: When asked to do some slicing in sets in java you'ld use collection API's, and in vfp just feed it into a cursor [and probably be better off]. When a java schooled developer programming in vfp6 without collections, after having put all the data into vfp arrays, asks you about keyed access into those arrays, you would not tell him to look up ascan, asubs and so on, but tell him to use cursors.

>>I'ld go for each languages/platforms strength instead of trying to mirror the approaches - and you are a seasoned enough developer to probably do the same...
>
>Sure, hence the question. How do I solve a particular problem that I've solved in VFP this way ??

By avoiding the problem at all, if/because a more fitting strategy for .Net exists. Therefore:
>>I would question being as "closest as possible to the VFP code" to be a worthwhile target ;-)

regards

thomas