Printable View
Hey All,
I am building my application and installing it in several other computers to test if it works correctly. When I save my INI settings, they will not save the data or load the data. It works fine when I run it on my computer. Is this a path issue? I included the INI as an external file when building the application, should I have just left them out?
This could be a security issue. Microsoft don't want apps to use their savefiles in its own folder. This restriction counts for the #Program files# folder. And no, i don't understand that neither. It's Microsoft ^^
Try to install at C:\ and have a look if it works then. When yes you have to either install your app at C or store the ini at the place Microsoft thinks that's the secure one.
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"
Ah, did they finally change that? Seems that i have to redo some of my apps then ^^
Agreed its good application devlopment practice to use application data. This works in vista and also allows different installs per user on a machine should there be multiple.
One question to that. The install shield doesn't know about this folder. It is created by the software. Which means the folder in the appdatadirectory stays when you uninstall your app. Not ideal i would say. What's the best way to handle the uninstall then?
Ini++ can automatically put it in this folder, too. However, currently it is only the base folder. Future versions will allow you to specify a subdirectory to put it in.
You can always install in your own folder on the root directory, this gets over the issue with using the Program Files folder in Vista. If you have many programs on offer, do what I do and create one hub folder which contains all your programs. I install to,
c:\KnightTrek Productions\PROGRAM FOLDER
Where PROGRAM FOLDER is the name of the software being installed. That way, on the root directory of the computer, there is one KnightTrek Productions folder into which all my programs install.
Bad practice! Users don't want folders in the drive root cluttering up their PC.
It does get around the Program Files problem, but forcing a directory on to the user is never a good idea...
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.
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.
so i can take it from this thread then that no-one uses appdir$+ anymore??
To read only data, yes.Quote:
Originally Posted by lembi2001
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"
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?
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.
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.
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?
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. :)
Now that would be neat :)
Ah, found the place where you can install to Appdata path. That answers my question. Now i can install and uninstall these settings too. No need to create the stuff from within the app. Thanks :)
No, the Create Directory action will create the directory only if it doesn't exist. And the Set Current File action doesn't modify the file.Quote:
Yves, I like this idea, but everytime the application runs, will it keep creating the sub directory and overwriting the ini?
When you execute old applications on Vista, they are executed in compatibility mode. In this mode, you can write files to the Program Files directory : in fact the files are stored by Vista in another directory, but displayed as if they were in the Program Files directory.Quote:
Originally Posted by Tiles
If you have created your MMF application with MMF 1, MMF2 will set the Vista Execution Level of your MFA file to "None" when you load the CCA file, for compatibility reasons. I.e. your application will still be considered as an "old" application by Vista, so it will be able to save files (virtually) in its install directory.
New applications created with MMF2 have the Execution Level set to "As invoker" by default (in the properties of the application). In this mode, and if the UAC mode is enabled on the user's machine (99% of the Vista machines I suppose), your application won't be able to write to system folders like Program Files. In this mode, you have to save files to the Application Data folder.
You can also force the Execution Level to "None", but it's not recommended.
Yes, if you want to save a file, you should save it in the Application Data folder.Quote:
By the way, what about an array? Do i also officially need to save it to the Appdatadirectory?
Thanks for clarification Yves. I will store the Inis, Arrays and anything else saverelated for future projects in the Appdata direction :)
"Ini++ can automatically put it in this folder, too. However, currently it is only the base folder. Future versions will allow you to specify a subdirectory to put it in."
Just remembered you can actually. The filename can have seperators in it and folders are still made automatically. Clever me.