>BOb,
>
>>Perhaps I am missing something obvious, or not so obvious?
>
>The concept I have in mind is outlined in Steve Black's article "Hook Operations" in the 08/97 issue of FoxTalk magazine.
>

Well... I tell you ... it is quite the article.

But, it seems to me that there still has to be some place where I need to identify the HookObject to the class so that the hook can be called. If this is so, I would have to do this in every class which I have created that are subclasses of your controls. (I guess this could be made data driven and work simmilar to the abstract class?)

Or, can the code be written to assume that the hook class for a class is always called classnameHook... for example...

cControlContainer would look for cControlContainerHook class. If it existed it would instantiate it...

So, in the init of the class you can have...

this.cHookClassName = UPPER(this.class + 'Hook')
if cHookClassName $ upper(set('classlib'))
this.oHook = createobject(cHookClassName)
endif

Then, in the event or method where the hooks are you can do...

if vartype(this.oHook) == 'O'
lPreMethodHook = this.oHook.PreMethodHook()
else
lPreMethodHook = this.PreMethodHook()
endif

if ! lPreMethodHook
return
endif

{code here}

Is the above viable? Or, am I way off on how this would work?

*****************

This is very simmilar to what I was considering doing... creating a .prg that contained functions and call the functions from the subclassed controls.

I still tend to think adding an i-layer, even if just to forms and control (UI) classes would make things easier... Then, I could use the internal hooks and not have to duplicate code.

Of course, our other choice is to subclass only the single object controls and build our own control classes so we can make use of inheritence.

BOb