Variant to Data Type

[P@Anand]

I am posting the idea believing that it has not been posted yet( I have searched for this thread in Idea exchange)

• While using the property node (and also in some other functions) we some times get the output as Variant. To convert the Variant to the data type required we need to convert the variant to the data by wiring the data tyoe to the respective terminal.

• It would be handy to have an option straight away to conevrt the variant to the respective data type. I have attached the snap shot of the idea. Encourage if it is good. Regret if it has been already posted.

Available Method

Proposed Method

[Mr._Jim]

Not a bad idea...  This could definitely save diagram space and contribute toward simplicity.  I have a question, though: Do you mean to suggest this only for common data types such as the ones you've listed?  That would imply that you'd still have to use "variant to data" for complex cases like OLE objects, clusters, arrays of bizarreness, and myriad other unpredictable cases.  An idea to cover these cases might be to include a data type terminal on the left-hand side of the property node.

Jim

[AristosQueue (NI)]

I've got some hesitations both about the original idea and Mr. Jim's suggested amendment.

The original idea would fold all the error behaviors of "variant to data" into the property node. Currently, all properties in a single node will read until the first one hits an error, and the ones after that point return default values. You'd be adding more error checks to that property that are currently the next node in line. How desirable is that? After all, the property itself does have a valid value. I wouldn't want to create an exception situation where "reading this property triggers an error but we keep processing the other properties anyway."

As for the amendment:

> An idea to cover these cases might be to include a data type terminal on the left-hand side of the property node.

As soon as you start needing additional inputs, you've got a method, not a property. You wouldn't be able to grow the property node unless you could specify a different input value for each variant output. That starts getting syntactically messy -- either you have them on different lines (in which case growing becomes a "grow by two" operation) or you have them on the same line and then it becomes harder to read whether you're reading or writing the property.

In general, I don't see the conversion node being separate as a significant detraction, so I'm loathe to consider any proposed improvement to the system unless it is a slam dunk "wow, that's better" type of change.

[Mr._Jim]

Yeah, I'm with you (Aristos).  I don't see it as much of an improvement over the variant to data function, but I thought I'd ask some questions to see if I was correctly understanding what was being proposed.

[P@Anand]

Yes i too agree with you Aristos...I was thinking to have all the cases (Arrays and Clusters) but they are not added (Not able to figure out how those can be given effectively) Mr.Jim... I would have given kudos to your Explanation if it was a discussion froum reply... I'll think on that... Thanks you guys...

[Darren]

Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.