Paul,

>I'd probably need/want something like this for the cContrls library, an I-Layer class that cForms::cBaseForm inherits from (instead of a base form), plus a few of the kCustCtl classes.

It was me, who brought up the topic lately <g>. I've solved the issue for me with Hooks. (I think you pointed me to that!?) I still would like to see an I-Layer in MM, but this would only be half of what I would like to to achieve. If you want to have different behaviours for different clients, you would need to have an I-Layer for each of your projects. So here is what I did:

- Each control has a cHookClasses property, that contains the hooks that are needed

- A Hook collection object is added to each control on init. The collection holds references to hook objects that are alredy stored in a collection in goApp. This way there's only one instance of each hook class that's needed. The hook objects are stateless (because they are used shared), all static information is stored in properties of the controls.

- In the methods of the MM control classes, I call a generic THIS.CallHooks() method, that calls the hook collection, so I have all the code that otherwise would have to exist in most controls, in my hook classes and only the code communicating with the hook collection duplicated in several control classes.

This way, the hooks can be sublassed anyway I want (for different projects, clients, etc), but I still have to modify the MM control classes. This is, where an I-Layer would still be helpfull. I could then implement my interface to the hook collection in the I-Layer.

Ok, one downside exists: the instantiation speed increases when dealing with many of the hook classes for a control. Speed issues when reacting to events are not really noteable.

Regards,
Armin