>>A project hook sounds doable, too, though I don't do all my class/form mods with the project open.
>
>The example of my first thread already does base on a project hook.
>
>But of course it would be really nice to have a designerhook to have a local solution to the problem.
>
>Especially no event fires, when you add a (subclassed) control to thing you are designing. The only point, where you can establish an eventhandler is the BeforeModifyFile and BeforeAddFile event. Afterward you could only play dirty tricks with a timer observing ASELOBJ().
>
>Assume you have a container with a label plus another control and can handle resizing of the lable also resizing the other control, then add this container/composed control several times to a form class and have each of them with their own eventhandler. Therfore a designhook.BeforeAddObject/AfterAddObject would be nice.
>
>The IN WINDOW clause is of course nice, if you don't use the project manager, but I'd not miss the advantages of project hooks, eg I do backup files I modify in the BeforeModifyFile event. And the IN WINDOW clause does not work automatically, you can't simply use the project manager and it's Modify button then.
>
>Bye, Olaf.

I agree, we really need to have hooks into some of VFP's internals. One that I've asked for several times (and never heard a response) was to have the ability to breakpoint on the use of a VFP command. Not just on a particular line of code with the command, but on use of the command period. For example, "USE sometable", it would be really handy to know when "USE" was fired, no matter what table/view was involved, no matter where it occurs in the code.

Once we had those kinds of hooks, there's a whole world of possibilites that could be "add-ons" through user written code.