I have a clock program in progress which has a few options which I was going to save as a binary blob somewhere.
There are many ways to do this, each with their pros and cons.
- registry plenty of people dislike storing stuff in the registry
- data file what if we don't have write access (e.g. CD-ROM)?
- resource write access (as above), AV problems?
- ADS only for NTFS
Thoughts?
If its supposed to be on any cd or dvd rom,in readme.txt, tell user to install or move to a hd before use,to make it possible to write settings to a config file
Hi sinsi
Just to complete the list, you can also use an environment variable, which is indirectly a registry entry.
Biterider
Local user profile is a junkyard for many kind of files for user.
An AppData is similar folder for those files.
https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderpatha (https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderpatha)
I agree with Timo, probably the user's appdata folder if you're worried about running off read-only media.
Quote from: sinsi on May 06, 2025, 05:45:40 PM- registry plenty of people dislike storing stuff in the registry
- data file what if we don't have write access (e.g. CD-ROM)?
Just check if you
can write to the executable's folder, and if not, use the registry.
Quote from: jj2007 on May 06, 2025, 11:53:40 PMQuote from: sinsi on May 06, 2025, 05:45:40 PM- data file what if we don't have write access (e.g. CD-ROM)?
Just check if you can write to the executable's folder, and if not, use the registry.
I would also check the "user" folders as well for write access. Even in scenarios where the user has limited privileges (a work computer for instance), the user folders are a possibility. In that scenario the registry may not be a viable option.
Quote from: zedd on May 07, 2025, 12:19:32 AMQuote from: jj2007 on May 06, 2025, 11:53:40 PMQuote from: sinsi on May 06, 2025, 05:45:40 PM- data file what if we don't have write access (e.g. CD-ROM)?
Just check if you can write to the executable's folder, and if not, use the registry.
I would also check the "user" folders as well for write access. Even in scenarios where the user has limited privileges (a work computer for instance), the user folders are a possibility. In that scenario the registry may not be a viable option.
+1, I'd say current directory, user's appdata folder, and then registry, in that order.
My preference, being a registry disliker, is a config file in the application's directory.
As you know, it's really easy to locate that folder by using GetModuleFileName(). That way you don't have config files spread out all over hell and gone.
Of course, if you want to have separate config files depending on what the user's current directory is, you can just write them to that folder.
Seems like a pretty good assumption that both of these schemes should have a writable folder available.
OK, so my thoughts are
- exe folder
- user's appdata folder
- registry
The data is going to be 4xDWORDs (x, y, font size, text colour) and a unicode font name.
Since it's going to start with Windows, maybe create a shortcut in Startup and use command-line parameters.
Quote from: jj2007 on May 06, 2025, 11:53:40 PMuse the registry.
jj, I had you pegged as vehemently anti-registry :badgrin:
One thing I'm unclear about here:
What exactly is the "user's appdata folder"?
Is this their <username> folder under Users?
Quote from: NoCforMe on Today at 06:18:49 PMOne thing I'm unclear about here:
What exactly is the "user's appdata folder"?
Is this their <username> folder under Users?
I would use local appdata
LOCALAPPDATA=C:\Users\<user>\AppData\Local
APPDATA=C:\Users\<user>\AppData\Roaming