Sergey,

You are exactly right! After posting this question I drifted over to Foxite Forum, I had not been there in months. Lo and behold, there was a "Reading and Writing to INI Files" WIN32 API function there ( http://www.foxite.com/foxitehelplib/faq900655.htm ) that does what I wanted. I just finished testing it to read/write into the %USERPROFILE% directory by adding the DOS environment variable GETENV("TEMP") (which I had already been using to direct output of temp tables) to pass in for the path variable. It works fine.

I had mistakenly thought that the Get/WritePrivateProfileString APIs would not accept path parameters (from a brief test I did before).

Thanks,
Mark

>Hi Mark,
>
>You can still use GetPrivateProfileString and WritePrivateProfileString but with full INI file name including directory where it's located. GETENV("TEMP") should return current user temp directory.
>
>>To: All
>>
>>Been reworking a legacy app that uses GetPrivateProfileString and WritePrivateProfileString to read/write to INI files in the WINDOWS folder. New security requirements dictate that the "[C]:\Documents & Settings\..." folder is the only location that my client's security restrictions will allow for read/write of work or personal files, application temp files, as well as the INI files. I know that INI files have fallen out of favor, but we use it to store last logon name, default contract number, etc. I do not have direction to rewrite the whole application (much as I would like to) but just to insert upgraded security features.
>>
>>Does anyone know of a similar API function that will do the same thing as Get/WritePrivateProfileString but defaults into the "C:\Documents & Settings\\Local Settings\Temp" folder for reading and writing to the INI file? Perhaps it would have path parameters that are addressable when calling the API.
>>
>>(Note: I have been to www.AllApi.com, scoured the UT files & document sections, searched the Fox Wiki, checked the microsoft.vfp.api newsgroup, looked at VFP Tek-Tips but have not struck gold yet.)
>>
>>Thanks,

Mark Rietman