Let me step up to a more globale analogy of the ID to be your woorkshop to create your EXEs.
The project manager clearly is one major tool, when you have a pjx and open it, you can spend the rest of your development day or session in the project manager alone, many things you can get to via the menu can also be reached from within the project manager window and the designer and edit windows you start up from it. And then context menus, etc.
I think many people don't use all features and classes VFP offers, no problem. But when you learn more about the tools and features they offer, it's like knowing more than hammer, drill, nails, screws and screwdrivers to do a few household things like hanging a picture. Get to know all the tools in the workshop and you can do more things, more detailed, better aimed to the goals you want to achieve.
Now lets get to the project hook. First of all a hook in general is the concept allowing to get into some processes that happen at the point of events. Take the picture literally, A hook is like something that you insert into an existing structure. Project hooks are not thee only hooks available in VFP, I think VFP7 already introduced DBC events and that also offered hooks like BeforeOpen and AfterOpen. The project hook for example has Activate and Deactivate events. I'll get back to that later, as these events could be useful for the case the OP has.
You may know a form also has such events. So your question is very valid, why isn't it simply an extension of the project itself? A form also has no form hook class for form events, it has form methods and events in the form itself, like Load, Init, Activate. VFP doesn't always follow the same patterns. We just need to look back in the evolution of VFP. In a DBC you have one record that has stored procs in one memo, that can also have such hook code since VFP7, IIRC, when DBC events where introduced, which could also have been called DBC hook. For a project hook MS could have extended the PXJ with such a record and use the code editor for it just like for stored procs of a DBC. But they decided for a less tightly coupled implementation. A project hook simply is a class of a VCX (or in a PRG) that can be assigned to a project in project info. One hook for each project, but it might be the same hook you use in all your projects.
It's decoupled like the data environment class decouples the data environment from form classes, in comparison to the other variant Foxpro also still offers and offered first, SCX forms that have an DE simply as integral part of them. I guess one thing is it appeals more to OOP developers to have separation, you can combine separate things in several ways. It's about the separation of concerns. Project hooks can be solutions for multiple projects. So making them separate means reusablility.
And to overcome the limit of one hook per project, I know someone did a project hook that allows registering several project hooks and so you can also combine several project hook ideas without needing to merge all code into one project hook.
There would still be other ways to do this, they could have made a Project base class (actually there is, but lets not go down this rabbit hole) and enable to inherit from it with events, so you could not just have a class tree of project hooks but of projects.
I think the separation here makes sense, as projects are about your application, very different things, while project hooks are only about the work on the project, the IDE, they are not getting compiled into the final EXE they only are available during development. The project itself also is only about your development process, that's right, but each project is, well, about that specific project, so you could say a project hook can bee seen as something that extends the IDE for one or multiple projects and you decide on THE per project base which hooks should extend it.
There you have a detail of that tool that always was available in your workshop and you never knew you had it: You can write a project hook and use it in any project you already have, you can add features and now let me get back to Activate and Deactivate events. These events happen, when you have two projects open and switch between them. And now lets bring this together with the other concept I talked about and you probably also don't know is the other side of the medal and an idea to combine the two sides to the medal: The environments and the environment manager.
Here I can get back on topic to the core problem: Wouldn't it be nice you simply click from one project manger to the next, and everything is set up to now work with the activated project?
The project hook provides the right event for this - the deactivate and the activate. And environments and the environment manager offers the other part to solve the switch from settings for one project to settings of the other project.
The environment manager already was an extension introduced in VFP8 that solved the problem to easily switch between projects, environments are tightly coupled with projects, though in themselves they are again not integrated in PJXes. For other reasons then reusability. But that's why I got the idea: Why not combine all these partial solutions that alreaddy exist to solve the partial problems into something that even automates this so it becomes seamless to work on multiple projects in the same IDE session.
You can always solve this isse by having an ID related PRG to execute when you start working on a project, but the project hook eneables you to do this init's Activate/Deactivae events without thinking about it. And the envirnments are more dedicated to solving the environmental problem of DEFAULT and PATH and other settings.
Even if you're in the simple camp of putting all project files into one directory, with the (completely understanddable and correct) resonong the project manager is there to differntiate all the project items into several tabs and organize this one cluttered directory. It breaks down when you have multiple projects that you don't want to all be in the same folder. At least in subfolders. In some cases for reasons of being able to combine modules even rather in parallel folders or several topic oriented code repositories, also in the sense of project management and version control.
I guess this all is mind blowing if all of this is new, but it becomes a straight forward idea when you know the components of projects, project hooks, environments and see how they could easily come together. What I had in mind is that a one-liner, perhaps two-liner in a project hook Activate could simply use the environment meant for a project and so if you always learned all features of the ID and actively use them, this is the simplest idea to combine the two things to solve the original problem.
On top of that, I got the idea - and I also do or did that - you have some code in main.prg that is only there because you would like to debug in the IDE and not just run and test the EXE. Work without building and waiting for the next EXE, work and suspend and single step through code in the debugger. Again other tools you might not even want to use, but you're missing out a lot of opportunities there, too.
So why not make it a new paradigm, separate things you do for and in the IDE and things that are really belonging in the code of the EXE. Pepole stick to old solutions and don't learn to make use of new features. You already have your solution, maybe like Mike Lewis mentioned with a code section excluded from the final EXE by #IF..#ENDIF and only compiled and execute when _VFP.Startmode=0, for example.
Yes, there always are many ways to solve the same things. But any way it is, I think I'll make that my new way of thinking about this, throw out things of code that rather belongs to configuration and use environments, project hooks, etc.
Chriss
