Jump to content

Storing Initialisation Data in a Strict Typedef


Recommended Posts

Hi all !

I mainly use XML files as configuration file for my applications. And then use flatten/unflatten from XML to populate a configuration cluster...

I've made a routine which creates the configuration file if it has been deleted by the user. In that case the XML file is create with default values.

I usually 'store' these values in the strict type definition of my cluster (see In Strict Typedef png). I was wondering if it was a good idea ? Or should I explicitly bundle the values in my code (like in Init png) ?

post-18168-0-47892600-1350634843.png

post-18168-0-87528600-1350634857.png

Link to post
Share on other sites

I have very little experience with the flatten XML primitives so I'm curious, what happens if the XML doesn't match the typedef? Say you're typedef changes, or a user modifies the XML? Do the primitives try their best to match what they can or is everything lost?

Link to post
Share on other sites

We also use XML files for storing configuration. I think this is a great solution.

I do not think it is a good idea to use the default values of the typedef to serve as default configuration values, since this is very unreliable and difficult to mainintain. In particular, it means that the developer has to edit the source code (and rebuild the application) to change the default values. Moreover, one has to have access to the source code even to see what the default values are (or maybe you run the editor and view them there?).

Our approach is instead to include an additional file for each configuration (e.g., MyConfigurationDefault.xml pairs with MyConfiguration.xml). Associated with the default files we include "Restore Page Defaults" and "Restore All Defaults" buttons in the configuration editor. (We simply read from the Default files as appropriate.) This has worked quite well. (Note that if someone wanted just to know what the default values were they could also just open the XML file; in practice we just read them in the configuration editor.)

If a user were to blow away the entire ConfigurationFiles directory (this hasn't happened to us) reinstalling the configuration files (which has its own version so that reinstalling the configuration does not necessarily reinstall the rest of the application) restores the original files.

In short, I advocate:

1) Supporting recall of default configuration values in your configuration editor.

2) Storing default values in files in the same fashion you store the user-edited values.

[What this means in practice is that to set the default values we open the configuration editor, set the values to be the defaults we want using the editor, save the configuration, and then copy the resulting files as default files. Done.]

  • Like 1
Link to post
Share on other sites

I seem to remember a problem with this route (this may be going back a few versions of LV) where if you modify the typedef you lose all your constants.

I think in my case I had the typedef as a constant on the block diagram (it contained only booleans) and sometimes the booleans would all reset behind my back if the typedef was changed. This was LV2009 if my very rusty memory serves me correctly. This was annoying as the change happened invisibly and lead to some quite subtle logic bugs.

To be safe I think the other method you propose is a bit less likely to get you burned.

Hi Neil,

If you drag'n drop the cluster on your diagram, the constant created will keep the values set in the control definition. In LV 2011, it seems that, even if you modify the cluster, the set values are kept while the new values (from the new added controls) are set to 'void'.

As my cluster is only used as a constant for initialization values, if I modify it, I only have to check it once in my code... But indeed, for a question of 'security', I guess it's better to explicitly bundle constant values into the configuration cluster.

We also use XML files for storing configuration. I think this is a great solution.

I do not think it is a good idea to use the default values of the typedef to serve as default configuration values, since this is very unreliable and difficult to mainintain. In particular, it means that the developer has to edit the source code (and rebuild the application) to change the default values. Moreover, one has to have access to the source code even to see what the default values are (or maybe you run the editor and view them there?).

Our approach is instead to include an additional file for each configuration (e.g., MyConfigurationDefault.xml pairs with MyConfiguration.xml). Associated with the default files we include "Restore Page Defaults" and "Restore All Defaults" buttons in the configuration editor. (We simply read from the Default files as appropriate.) This has worked quite well. (Note that if someone wanted just to know what the default values were they could also just open the XML file; in practice we just read them in the configuration editor.)

If a user were to blow away the entire ConfigurationFiles directory (this hasn't happened to us) reinstalling the configuration files (which has its own version so that reinstalling the configuration does not necessarily reinstall the rest of the application) restores the original files.

In short, I advocate:

1) Supporting recall of default configuration values in your configuration editor.

2) Storing default values in files in the same fashion you store the user-edited values.

[What this means in practice is that to set the default values we open the configuration editor, set the values to be the defaults we want using the editor, save the configuration, and then copy the resulting files as default files. Done.]

Hi Paul,

Having to two files is, for me, not a good solution. If both files (configuration.xml and ConfigurationDefault.xml) are deleted, then you need to re-send files to the cutsomer. Which takes time... and time is money ! :shifty:

As an aside, have you looked at EasyXML? It's awesome.

Hi Crelf,

I took a look at EasyXML. This tool is very powerful when you need to respect some XML schema compatible with the rest of the world (which is not the case of Flattent/Unflatten to/from XML LV functions ; only LV understandable).

Edited by Zyl
Link to post
Share on other sites

Having to two files is, for me, not a good solution. If both files (configuration.xml and ConfigurationDefault.xml) are deleted, then you need to re-send files to the cutsomer. Which takes time... and time is money ! :shifty:

When I have a file that I would prefer not be deleted by the user (templates, default config, etc.) I usually place the contents inside a string constant inside the program and recreate it that way. One fewer file hanging around, and no chance of a user "accidentally" deleting (or modifying) it.

Other than that I agree with Neil: Explicitly bundle. Remember they are called "TYPE"-definitions, they are intended to define type and not value. It is tempting, very tempting, in fact very, very tempting to use those constants to hold values. Works great if the TD never changes, but a TD which never changes, well that is really just a plain old constant.

  • Like 2
Link to post
Share on other sites

Hi Paul,

Having to two files is, for me, not a good solution. If both files (configuration.xml and ConfigurationDefault.xml) are deleted, then you need to re-send files to the cutsomer. Which takes time... and time is money ! :shifty:

Well, I admit our situation is relatively simple since we don't widely distribute our software. I would still use the same approach even if we did, however, for the following reasons:

1) Users interact with our configuration files via a configuration editor so they are really not likely to delete the files.

2) If a user does delete the files the user can restore them simply by rerunning the installer. (Of course, this means the user has to have the ability--permissions and skills--to run the installer, but that seems to be a reasonable expectation given that it is common practice in the computing world today. If as a user I mess up an installation of an application I expect to repair the installation or reinstall the application.) We would require the same procedure if a user deleted the executable file. [Even if I had a reason not to give the user the installer I would certainly include the configuration files in the deliverable as data files to store in a safe place in the event of an emergency. I'm not putting anything secret in the configuration files.]

3) I don't want to have to edit my source code every time the default values change.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By GregFreeman
      I currently have a project that I am refactoring. There is a lot of coupling that is not sitting well with me due to typedefs belonging to a class, then getting bundled into another class which is then fired off as event data.
      Effectively, I have class A with a public typedef, then class B contains ClassA.typedef and then class B gets fired off in an event to class C to be handled. Class C now has a dependency on class A which is causing a lot of coupling I don't want.
      For my real world example I query a bunch of data from our MES, which results in a bunch of typedef controls on the connector panes of those VIs. Those typedefs belong to the MES class. I then want to bundle all that data into a TestConfig class and send that via an event to our Tester class. But, now our tester has a dependency on the MES.
      I see a few ways to handle this. First is move the typedefs currently in the MES class, to the TestConfig class. The MES VIs will now have the typedefs from the TestConfig class on their connector panes, but at least the dependency is the correct "direction." Or, I can move the typedefs out of classes all together, but then I am not sure the best way to organize them. Looking for how others have handled these sorts of dependencies.
       
    • By Dhans
      Hi, all I am doing now pulse oximeter project in labview. I have got signals from oximeter and waveform is generated in waveform graph. But not a smooth one. I need a smooth waveform like the image attached here. What are the applicable methods to solve this problem?

    • By HelenaDomo
      Hi all,

      We are a group of students from the University of Cambridge who are developing a new data connectivity system for researchers like us, its up at https://rinocloud.com

      It currently integrates with LabVIEW, Matlab and Python. The plugin will point your data directly at our secure storage where you can automatically add metadata results for easy and fast retrieval. We’re also rolling out plotting features for presenting the data, collaboration features for project teams and an integrated lab book.

      We are looking for new users, researchers like us, to help us to get feedback from our product.  You’ll be able to directly influence the product development so that you get a data system that is useful for you.

      Know more at https://rinocloud.com 
      https://twitter.com/Rinocloud
       
      Thanks, 
      Helena
    • By Steen Schmidt
      Hi,
       
      I've decided to take the temperature on a known issue, that lvclass files retain knowledge of some of their old content after it's deleted.
       
      Proof
      For some reason I'm not allowed to upload lvclass files, so I'll describe it instead (using LV2014SP1):
       
      1) Create a new class and save it on disk as class1.lvclass. No member data nor methods, file size on disk is 8 kB.
       
      2) Add one piece of significantly sized (to easier see the issue) member data, I added a 1000x100 array of DBL (with random default data in it). Save the class again, and now class1.lvclass is 4604 kB (why so much, should be around 1000 kB?).
       
      3) Delete all member data again and resave the class. File size on disk is now 1171 kB, I'd have expected 8 kB.
       
      4) I can't ever get rid of that extra data in the lvclass file, not even when I "save as" to create a similar class.
       
      Questions
      A) What's the reason behind this issue?
       
      B) Is there any way to really delete stuff from a class file, or is the only way to recreate every class from scratch if you want something truly gone?
       
      C) Is there a list (perhaps internal to NI) of which problems this issue causes? Here I'm talking about stuff like this and numerous other threads about class data suddenly not being updated or member data or methods not being called correctly with DD.
       
      Cheers,
      Steen
    • By Duc Tran
      I have a data file EMG signal .tdms, the signal represented by number of samples and amplitude (24bit data). I want to perform this signal into a time domain to perform spectral analysis EMG signal. 
      I look forward to help me continue my project.
      I send all write file and read file the signal EMG signals
      Thanks so much.
      P/s: Read EMG Signal read data file sEMG_1.tdms
      EMG monitor write EMG signal acquisition to sEMG_1.tdms
       
      Read EMG Signal.vi
      EMG monitor_.vi


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.