storage path for %ss function

Paul, if I use the %ss code for save settings to a .ini file, the storage path is different between XP und VISTA/Windows7.

• in XP: c:\windows\??.ini
• in VISTA: c:\Users\Media\AppData\Local\VirtualStore\Windows\??.ini although the path %systemroot% is equal on both machines with c:\windows.

Is it possible to read out the actual storage path for the .ini file created with %ss under XP and VISTA/Windows7, because i want to read the .ini file without using the %rd, %rf, %rs controls?

Thank you

ClearWin+ uses the Windows API WritePrivateProfileString to save the data.

According to the Microsoft documentation for WritePrivateProfileString, the file is written to the 'Windows' directory in this context because ClearWin+ uses the user supplied 'file' to create the filename without its full path.

If this is accurate then you need a way to get at the 'Windows' directory for a given operating system.

However, from what you say, the Microsoft documentation is not correct so this needs further investigation.

Paul, thanks for your prompt response.

It looks like there is no easy solution to this.

I think that you are going to have to detect the current operating system and then, if it is Vista, find a way to get the VirtualStore path from the registry using CSIDL_LOCAL_APPDATA.

At this end the best solution would be for me to modify %ss so that you could supply the full path in your program.

Although the %ss function looks convenient, for full control you need to manage persistent program settings yourself.

INI files are the way things used to be done, manipulating entries in the registry is the new way. However, INI files are much more convenient than the registry, and if you mess them up, they result is easier to fix - not least because INI files can be readable with a text editor, and nothing else relies on them.

The problem is - where should INI files be located? Presumably, %ss thinks they should be put into the standard Windows folder. There is a lot to be said for putting it in the \Programs\xxxx folder - or the folder where the program in question is installed. Clearwin has a couple of lovely routines for finding where that is - they cope with a user who has moved the program folder or even renamed the program itself.

You use GET_PROGRAM_NAME@ to get the path and program name into a longish character variable. Now you need to get rid of the 'xxx.exe' from the right-hand end of it, and you can find that with any one of a number of command line parsing routines in FTN95, or work it out for yourself by finging the rightmost '\' character. What is left is the path to where the program is stored. An INI file there is always going to be in the 'right place'. If you are confident that no-one will rename the EXE, you can skip finding the program name, because you already know it.

This method is also useful for connecting to CHM help files installed in the program folder.

Experience tells me that routines for reading INI files need to be robust, and capable of coping with errors introduced by users opening the files and modifying their contents...

Eddie

I agree with Eddie, manage the INI yourself without using %ss.

I use the environmental variables HOMEDRIVE and HOMEPATH to determine a directory location for the INI file. The values of these variables are easily found with getenv@. The code works fine for all versions of windows.

VirtualStore is the shadow directory that receives writes from non-admin privileged users. As far as I know you should be perfectly fine to still read the file (VirtualStore\Windows\xyz.ini) using the %systemroot%\xyz.ini qualifier.

thank you very much for your help. I think the best and simplest way is to use the %systemroot%.

Bartl

Thank you very much for your help. I think the best and simplest way is to use the %systemroot%.

Bartl