I am using TJvAppStorage (TJvAppIniFileStorage / TJvAppRegistryStorage) from the JVCL for persisting configuration objects. When exiting a program I use the following code to check if the configuration has changed in order to ask the user whether he wants to save it:
I am using TJvAppStorage (TJvAppIniFileStorage / TJvAppRegistryStorage) from the JVCL for persisting configuration objects. When exiting a program I use the following code to check if the configuration has changed in order to ask the user whether he wants to save it:
function Tfr_Settings.SettingsChanged(out _OldSettings, _NewSettings: string): Boolean;
begin
_OldSettings := TheAppStorage.AsString;
try
FOnSaveSettings(TheAppStorage);
_NewSettings := TheAppStorage.AsString;
Result := (_NewSettings <> _OldSettings);
finally
TheAppStorage.AsString := _OldSettings;
end;
where TheAppStorage is a TJvAppIniFileStorage instance.
Recently I found that writing to a TJvAppIniFileStorage silently fails if the ini file is readonly. So the code above will always return false even if the configuration has been changed and the user might want to save his changes to a different file.
To solve this problem, I could possibly switch temporarily to a different file, but I would prefer to use something that simply keeps the data in memory without even requiring a file.
Is there such a TJvAppStorage descendant already? Or maybe a setting of TJvAppIniFileStorage?
function Tfr_Settings.SettingsChanged(out _OldSettings, _NewSettings: string): Boolean;
begin
_OldSettings := TheAppStorage.AsString;
try
FOnSaveSettings(TheAppStorage);
_NewSettings := TheAppStorage.AsString;
Result := (_NewSettings <> _OldSettings);
finally
TheAppStorage.AsString := _OldSettings;
end;
where TheAppStorage is a TJvAppIniFileStorage instance.
Recently I found that writing to a TJvAppIniFileStorage silently fails if the ini file is readonly. So the code above will always return false even if the configuration has been changed and the user might want to save his changes to a different file.
To solve this problem, I could possibly switch temporarily to a different file, but I would prefer to use something that simply keeps the data in memory without even requiring a file.
Is there such a TJvAppStorage descendant already? Or maybe a setting of TJvAppIniFileStorage?
"To solve this problem" - the problem being that the class silently fails? If so, and this might be too obvious and so I'm missing the point, sorry, why not modify the JVCL class?
ReplyDeleteThe problem is, that I can't easily diff the two configurations.
ReplyDeleteYes, I could modify the JVCL, but I'd rather avoid it.
Sounds to me like you should save the configuration every time irrespective of whether it has changed. Don't ask the user anything. If the config can't be written, show an error message, or ignore the error.
ReplyDeleteI agree with both Davids. Always save and warn the user if it fails. If that's really something you cannot do (for instance because there is no UI), then fix the JVCL and submit the fix.
ReplyDeleteAlways saving the configuration was removed from our internal programs on user request.
ReplyDeleteThomas Mueller for what underlying reason was that?
ReplyDeleteUsers enjoy pain
ReplyDeleteMany settings are project specific and should be stored on the server in a project specific directory. So the global settings file contains the defaults and if any changes are made, the programs tell the user about it (and show him a diff), so he can decide whether the changes are significant or not. If they are, he selects a new file name (mostly just a new directory) to save the modified configuration.
ReplyDelete