I can share it, but it is NOT being called in the scenario I have described. I have a breakpoint in the Visual Studio debugger when any call to WriteProfileString is made and it is not being hit. I am NOT activating the configuration tool, which is the only thing that even CONTAINS calls to WritePrivateProfile string. What my program IS doing, is monitoring the directory for changes and calling GetPrivateProfileString (many times) after the file was changed with NPP.
The issue seems to occur if I make ANOTHER change with NPP and try to save within a few minutes of my program re-reading the INI file. That is RE-READING.
If I look at the directory when NPP reports that the file NPP just tried to modify was locked, the file size shows as ZERO and trying to use ‘type’ to view the content at a CMD prompt shows the file is empty. The content will be “magically” restored if I tell NPP to give up writing to the file, and NOT to save with a new name and then tell NPP NOT to reload the file after NPP (erroneously, IMHO) reports that the content changed.
If the file content changed, NPP did it. I’m afraid I am not likely to believe that Windows File Explorer is changing the file content, and I can prove my program isn’t writing to it, both by using procmon to see that the only write operations come from NPP, and by using the debugger to catch any attempt to call the write functions.