RE: variantconfig - missing keys

[Michael C. A. <mic...@im...>]

It would be nice if the returned data structure was returned in a format
that optionally included all the keys, whether INI data was found or the
default was used, and what the value was. Where I'm going with this is that,
in the event of an error/lack of data, it might be useful to be able to pump
this into a slightly modified version of the Universal Probe, which would
then display the cluster data in the tree and indicate if the data came from
INI or default.

-----Original Message-----
From: ope...@li...
[mailto:ope...@li...]On Behalf Of
Jim Kring
Sent: Tuesday, December 02, 2003 2:34 AM
To: ope...@li...
Subject: variantconfig - missing keys


Someone has requested a feature for the Variant Configuration File I/O
(variantconfig) library.  Here is the request:

########################################
Together with the indication "Key found", it would be handy if - for example
- "Read INI-cluster" would have an extra stringoutput that contains the
name(s) of the missing key(s) so the user knows where to look in the
INI-file.
########################################

I was thinking that there are really two things that you want to test
against:

1) Which sections/keys are in the INI file but not in the LV data structure
2) Which sections/keys are in the LV data structure but not in the INI file.

The latter (2) is more important, IMO, since the user may want notification
as to which elements were populated with default values.  The former (1) is
useful when a data structure changes and one might wish to flush the data in
the INI file to remove stale sections/keys.

So, the question that I have, is how best to implement this feature?  It
might be useful to return the missing sections/keys in a programmatically
useful data structure (more than just a string containing a list of missing
sections/keys)

The 'missing sections' could be implemented simply as an array of strings --
one element for each missing section.  However, the 'missing keys' structure
would be a little more complicated because we would need to include the
section owning the missing keys.  This could be implemented as an array of
section clusters, where each section cluster contains the name of the
section and the keys that are missing from the section.  This is shown below
(where {} denotes a cluster and [] denotes an array):

[ { section1, [ key1, key2, ... ] }, { section2, [ key1, key2, ... ] }, ...
]

Any thoughts?

-Jim



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
OpenGToolkit-Developers mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers