"Cluster Variant to Data" when some values are missing

[Antoine Chalons]

One thing that I really like about the OpenG "Read Section Cluster.vi" is that if some values are missing form the INI file it doesn't matter, the default value for the corresponding elements will just have the default value.

 

I was wandering if it would be a good idea to have the "variant to data" behave the same way, instead of returning an error 91, shouldn't it try and see what does match between the data available in the variant and the data type passed to the "Variant to Data" primitive?

 

I find it not easy to explain what I mean so here's an example :

 

 

And here's the code.

 

my variant to data.zip

 

I know there are some limitations, not all data type are supported (refnums, arrays, waveforms, etc...) and unique names are required.

 

If someone wants to know when this can be useful, the answer is this : when you develop custom steps for VBAI and you want to add some parameters without losing all the ones that were already there.

Maybe there are other use cases for this?

 

Any feedback will be much appriciated.

[hooovahh]

I think something like this could be in the idea exchange but would affect previously made VIs and their functionality enough that I don't think NI would implement it.  Right now if I have an error in the Variant to Data because of a type mismatch, the value I get out is the default value for the data type.  I think it should be the value wired into the Type terminal (similar to OpenG).

 

Secondly what your VI is doing is slightly different (correct me if I'm wrong).  It tries to match the data types based on the label name, not the data type it self.  At the moment the Variant to Data doesn't care about the labels at all.  I can have 2 clusters that have different labels, but the same data and the conversion will work properly.  If I had 2 labels swapped (change bool and num2) then the data won't be able to be set, and it won't be listed in the "Missing" array because it found matching labels.

 

Neat functionality but I don't have a use for it at the moment.

[Antoine Chalons]

I thought about posting this on the idea exchange, but I could only think of one use case and it's quite small so I don't think many people would be interested.

I also don't think the "variant to data" primitive should be modified to match what I did, as you pointed casting to a specific type and matching by name are really not the same thing. Getting an error on type mismatch is I also what I expect from the primitive.

 

The way I put it "I was wandering if it would be a good idea to have the "variant to data" behave the same way" was not exactly what I wanted to say, in fact it's another primitive that would be nice, I don't know what to call it... maybe "label based cluster variant to cluster match" but that doesn't sound right...

The point in posting this was more to see if there was any other use cases that I hadn't thought about. The code posted is useful for my use case and really that what matters.

 

Thanks for your comments!

[JackDunaway]

Generally, I like what you're suggesting.

 

I don't have a particular opinion on Variant behavior when deserializing/validating, but I strongly agree for other stringly-typed composite data structures (XML, JSON...).

 

The reason I don't have a strong opinion about Variant behavior is we're typically talking about intra-application communication; the reason this is so important for XML/JSON is that now we're talking about interoperability beyond an application instance, where strict validation is oftentimes more of a hindrance than an asset.

 

For those participating to the LabVIEW 2013 Beta, there's a discussion on that forum about this topic -- search for "validation on deserialization" and weigh in.