Annoying "feature": format strings with a space - failure to update

[Tournifreak]

All,

This is something that's bugged me for a while. Has anyone come up with a solution?

Create a numeric control with a space in the format string, so you can have a space before the units (in this case, "A" for "Amps"):

Highlight the numeric part of the control, plus the space, thus...

...the control fails to update.

I've always found this very easy to do by accident and it's really annoying to end users who can't figure out why the controls sometimes don't update.

Any easy fixes out there?

Jon.

[Tournifreak]

sorry...

that bit after the 2nd picture ought to say, "Type in a new value...the control fails to update."

[billko]

---

@Tournifreak wrote:

All,

This is something that's bugged me for a while. Has anyone come up with a solution?

Create a numeric control with a space in the format string, so you can have a space before the units (in this case, "A" for "Amps"):

Highlight the numeric part of the control, plus the space, thus...

...the control fails to update.

I've always found this very easy to do by accident and it's really annoying to end users who can't figure out why the controls sometimes don't update.

Any easy fixes out there?

Jon.

---

I suspect that is because the format you are using makes it not a number any more.  It becomes a string.  If the control cannot interpret the inpute as a number, it discards it.

One solution is leave the units off the number and specify the units in the label.

[mikeporter]

So you have a numeric control that is formatted as shown, but when you type in a new value it doesn't appear in the block diagram, is that correct? Well one problem is that a numeric control won't pass its new value to the block diagram until after it loses focus. Since the entire contents is continuously selected, the control never loses focus, so the input never updates.

You will see the same/similar issue if you create a dialog box that contains a numeric field. If you type in a new value and press the button to read the control without first clicking outside the control the code will not see the changed value because the numeric control doesn't lose focus until after LV has responded to the mouse click. The solution (in that situation) is to force the control to lose focus before the code responds to the mouse click.

Mike...

[Tournifreak]

---

@mikeporter wrote:

So you have a numeric control that is formatted as shown, but when you type in a new value it doesn't appear in the block diagram, is that correct?

Not really. The problem is a FP effect. I think Bill is closer to it, but as far as I can tell it's a bug really. LV ought to be able to handle valid numeric inputs if it gives you the option to format the control in that way.

I could do as Bill suggests and put the label in the caption, but then there's big alignment issues. ie. How do you get the "A" to always be at the end of the numeric bit, even if the space used by the numeric varies.

[Darin.K · Accepted solution]

I remember reading about this before, but I just can't seem to find the link at the moment.  I prefer to right-justify the numbers in the control, simply select the text and use the font pulldown.  With right-justified text it is easy to use the caption or free label for the units.

[mikeporter]

Well then I guess you need to specify exactly what you have to do to duplicate the problem. I am running LV2012 and it works exactly as I would expect. Remember that you are telling LV the format to expect number in. You are telling it you will be inputting a number, followed by a space, followed by the letter A.

If you don't enter data in that format, LV will not accept it - and it shouldn't You didn't enter data in the format that you said you were going to use, so LV sees a input error and doesn't accept the change - which again is exactly what it should do.

Mike...

[Tournifreak]

I think DarinK might have the best solution so far. Do others think it's a bug?

Have a look at the little vid (zipped, attached) to see the behaviour.

Jon.

[mikeporter]

Exactly as I stated. You did not enter the data in the format you told LV you were going to use, so LV rejected the input. This is not a bug - it is how LV should work. Look at it this way, do you really want LV to be deciding what you or one of your users really meant when a value was entered incorrectly.

Mike...

[Darin.K]

I don't think it is quite as cut-and-dry as Mike portrays it, there are clearly some grey areas in this feature/hack.  If you put '%f A' for the format string, then 1.2 A or 1.2 B or 3.3 X are all valid inputs as well as 2.0+space.  Once you add a custom suffix to the format string all of the usual filters are removed (normally you can not press say 'x' into a numeric), this alone makes it annoying in my book (for a control at least).  Not to mention the SI suffixes, hex digits and other considerations.

If I were to create this feature I would do the following: scan the input for the longest string which makes sense as a number.  Keep the number, toss the rest, then format the number using the format string.  This way 1.2x would be interpreted as a value of 1.2 which could then be formatted as you wish.

Since it operates neither the way I would like nor the way Mike describes, I would avoid this for controls as it is basically a hack with a lot of inconsistent behavior.