LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Darin.K

Autoadapt numeric constant radix plus automatic radix conversions

Status: New

I would like to introduce a little shorthand for creating numeric constants with non-decimal radix.  New constants should be able to autoadapt for radix, much like they do for type:  Drop a constant, enter '0x20' or 'x20' to get a constant with Hex radix (visible!), and the proper value.

 

In addition, it would be nice if automatic conversions would take place if radix specifiers are entered into (non-hex) constants (or controls).  For example, entering '0x20' into a numeric control with decimal radix should result in a value of 32 being entered (auto conversion).  Hex is an exception, obviously, because b and d are already valid.  The other radices have no such problem.

 

ConstantRadix.png

8 Comments
crossrulz
Knight of NI

One of the keys here is that the radix becomes visible when using a non-decimal radix.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
SteenSchmidt
Trusted Enthusiast

Since I vote for radix always being on when non-decimal display is selected, I think this idea should be about automatic conversion only. There are two different ways to convert that we must choose between:

 

a) Let the entered number dictate the display style of the constant/control.

b) Make the entered number convert into the current display style of the constant/control.

 

There are pros and cons of both;

 

You are the programmer after all, and should be allowed to dictate the display style by shorthand. But what if it makes more sense, documentation wise, that your numeric is displayed as binary (since your code is a heap of bit-banging and all other numerics around are displayed in binary for instance)? Shouldn't the preset display style be maintained in this case, but you should just be allowed to enter FFFFh as shorthand for a long string of 1's? So, what to do...

 

- Can we choose one or the other conversion type as better?

- Or can we define a set of rules when to do one and when to do the other?

- Or is it better that constants always lets the entered number dictate the display style, and controls/indicators always maintain their preset display style for instance?

 

/Steen

CLA, CTA, CLED & LabVIEW Champion
Darin.K
Trusted Enthusiast

My scenario is that the first value gets to dictate the radix, future changes only convert.  That is how I wish type adaptation would work. 

shb
Active Participant
Active Participant

Should this work in a control too?

Darin.K
Trusted Enthusiast

> Should this work in a control too?

 

I think autoconversion of numbers would be great in a control.  I am less inclined for them to autoadapt, could certainly be an option.

Dominik-E2
Member
Hooovahh
Proven Zealot

So I voted for this a while ago but I just found a new use that would make this even more useful.  Having paste into controls and constants also changing the radix and display type.  I had a numeric constant on the block diagram configured with decimal and I pasted in the text from my clipboard "0x20000000" and it set the value to 0.  What I think would have been nice is if it recognized it was a hex display, changed it to that type, and pasted in the 20000000.

Petru_Tarabuta
Member

+1. The Format Numeric QuickDrop plugin may help in the meantime: https://www.vipm.io/package/crossrulz_lib_format_numeric/