Creating INI Files - C root path and Windows folder are off limits!!

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.

    Hi Folks.

    I'm running Windows 8.1 64bit and I've just discovered that writing INI files to the Windows folder or the C root path is not working. I'm putting finishing touches on DigiGraph 3 and need to save the applications installed path to an INI file so the DigiGraph 3 Screensaver can access the users created screensaver presentation files. My first port of call was writing this to an INI file in the Windows folder but it doesn't work. Yes, I have ticked off for it to use the Application Directory folder and I have even specified the Windows path "C:\Windows\MyINIFile.ini", but the file didn't appear.

    Still needing a location that I could easily store and access this file, I decided to write the INI directly to the C root path. Again this did not work.

    My only solution has been to write my INI file to the MyDocuments folder. This worked fine but I'm not happy with it. What if a user has their MyDocuments folder set to be on the SkyDrive or wherever!?! I can write INI files into my own folders just fine but not into Windows or the C root and this is not good. Anyone got any ideas on how to sort this or do I just go ahead and use the MyDocuments folder?

    KnightTrek Productions
    Please login to see this link.

    Did some research. The C root drive is locked down in Windows 7 and 8. You can create directories on it but not files. What a load of nonsense!

    So I've been looking around at my options and the File Object allows me to get the All Users folder. This returns c:\users\public. This would be great because this will be local on all computers but in the Fusion 2.5 help file is says not to use this command and to use the All Users Documents command instead. When I do this is is returning an invisible folder at c:\users\public\public documents. Is there a specific reason why I shouldn't use the All Users option? It would be ideal for me.

    KnightTrek Productions
    Please login to see this link.

    Hi Paul,
    If MS is willing to organize a little bit the amount of files each software is producing, locking some folders and enforcing some kind of policy make sense. Data of applications have to go in Application Data or All Users Application Data. Both can be retrieved using File object.

    Personally nowadays I would recommend not using INI's property to set the filename, but instead to compute it with events. In addition of avoiding some annoying side effects, it allows to first check for a file beside the executable (portable mode) and then for a file in Application Data folder (current user folder or all users folder).
    ouly

    Please login to see this link.

    Its not a great idea to use the root or windows directory anyway. It's definitely better to either use the all users/public user application data path or what you'll more likely to see with programs is the use of %ALLUSERSPROFILE%. This by default will return with "C:\ProgramData". Which is what I'd use if I ever had to store a config... ie %ALLUSERSPROFILE%\Program_name\config.ini

    As Ouly says, use ApplicationDataDir Paul. That's the standard now, also ProgramData can be used.

    Game Launcher Creator V3 - Please login to see this link.
    Bespoke Software Development - Please login to see this link.
    Learn Clickteam Fusion 2.5 - Please login to see this link.

    Danny // Clickteam

    When your program is running you should assume that you do not have permissions to write in any directory (not explicitly specified by the user) with the exception of the user directories. If you need such an INI file or registry key you should write it as part of the installer.

    For instance, an office's IT policy may prevent the user creating files or folders in any directory other than the user's home directory.

    (The All Users profile might be an exception but I can't actually find any guarantee that you can write to it from all accounts, so it may be that that can legitimately fail)

    - Please login to see this link./Please login to see this link.

    Thanks for all the feedback. Seems using the Application Data folder is the way to go, just don't like writing to invisible folders because I can't see the file to make sure it's right but it shouldn't be an issue.

    Quote from ouly

    Personally nowadays I would recommend not using INI's property to set the filename, but instead to compute it with events. In addition of avoiding some annoying side effects, it allows to first check for a file beside the executable (portable mode) and then for a file in Application Data folder (current user folder or all users folder).
    ouly

    Thanks, Ouly, but it wouldn't work for the screensaver. The INI file is storing the installation path of DigiGraph 3 so that the screensaver knows where it is and can access the screensaver presentation data that the user created at runtime. So I need to write this data somewhere that is common on all computers and have the screensaver read it and find the path and read the presentation data in question.

    Jax. I don't know how to write an INI file as part of an installer but I know Install Creator has that feature so I'll look into it.

    KnightTrek Productions
    Please login to see this link.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login