Limit entry of minimum field width

[JB]

Add a limitation for the minimum field width for numerics.

The maximal accepted value should be limited according to the format and the display style of the numeric. For example 2 for a U8 with hex display.

Currently, this missing limitation can lead to confusing code/display. For example, with a minimum width of 4 and "Pad with zeros on left", above numeric will have a "U16 look".

A particular thought would be needed about how to adapt the entered value when the format or the display style changes.

Not obvious. The cure could be worse than the disease !

What do you think about this idea ?

[Intaris]

I don't see why it shouldn't be possible to display an U8 as a 4-byte Hex.  You can't actually ENTER a number greater than 255, so it would behave as an U16 with a max value of 255.

Whether it makes sense of not is a different argument, but prohibiting it serves no real purpose.

[altenbach]

In my opinion, "pad with zeroes" to the correct data size should be the default for non-decimal formats (hex, binary, etc.). Whenever I use one of these display formats, I always pad with zeroes. I cannot remember a single exception!

Not sure what should happen if the programmer changes the represention later. Maybe the format should adapt only if the display was at the default for the old datatype.

I don't like hard restrictions for formats. We should still be able to define any lenght, independent of datatype.

[Manzolli]

I understand that this would be applicable only to integers being showed as Hexadecimal, Octal and Binary, right?

[JB]

---

Manzolli a écrit :

I understand that this would be applicable only to integers being showed as Hexadecimal, Octal and Binary, right?

---

Yes. This idea arose while writing a VI with Join Numbers and Split Number functions to do some logic on the words and bytes of an U32.

For example, if you make a copy of an U16 constant (displayed in hex with a minimal with of 4 and pad with zeros on left) and change its representation to U8, it will appear with two superfluous 0 which are confusing.

---

Altenbach a écrit :

In my opinion, "pad with zeroes" to the correct data size should be the default for non-decimal formats (hex, binary, etc.). Whenever I use one of these display formats, I always pad with zeroes. I cannot remember a single exception!

---

I fully agree.

[JB]

I understand that this would be applicable only to integers being showed as Hexadecimal, Octal and Binary, right?

[JB]

In my opinion, "pad with zeroes" to the correct data size should be the default for non-decimal formats (hex, binary, etc.). Whenever I use one of these display formats, I always pad with zeroes. I cannot remember a single exception!

[Manzolli]

@JB The width limit should be limited to the size of the type. Ex: U16 in Hex -> 4, U8 binary -> 8.

A default option, which matches the exactly width and padded with zeros (@altenbach) would be nice.

Kudos!

[Intaris]

I agree fully with changing the default behaviour to include zero padding at the correct length but I'm still against any hard limit based on datatype.

[Manzolli]

@Intaris Why somebody would need more places than the amount that data type can hold? 

[RavensFan]

Because they might want it to appear differently to the user than what the datatype defines?

[Manzolli]

Convert to a bigger type. Ex. an U8 Hex (two chars) that you want to look like a U16 (four chars) Hex: just convert to U16 before you shou it. In this case the first four chars will be always zero.

If you want more (can't imagine why) add a string of zeros (or anything else) using Format Into String.

[Intaris]

If you want more (can't imagine why) add a string of zeros (or anything else) using Format Into String.

Well why not just allow it on the formatting page for the control then.... Just because I have no need for something, doesn't mean that nobody should bea ble to use it.

What if you have several fields presented to the user and some are U8 and some are U16 and others are U32.  It would be nice to be able to display all of them the same so that the user doesn't have to KNOW that they're different types.  I fail to see the rationale behind PROHIBITING the option to display an U8 with 4 or 8 hexadecimal digits when the main problem is clearly the default settings.