>>>I looked a couple of .PRGs created by Rick Strahl (I am using one of his tools in my VFP 9 project). And he put many functions, procedures, and classes in just a couple of .PRG files.
>
>Just when the furor was dying down.... ;-)
>
>But "Encapsulation" would be a good reason for 3rd party commercial offerings to group functions into a proc rather than bulking out the project manager with huge lists of internal functions to distract the developer.
>
>BTW, if it's accepted that a prg/fxp in your project *is* loaded into memory at startup with the rest of the app, then an fxp "file read error" suggests either something (virus scanner?) is able to lock memory supposed to belong to your app, or the app is trying to access a copy other than its own. The developer's %temp% path could be a clue; definitely check the path to the prg in project manager since file read error could simply signal an attempt to access a %temp% other than the user's.

I added a bunch of logs to the application, in order to pin-point where something (and you maybe right) locks some .FXP files. And it appears that the password.fxp file is not readable right at the end of the application. That is, when a user closes the application. This could be a reason why nobody complained. Because when they would close the application and some error pops up, they may say "Screw it; I am going home"
I just added more log files (and removed some that didn't produce any results). These log files should help.
I also added additional SET PROCEDURE TO PASSWORD ADDITIVE at the end of the application (when one of the methods is called). I also added a check if FILE("password.fxp") is found. Because, my understanding is the FILE() look for the files inside the application .EXE. And if it does not find it, it means, bad things are about to happen.

As to "Just when the furor was dying down.... ;-)", we will find out soon enough :)