Peter,
>Don't you have any stuff included as excluded in any of your project files?
It is quite rare that I exclude anything but .H files. I've learned to remove the packaging dependencies, so my code packaging is granular enough for this to be a non-issue for
my code. I did just have to do some exclusion in one project because of truly cruddy classlib packaging used by another developer.
>Imo, that target would be quite fundamentalistic and does not sound to me as 'easier'.
We just see the different side of the problem as the easier solution.
>My own method is:
>
Each module (an app) has its own pjx in its own map.
>All prg's, vcx's, etc. are 'owned' by a module and ideally reside in the specific map.
>I switch to the map to change things.
>There is a special program (b.prg) that builds an app based on the only pjx in the current map. This b.prg first manipulates SET PATH, since it must refer to no other maps at all.
>BUILD comes with a messagebox. There I answer 'Ignore all'.
>The result is a pjx/app that has nothing else inside than what is in that map.
You might think about storing this metadata in the User memo of the project, although it would be subject to loss on project corruption. So backups and/or using an external XML document might be appropriate.
>You might wonder why I started this thread then. Well, I also bear responsibility for a legacy application. It is completely impossible to restructure that stuff. Both your and my solution are impossible to implement in that legacy app. Here's an anecdote: Just this morning betatesters were testing the new version of that application. Guess what, an error occurred exactly because a prg had sneakilly got included in an app where it should not have got included. The routine also resides in the exe and uses an included table. That table is not known to the sub-app, so it could not be found. Bang..
And you are also going to be susceptible to bugs going the other direction. If you mismark something as exclude and that functionality really does get called along some execution thread you'll hit program not found errors at runtime.
Supporting legacy code that wasn't designed with optimal packaging is problematic, but it's not fundamentally VFP's fault/problem. It is good that VFP is hookable enough to create workarounds to these sorts of problems.
