Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation


About tanksalm

  • Rank
    I've come back for more.

LabVIEW Information

  • Version
    LabVIEW 2010
  • Since
  1. I think I should clarify my situation and my suggestion. I am inheriting code with at least a hundred settings, mostly stored in clusters. These settings are saved in between runs of the program, so the user can start back where he exited the program. These settings are currently put into a giant cluster and passed into a manually-coded vi (call it MasterStore.vi), where the cluster is manually disassembled, and each setting is manually saved into an xml file. So they have a hundred calls to the "Store to <xml> File" vi (I forget what it's called) and another hundred calls to the "Retrieve from <xml> File" vi. In order to save another variable, they (now I) must modify MasterSave and MasterRetrieve accordingly. A very convenient replacement for this would be the "Variant to Config" vi. It would be possible to ensure all of those names exist and are unique, but really, would you want that task? It more or less requires a program in itself to do. I wholeheartedly agree that human-readability is important - what I'm suggesting doesn't change that; it just prevents accidental information loss. The vi (in my mind) is as much about human-readability as it is about developer convenience. The ideal behavior (in my opinion) would be for the vi to append a unique number to the end of duplicated variable names, and automatically name unnamed fields within the cluster. It's unnecessary to add a unique number to the end of all variables - I only suggested that for simplicity on the side of developing OpenG. Ideally (in my opinion), you could wire any cluster whatsoever to the vi, then read those same contents out of a file and back into the cluster next runtime. For instance, if I had the following cluster (four elements) that I feed into the vi: Cluster_Name String_Name = "Hello World" Boolean_Name = True Boolean_Name = False [unnamed] = True Then the save file would look like this: [Cluster_Name] String_Name = "Hello World" Boolean_Name-1 = "TRUE" Boolean_Name-2 = "FALSE" Unnamed_Variable-1 = "TRUE" Whereas currently, it looks like: [Cluster_Name] String_Name = "Hello World" Boolean_Name = "FALSE" <--- Or maybe this is "TRUE". The current functionality entails loss of information. I realize that the developer always has the ability to rename the elements. However, as "Variant to Config.vi" was also created for developer convenience, I think that my suggestion would be a very useful addition.
  2. I've been using the OpenG Variant to Config VI to save clusters. It is a very nice function, but there are two issues which prevent it from being as useful as it could be. The first is that if I have a cluster with two identically-named items (stupid to do, but for argument's sake), one of the two values will not be saved. This is because the key in the key-value pair is the same in both cases, and so the second value with name "Variable" overwrites the first. The second, closely related, is that if I have a nameless field in a cluster, this will go unsaved entirely (and will, in fact, throw an error, which is at least useful). I realize that these are perfectly reasonable behaviors for the function, but would it not be possible to append a unique number to the end of each field's name (perhaps with some delimiter, like "variable_name - Number"), so you don't run into more uniqueness issues? This would fix both problems. As this would make the config file a little less readable, you could have a boolean input to the function which specifies whether or not to "force variable name uniqueness."
  • Create New...

Important Information

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