From: Jud C. \(S. Software\) <ju...@us...> - 2005-02-11 15:08:07
|
Paul, > ... Are you planning to empty > the entire file, or just the sections that DUnit populates, and are you > planning on only storing values different than the defaults? I would > imagine that if you delete the entire file, or only store values that are > not the default, that someone's code would break. Yes, absolutely, I'm sorry if it wasn't clear. As you say, it is not feasible to clear / delete the whole file as other settings may be stored in there. What we are proposing is a good half way measure, which is to delete the sections that belong to the tests, i.e. are named after the tests, before saving any non-default values. The existing DUnit code will not be detrimentally affected by this in any way, the concern (although slight) is that classes that have been written to inherit from TTestCase and its descendants might break if they do not always save non-default values. In my opinion it is unlikely but possible, and that is ! The benefits of doing it mean that the INI files and Registry hives are smaller, which is cleaner, tidier, that they are less likely to grow out of hand, and it will probably improve performance a little as well. The other area for discussion is the storing of settings in the registry, as per my previous message, but basically my proposal is to: 1) Store the settings under HKEY_CURRENT_USER/Software/DUnitTests rather than directly under HKEY_CURRENT_USER as it is now. 2) Change the Registry storing to substitute a '_' or something else for all '\' in the INI file path name, which would then give us a much flatter key structure that is less likely to break if the Windows parsing mechanism for Registry keys changes in the future. Juanco had proposed also looking at JSON for storing the settings, which looks great, but a lot more work than I personally am up for at this stage! What do the rest of you think to all those?! All the best, Jud SOCK Software http://www.socksoftware.com Makers of CodeHealer and SOCKShell |