opengtoolkit-developers

variantconfig - missing keys

[Jim K. <ji...@ji...>]

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

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

RE: variantconfig - missing keys

[Jim K. <ji...@ji...>]

Mike,

Thanks for the comments.  I like this idea.  It certainly would be =
possible
to dynamically construct (as a variant) such a data structure.  If you =
have
the time, I'd like to work with you on the use-case that you have =
described,
and then we can back-out the requirements for a useful data structure.
Also, since the output of the Variant Config File VIs are a variants, it
would be possible to utilize variant attributes as a place to put this =
extra
data, without affecting the existing connector panes, in any way.

I'd like to also introduce another concept that I've mentioned to =
several
people, off-list.  The attached example (Merge Clusters) shows how to =
merge
the contents of a cluster into a different, by similarly typed, cluster.
The elements in the source cluster, which are common to the destination
cluster will be merged.  The elements which are not common, are ignored.
Where this differs from reading an INI file and populating a data =
structure
is that INI file keys do not have "type".  You must explicitly tell =
"Read
Key.vi" the type of the key, and then "Read Key.vi" will format the key =
from
a string into the data type that you have specified.  Basically you are
using your target data structure as the definition of the source's data
structure.

-Jim

> -----Original Message-----
> From: ope...@li...=20
> [mailto:ope...@li...]=20
> On Behalf Of Michael C. Ashe
> Sent: Tuesday, December 02, 2003 8:16 AM
> To: ope...@li...
> Subject: RE: variantconfig - missing keys
>=20
>=20
> It would be nice if the returned data structure was returned=20
> in a format that optionally included all the keys, whether=20
> INI data was found or the default was used, and what the=20
> value was. Where I'm going with this is that, in the event of=20
> an error/lack of data, it might be useful to be able to pump=20
> this into a slightly modified version of the Universal Probe,=20
> which would then display the cluster data in the tree and=20
> indicate if the data came from INI or default.
>=20
> -----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
>=20
>=20
> Someone has requested a feature for the Variant Configuration File I/O
> (variantconfig) library.  Here is the request:
>=20
> ########################################
> Together with the indication "Key found", it would be handy=20
> if - for example
> - "Read INI-cluster" would have an extra stringoutput that=20
> contains the
> name(s) of the missing key(s) so the user knows where to look=20
> in the INI-file. ########################################
>=20
> I was thinking that there are really two things that you want to test
> against:
>=20
> 1) Which sections/keys are in the INI file but not in the LV=20
> data structure
> 2) Which sections/keys are in the LV data structure but not=20
> in the INI file.
>=20
> The latter (2) is more important, IMO, since the user may=20
> want notification as to which elements were populated with=20
> default values.  The former (1) is useful when a data=20
> structure changes and one might wish to flush the data in the=20
> INI file to remove stale sections/keys.
>=20
> So, the question that I have, is how best to implement this=20
> feature?  It might be useful to return the missing=20
> sections/keys in a programmatically useful data structure=20
> (more than just a string containing a list of missing
> sections/keys)
>=20
> The 'missing sections' could be implemented simply as an=20
> array of strings -- one element for each missing section. =20
> However, the 'missing keys' structure would be a little more=20
> complicated because we would need to include the section=20
> owning the missing keys.  This could be implemented as an=20
> array of section clusters, where each section cluster=20
> contains the name of the section and the keys that are=20
> missing from the section.  This is shown below (where {}=20
> denotes a cluster and [] denotes an array):
>=20
> [ { section1, [ key1, key2, ... ] }, { section2, [ key1,=20
> key2, ... ] }, ... ]
>=20
> Any thoughts?
>=20
> -Jim
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.=20
> Does SourceForge.net help you be more productive?  Does it=20
> help you create better code?  SHARE THE LOVE, and help us=20
> help YOU!  Click Here: http://sourceforge.net/donate/=20
> _______________________________________________
> OpenGToolkit-Developers mailing list=20
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.=20
> Does SourceForge.net help you be more productive?  Does it=20
> help you create better code?  SHARE THE LOVE, and help us=20
> help YOU!  Click Here: http://sourceforge.net/donate/=20
> _______________________________________________
> OpenGToolkit-Developers mailing list=20
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
>=20