Make .NET / LabVIEW type conversion configurable.

[TylerDurden]

Hi,

what does the community think about configurable automatic type conversion between .NET and LabVIEW? We need to deal with a .NET API for a sensor which handles system time with nanoseconds since the 16th century. Don't know why they're doing this stuff.

To set the appropriate time you have to substract two .NET DateTimes. Everybody will know this will look like in LabVIEW.

You will have to use a method of the object to substract this. Now you're using DateTime.Substract. This means in LabVIEW.

Here it would be nice to have a checkable item in the right-click run-time menu for the invoke / property node to select or deselect the automatic type conversion so that the Substract() method would accept a DateTime class and not a LabVIEW timestamp.

Hope the idea is clear enough. I've checked the idea forum for this entry but didn't found it. If so, don't shoot me for a double post.

Tyler.

[Felmer]

This is a great example of the mentioned problem. In .NET a timestamp is defined as time in seconds since year 0. In contrast LabVIEW uses the time in seconds since 1904. So you can´t convert both timestamps in any case correctly.

The mentioned .NET method DateTime.Subtract expects a System.DateTime object as parameter. The LabVIEW invoke node converts the expected System.DateTime object to a LabVIEW timestamp. This automatic conversion may lead to the problem that is not possible to correctly execute the method with the given parameters because they are not compatible anymore.

One Solution would be that we are able to select if the parameters are automatically casted to LabVIEW native data types or if the nodes use the appropriate .NET objects. The default value for this selection should be the automatically converted LabVIEW data type as it is now.

Are there any pitfalls to this suggestion which should be considered?

[Darren]

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