>Bob,
>
>If you are creating these methods outside the designer, you need to also put stuff in several of the Reserved memo fields, and work on backups because it's quite easy to totally confuse VFP. Some of the stuff is order dependent, and if there is something in the Methods memo that VFP is not expecting it'll just choke.
>
>FWIW, simply issuing ParentClass::Method() inside my overridden code without the need of hook operations has been sufficient for me, but I don't work in a big programming team. Hooks are useful in some situations though.


Thanks for the warning David. I've re-read Steven Black's Hook Operations article from the Aug. 1997 FoxTalk and now realize that it's not as straight forward as I thought. There are some subclassing issues to consider.

Could you suggest the best source of info on the Reserved memo fields and order dependent issues.

Bob


>>Nancy Folsom mentioned hooks as a solution. It seems that Steven Black, Barbara Paltiel, and Mark Mccasland all encourage or use this approach. Although I thought I understood the use of hooks, somehow I had never thought of hooks as a defense strategy. I am now in the early stages of figuring out if this approach will work in my framework (I wrote it), and if there are any undesirable side effects. My current plan is to add a collection of “My” methods to my base classes ... e.g. MyClick(), MyLostFocus(), MyLoad(), etc.
>>
>>The programmers using this framework will have to restrict themselves to writing method code ONLY in the methods that start with “My”. Each of the “normal” methods, such as Load(), would include my normal base code, followed by this.MyLoad() to pick up any locally required extra stuff. In cases where the child code should run first, such as in KeyPress(), the KeyPress() Code would START with this.MyKeyPress() and then be followed by my normal KeyPress() code.
>>
>>But back to your question ... I don’t want to move all the existing WhatEver() method code into the new corresponding MyWhatEver() method manually, so I plan to write a MoveMethodCodeToMyMethod.PRG program, and run it instead against ALL my existing SCX files. I was just checking out whether or not I would be stuck with a mismatched Methods field / ObjCode field in my SCX. (I have since been told by John Petersen that “Compile Form MyFile” will make things right again)