>Still looks "clumsy" to me. And you've effectively destroyed the previous "animal" everytime you activate a different one.

With the ability to SET PROCEDURE AS needed, that wasn't an issue. Only one screen was active at a time, so that's the PROCEDURE file that was active.


>Now, as for the maintenance aspect ... You've created 3 program files already, and will require an additional one for each additional implementation.

Some people would view that additional granularity as a plus, especially if you use SourceSafe.

>As I said, it's easier with an object-oriented language.

No argument that it's easier with an OOP language, but since 2.6 wasn't, you work with what you've got.

I used it quite effectively for all of our forms (excuse me, screens) in 2.6 to have specific behaviors for certain functions. I even had a form of inheritance that if the screen didn't create a particular function, there was the "base behavior" in a main SET PROCEDURE file that dealt with the "default".


>>>Also, it doesn't seem to be particularly useful unless you have "objects" ... so there are some language dependencies. Using "scoping rules", I can affect polymorphism in a procedural language, but it's pretty clumsy.
>>
>>That depends on what you define as "clumsy". I used to do this in 2.6 all the time:
>>
>>

SET PROCEDURE TO pig
>>DO speak
>>
>>SET PROCEDURE TO cow
>>DO speak
>>
>>
>>*pig.prg
>>PROCEDURE speak
>>?"Oink"
>>
>>*cow.prg
>>PROCEDURE speak
>>?"Moo"