Recommended Posts

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?

Share on other sites

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.

Share this post

Link to post

Share on other sites

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.

Share on other sites

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.