Make numeric display format auto-set to what you input

[Dominik-E2]

Instead of having to open the "Display Format" window everytime you want to drop a control/indicator/constant with a special format value (i.e. 2400000000 as 2.4G) make the control/indicator/constant automatically set to whatever format you put in. For example

Typing in 2.4G sets the Display Format to "SI notation".

Typing in 2.4E9 sets the Display Format to "Scientific"

Typing in 2400000000 sets Display Format to "Automatic formatting" etc

[Troy]

This would save so much time.  Constants on the BD is where this saves the time and makes the code easier to read.

I am with fabric on this.  I set the controls and indicators to specific display formating during edit time, but don't want them to change at run time.  So my vote is edit time only.

[Manzolli]

I think it should use the last user input format. As an option, Kudos!

[altenbach]

I still think this is a can of worms. Where should it end?

What if I type "3.500", should it automatically start formatting as %.03f?

What if I type 1e-2, should it start formatting in scientific?

What if I type "FF" into a decimal formatted integer numeric, should it start formatting in hex from now on?

What if I type 1.2 into an integer. Should the type change to DBL? (well, it does it for diagram constants already ;))

I think it will result in undesired outcomes in >50% of the cases and could get pretty annoying.

[Henrik_Volkers]

Simply keep the format of the value entered!!

LabVIEW is smart enough to 'get' the value, no matter what (valid) format for entering I use.

Why shouldn't it keep that format for a BD constant??                              Small adjustments like 1e-2 to 1E-2 are OK 😉

In an addition: If I enter a constant it shouldn't be truncated . If the programmer enters more decimal zeros in a constant, they should be displayed!!

For a numerical BD constant maybe one could enter the formating string..   like "%.03f:1" would give a "1.000" constant, but I prefer just to enter "1.000" and it would display like "1.000"

If I enter the samplerate constant "10MHz", would it be nice to see a "10M Hz" instead of "1000000" ?

AND:

If I create a constant in a BD it should ALWAYS show the Radix or display style

(Maybe there is already a ini key to configure that??)

There are 10 kind of programmers, ....

[tst]

> AND:

> If I create a constant in a BD it should ALWAYS show the Radix or display style

> (Maybe there is already a ini key to configure that??)

See this - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Automatically-show-descriptor-or-radix-for-non-normal-...

[altenbach]

> LabVIEW is smart enough to 'get' the value, no matter what (valid) format for entering I use.

The key word is "valid". Type FF into a decimal integer numeric and it will not understand.

[AristosQueue (NI)]

Henrik_Volkers: Type in 2E4... is that 20000 or a request to shift to hex notation?

[crossrulz]

I think we are somehow going to have to tell LabVIEW what we want.  Like put in "0x" at the beginning of our number to change it to hex.  2E4 should be taken as it does now, as a float.

[AristosQueue (NI)]

I want to comment on the original idea, then I'll come back to crossrulz post.

Let me say at the outset -- this is me as a LV user opposing this idea, not me as a LV R&D member. I'd want to do a lot more usability testing on this before I would weigh in on whether I think it is good for LV generally.

But for me as a developer, I would not want this change, nor would I want any one on my software team using code written with this change.

Dominik-E says that what LabVIEW currently does is bad. Why is it bad? As far as I'm concerned "2.4G" is useless. I had no idea what 2.4G is as a value. This isn't a joke... when I first saw this idea earlier this month, I had to go find out. I didn't know LV supported that notation. I thought it was a unit that we supported, like hz or ms. I'm glad that LabVIEW allows you the shortcut of typing 2.4G -- makes it easier to write code if LV can interpret what value you intend. But I'm equally glad that it converts that value into something that I can read. I think it is better to make as comprehensible-without-specialized-knowledge as possible. I know... many people don't consider unit magnitudes to be specialized knowledge. But it is. It is one extra layer of obfuscation. I don't immediately comprehend the magnitude difference between "2.4Mhz" and "2.4Ghz" -- if I see both in a document (or a diagram) I have stop and think about which one is larger. It's not intuitive to me... never has been. Three extra zeros? That I can see on a diagram and know that I'm dealing with two very different numbers.

The NeM notation is also problematic. I can't tell you how many times I have compared numbers wrong because I stopped comparing at the left-most digit and failed to even notice that letter "e" embedded in the middle of the string. It's like I'm playing some sort of visual test challenge: Quick, which one is largest?

• 435739459873249582734928734E342987349273094203  or 
• 535739459873249582734928734E342988349273094203  or 
• 43573945987324958273492873E4342987349273094203

If you explicitly want to flip your constants into SI mode, that's fine, but having the automode be one that is maximally accepting and then displays in the common form, easily comparable and usable if I copy to something else (like a calculator or other document) is exactly right, to me.

This ties into what crossrulz just posted: the magic 0x.The meaning of that is specialized knowledge for sure. Shall we also say that anything that starts with an explicit zero is octal (that's the convention in some text languages). Binary? And how do you switch back to decimal?

I think if you go that route then you end up needing to type something like

d16  or 16  (we'll take no character as implicitly decimal?)

x10

o20

b10000

But if you're going to explicitly do it by typing, why wouldn't you just set the ring and then type the number? Setting the ring happens once, whereas with typing you would have to keep typing that character out. Most of the time I'm not swapping a control or constant back and forth from hex to dec to bin repeatedly.

Overall, I really don't like this idea. I think it has some strong usability downsides.

I would like to see the radix ring made visible by default to make it easier for people to change which display mode they want -- that's an idea I can get behind. But the default being something that expands numbers? That's nice. And not having magic prefixes? That's also nice.

Back to speaking for LV R&D -- maybe the specialized knowledge is sufficiently common among LV users that it makes sense to do this. That's what I'd want to explore. But I know of at least one user* who doesn't like the change, so I wouldn't call it a slam dunk.

* myself 😉

[Henrik_Volkers]

AristosQueue,

Why is it bad? Because after entering a number in a VALID format into a BD constant (autoformat) , LV changes it into decimal or floating format instead of keeping the format just entered.

All examples you give above, assist the using of a meaningful format. (and that it should be indicated)

Here is another one:  13000000 feed into a power generator, or was it 130000000 ?? Which one is right??

13MHz no problem , 130MHz ... UUps might stop the airport 😉

Why LV (or you or LV R&D ) think he is smarter than the programmer, looking for a way to find a meaningful (in the context of the actual program/BD) format to write a constant into the BD.

And the point is that LV already allow us to enter a numeric BD constant in many different formats, so why not keep that format?

All that 'magic' prefixes and E formats are used because they assist readability   ... if properly used!