Windows 7 / Ini / App Data Dir Problem

[SethAluma]

Like, one that checks if the AppPath$ is writable, if not, use AllUsersAppDataDirectory$( "File" ).

Generally, if they have UAC enabled, and your app is in "%ProgramFiles%\MyApp\", then AppPath$ = "%ProgramData%\MyApp\"

The reason for using %ProgramData% (AllUsersAppDataDirectory$( "File" )) instead of AppPath$ is so that that will be the path for everyone, whether UAC is enabled or not.
Reading %ProgramFiles% in your app sometimes reads %ProgramData%, but sometimes reads %ProgramFiles%, depending on your setup (happened to me twice before- no idea why).
Using %ProgramData% makes sure there's only the one path. (better compatibility)

In regards to them installing the software to C:\MyApp\, did they do it, and did it work? It's not a permanent thing, just a troubleshooting thing to see if that's what's causing the issue or not.

[SethAluma]

Hello ,
I may be wrong , but if you look at build 252 features

- INI object : new "Create INI file in Application Data directory" property. When this option is selected and you enter a filename without pathname, the file is created in an MMF Applications folder in the user's Application Data directory. refer to the documentation for more info.

your problems regarding INI should be solved , shouldn't they?
eric

That creates the Ini file in the %AppData% directory, which is only accessable by that user. For things like serial numbers, it needs to be installed in $ProgramData%, AppPath$ (provided it's not stored in %ProgramFiles%), or the registry (I highly recommend using the registry instead of an Ini file)

Why are INI files deprecated in favor of the registry?

[Nifflas]

That article is about storing massive amounts of data shared between several programs in either the registry or an ini file. This used to be a problem a long, long time back when software used to store their settings in ini files located in the Windows directory that were shared between lots of applications. It's highly irrelevant here and now for software having its own files with settings in the AppData folders.

[color:#666666]"INI files don't support Unicode"[/color]
- Neither does MMF2 (apart from the Unicode version I guess). An extension storing unicode data with ini syntax shouldn't be hard to create either.

[color:#666666]"INI file security is not granular enough. Since it's just a file, any permissions you set are at the file level, not the key level."[/color]
- Same goes for every file format, and irrelevant for storing an application's settings.

[color:#666666]"Multiple writers to an INI file can result in data loss."[/color]
- Same goes for every file format, and irrelevant for storing an application's settings.

[color:#666666]"INI files can suffer a denial of service. A program can open an INI file in exclusive mode and lock out everybody else."[/color]
- Same goes for every file format, and irrelevant for storing an application's settings.

[color:#666666]"INI files contain only strings. If you wanted to store binary data, you had to encode it somehow as a string."[/color]
- Well, obviously you chose a format relevant to the task you want to do. It's like saying .wav is a bad format because it can not store an image.

[color:#666666]"Parsing an INI file is comparatively slow. Each time you read or write a value in an INI file, the file has to be loaded into memory and parsed. If you write three strings to an INI file, that INI file got loaded and parsed three times and got written out to disk three times."[/color]
- No. It's up to the programmer how and when to make the ini extension write a file, not to the format itself. Ini++ is good for this.

[color:#666666]"Many programs open INI files and read them directly. This means that the INI file format is locked and cannot be extended. Even if you wanted to add security to INI files, you can't."[/color]
- Like every other file format. Not a problem.

[color:#666666]"What's more, many programs that parsed INI files were buggy, so in practice you couldn't store a string longer than about 70 characters in an INI file or you'd cause some other program to crash."[/color]
- Again, it's up to the extension programmer, not the file format, to do a good work.

[color:#666666]"INI files are limited to 32KB in size."[/color]
- That's fine for smaller quantities of data. Besides, I doubt the MMF2 extensions like Ini++ have this limitation. Perhaps it breaks the file format standard, but nobody will complain when they see a 33KB+ file with an ini extension in the settings folder.

[color:#666666]"INI files contain only two levels of structure."[/color]
- Again, you chose a format relevant to the task you want to do.

[color:#666666]"Central administration of INI files is difficult."[/color]
- Irrelevant if you need to store one program's settings in a simple file.

It's very common for software to store all kind of various settings in file formats for images, sounds, binary data, arrays, text, and so on. There's nothing unusual or wrong with this. If you design an application like my games that come with a portable and non-portable version, storing the settings in a file is the only option, and if I chose ini or another format is only a question of what kind of data I need to store. Also, check Felix Koehler's and Igor Levicki's comments on the article.

[SethAluma]

I know the article is a little outdated, i didn't say that every point in it is true, I just provided it in case anyone was interested is all.

I agree that for portable applications, an ini file in the AppPath$ directory is the correct way to go, but they were mentioning installing the application, which implies it's not a portable application.

It's up to your own preferences on where you store your data. Personally, i prefer to store my non-portable apps data in the registry (or %ProgramData%/%AppData% for things like pictures, templates etc.), and portable apps in AppPath$ (as portable apps won't be in %ProgramFiles%)

[Nifflas]

My recent games are avaliable as portable and non-portable version. The portable version stores the settings in the application folder, and the non-portable one stores in the user account's application data folder. It's the same executable that just uses a different settings path if it's installed. I guess that's a bit off topic though.

The article is not only outdated now, when it was posted in 2007 it was outdated by a decade. The ini file mess was a big problem back before we had a registry and standardized paths for storing program settings. It's not wrong to store a single program's settings in the registry, but what I try to point out is that it's equally right to use the also standardized AppData folders (and that the article can not back up otherwise).

[RickyRombo]

I was told to post regarding MMF2's inbuilt AppTempPath$ by LB.


View MFA

It appears to go to USER\AppData\Roaming\Clickteam so it should be the best solution in terms of size. But if you want it available for all users, then this is irrelevant.

[LB]

I'm on Vista with MFM2 build 251, and running from the MFA it goes to the same place as the MFA. Building and running the EXE goes to "C:\Users\{TempUsername}\AppData\Local\Temp\{TempF older}.tmp\". Compressing/not compressing the runtime has no effect.

[RickyRombo]

Ah, strange!

I can't remember what it was, but you're right it's apparently not that!

[BrashMonkey]

Hi again everyone,

I've done a bit more testing and it seems that for the two customers who are having a problem, my App sucessfully writes the serial to the propper location, BUT when its time to load from that same location, it either doesn't find it or is not allowed to read from it!

I'm using the YASO extension method mentioned eariler in the thread. I'm using: "GlobalSharedDocuments$( "YASO Object"+"/myapp/myfile.txt"

Any idea why the app wouldn't be able to read the file that it just sucessfully created?

I though this was the safe way that would allow for everyone to be able to read and write to it..or at least read it.

thanks

[JoKa]

Can't test it right now, but hope MS hasn't changed something.

Just to be sure, is this a typo?
"GlobalSharedDocuments$( "YASO Object"+"/myapp/myfile.txt"

Since you're working in the local file system, I'd expect backslashs:
"GlobalSharedDocuments$( "YASO Object"+"\myapp\myfile.txt"

Also, I first checked if the folder myapp exists, otherwise created it before storing files in it. Not sure if these details make a difference.