Timeline for Best approach to persist settings in files
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 18, 2017 at 18:47 | answer | added | InfoMaster | timeline score: 0 | |
| Nov 17, 2017 at 20:11 | answer | added | Gaurav Ramanan | timeline score: 3 | |
| Nov 17, 2017 at 17:13 | comment | added | Robert Harvey | Sounds like you just need to do the work of reorganizing this. The answer to questions like "should I use one file or several separate files" is "which approach best serves your organizational needs?" | |
| Nov 17, 2017 at 11:42 | review | Close votes | |||
| Dec 3, 2017 at 3:01 | |||||
| Nov 17, 2017 at 11:33 | comment | added | Neil | I'm partial to having a readable executable.ini file that your users can edit and a settings.xml for persisting program settings that users will likely not ever need to edit. If the program is modularized, then each module gets its own settings.xml file with data concerning that specific module. I learned a long time ago to avoid windows registry like the plague. ._. | |
| Nov 17, 2017 at 2:04 | comment | added | sergiol | @FrankHileman: Seems to NOT be much language dependent. We use a "made-in-house" abstraction layer for XML storage and parsing, which underneath uses MSXML. Windows, and the code is MFC over the platform toolset of Visual C++ 2013. | |
| Nov 17, 2017 at 1:34 | comment | added | Frank Hileman | What language and programming environment? Seems like definitely windows. | |
| Nov 17, 2017 at 1:01 | history | asked | sergiol | CC BY-SA 3.0 |