INI settings will not save / installing on comp..

[James]

If the user has UAC enabled, they will be used to the confirmations while installing software. It's their responsibility to enable or disable it, not yours.

[Paul_Boland]

Hehehe... I'm always pulled up on my KnightTrek Productions folder when I post about it.

By using it as a hub, it's just one single folder on the root path, it's not like I'm installing all my programs into their own folders on the root path.

The installation path is not forced onto the user, they can change it if they wish. By that logic, setting an installation path for any software is forcing it onto the user.

It gets around the Program Files problem.

And finally, I, personally, have no problem with my root path being flooded with folders. At long as everything installs into its own folder and doesn't place files themselves into the root path, I have no problem.

Anyway, that's just the way I work, a suggested solution to the problem.

[lembi2001]

so i can take it from this thread then that no-one uses appdir$+ anymore??

[Bruto]

so i can take it from this thread then that no-one uses appdir$+ anymore??

To read only data, yes.

[MikeB]

Yves, I like this idea, but everytime the application runs, will it keep creating the sub directory and overwriting the ini?
---------------------------------------------------------------

That won't work on C:\ either.

Probably the other machines use Vista?

You should save the INI file to a sub-directory of the user's Application Data directory. To do that :

1. Insert a File object in your application

2. At start of frame create the directory AppDataDirectory$( "File" ) + "\YourSubDirectory" (with the Create Directory function of the File object) (note: do not forget the '\' before the sub-directory name)

3. Set the INI file (using the Set Current File action of the INI object) to AppDataDirectory$( "File" ) + "\YourSubDirectory\YourFile.ini"

[Tiles]

I still use the Ini in the folder of my exe. And install to C:. No reports about unhappy users so far. Not from XP users, not from Viasco users. Not since years. And not with thousands and thousands of users.

That's why i asked if they finally changed it. Because from my experience it still works to use the Ini in the exefolder. It reads, it writes. You just have to install to C.

By the way, what about an array? Do i also officially need to save it to the Appdatadirectory?

[Olivier]

If you want to be SURE that your application will behave correctly (save/write, load/read) by every user using a Windows system, then you MUST comply with Microsoft's rules. It is simply not recommended that your application writes to C:\ or C:\Program Files\.
And it's certainly not a matter of personal preferences. Clutter or not.

Topics of interest:
http://www.clickteam.com/epicenter/ubbthreads.php?ubb=showflat&Number=34572&fpart=1
http://www.clickteam.com/epicenter/ubbthreads.php?ubb=showflat&Board=5&Number=71019

EDIT: To be more accurate, the rules above apply for files to be written then read by your application. Of course your application can still read/load various external files (graphics, sounds etc..) from it's own directory or sub-directories. Those files being written by your installer, which automatically has the permission to do so.

[DJFuego]

Yes, follow the Best Practice laid down by M$. There are places in windows setup for correctly saving and modifying data without having to elevate or change priveledges.

You have no idea how many times I've had to modify access rights and setup special usergroups in Domain based environments because the programmer didn't think.

They expect you to give the user full administration privs on the local machine.. Errr. I don't think so.And if they use the registry this more work.

So think before you decide on saving changing data to Program Files or the application folder.

[Tiles]

Thanks for the advice guys

For me the Micro$oft way is useless. It doesn't make the system more secure. It bothers the users and developers. And makes the system more unsecure by that. Another excellent example of nonsense that just winds up users and does nothing else besides that. The most secure system is the one that is turned off. Everything else causes danger. No matter how much security features you implement. Anyways. That's just my personal opinion ^^

There are still open questions. When i install at C and use the Ini in the appath my Ini gets deleted when uninstalling. No trash left. Clean uninstall.

In case i use the Micro$oft way i leave trash at the users PC when my app gets uninstalled. Because the Ini gets installed by the app, not the installer. How to avoid that one? Leaving it at the place it is?

[Olivier]

You could leave the files if you wish your users to find their settings or saves back after a possible reinstall.

If you want the files to be uninstalled you could make your installer create the files. Install Creator can write to special folders like Application Data. Then those files would automatically be deleted at uninstall.
I think you could also tell your installer to remove directories inherent to your game like Application Data\YourCompany\YourGame\. Works if your application writes all its files in such a directory.

At uninstall some AAA titles ask if you also wish to remove the settings and save files. I wonder if this is possbile with IC. Yves has probably the answer.