Maintain Consistent Datatype for Property Nodes on Numerics

[JackDunaway]

I have noticed that Property Nodes for certain numerics do not properly store Range Properties as the native datatype of the control, but rather stores them as DBLs. I have attached the screenshot to illustrate my point:

Notice the first Numeric's datatype is a DBL, and therefore you see no coercion dots for the Range Properties or the Value Property. The bottom two examples show I32 numerics, which have the proper datatype for the Value Property, but have the wrong DBL datatype for the Range Properties.

I propose that the Range Properties should reflect the datatype of the Numeric, just as the Value Property does!

(This may affect other Property/Invoke Nodes besides Range... please list any other datatype inconsistencies you may find in the comments.)

[tst]

I definitely agree in principle (so I voted), but this is not something I would want a huge amount of developer time wasted on.

[AristosQueue (NI)]

Unfortunately a change like that would possibly break existing VIs. The underlying storage for range/increment is a double for all the numeric types regardless of the type of Value and someone may have stored double values in there and be expecting to retrieve them. So the underlying storage cannot change, which means at most, the API could change. Deprecating out the existing properties and creating new type-specific properties is possible but I doubt the utility. 

Not the first time I have wished for a time machine to retroactively change an API in its first relase. 🙂

[Darren]

National Instruments will not be implementing this idea.