On 31 Mar 2005, at 12:00, Beatrix Willius wrote:
Idea 1: Load the prefs not into a large number of properties, but into
a
dictionary.
Benefits: Only one object to carry around. No single properties to
create.
Drawbacks: Code depends on dictionary instead of properties. Basic
handling
of prefs stays the same.
This is your best bet. I have a system like this, although I don't
access the dictionary directly for most of the instances where I
manipulate the prefs:
Normally you have to be wary of a dictionary that has been imported
from something external (in your case an XML prefs file) because you
can't be sure of what it contains. A user could tamper with it so when
you think you're accessing an integer, you are in fact accessing
something else. This usually isn't fatal but has the risk of causing
unwanted KeytNotFoundExceptions and IllegalCastExceptions.
I have a module which contains a bunch of methods such as
SetPrefString, GetPrefString etc. where you can protect yourself
against dictionary inconsistencies. For example in GetPrefInteger(Name
As String, Default As Integer) if the data you find isn't an integer or
there isn't a value in the dictionary with that name, the 'default' is
returned instead of an error.
I have found this approach to be great because it easily allows you to
pass default pref values for everything. Not only is this good as a
fallback, but it initializes the value the first time a pref is read.
This also means that only when preference values are 'set' using
SetPrefxxxx, is the value stored in the dictionary which is then
written to disk - giving you very lean prefs files.
--
Charlie Boisseau
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|