Hi All.
I have a powertable on my window that the user can edit a cell.
This is a touchscreen environment so I have the numeric keyboard pop up.
How can I stop the additional precision being shown when the operator types in a number?
Example. My operator wants to type 2.355
pressing 2 =>2
pressing . => 2.
pressing 3 => 2.299999952316284
pressing 5 => 2.3499999046325684
pressing 5 => 2.3550000190734863
Its very confusing…
Regards
Dave Rigby
thanks.
so what is different? As you can see from my screenshots I am not getting that behavior.
Are you popping from a powertable cell?
Is there some additional setting I can tweak?
Regards
Dave Rigby
What version of Ignition?
I did it from a button. The place from where you call the script should not be relevant.
Tweaks? not really. The only thing you can do is set the keypad to int or double mode by giving a initialValue the same type you wish.
Version is 8.1.1 (b2020120808)
This is only an issue for the powertable (that I know of), numeric input works as I would expect and as mentioned by jespinmartin1
.
The rows in the powertable are generated at runtime by script
newRow = [id, item, description, lotNumber, expiry, 0.0]"
event.source.parent.getComponent('Batching_ptbl').data = system.dataset.addRow(event.source.parent.getComponent('Batching_ptbl').data,newRow)
Touchscreen mode is enabled in project properties so no option to pass int or double.
As far as I can see there is no place to define the cell as float or pass any options to the popup.
Regards
Dave Rigby
I’m pretty sure I’ve asked this question before and it ended up being a “bug” (or rather an unwanted feature) where the keypad wasn’t being passed any display formatting so it just used the most precise display it can, which for floats is not very intuitive for operators when they see a value they enter become something very close to what they wrote, but not what they wrote. Maybe it’s fixed in a later version? Pretty sure @PGriffith gave my answer before (but I could be wrong)
Thanks Nick.
That’s disappointing (it being a ‘feature’)
I will have a play with the latest build to see if it is resolved, there may be an opportunity in the next shut to “upgrade”.
In the meantime the operators will need to suck it up - or I can make the input grams instead of kg :o(
Regards
Dave Rigby
I call it from a power table and got exactly the same self result as before. I'm testing on version 8.1.7.
Aren't you using system.gui.showNumericKeypad(initialValue)? Even in touchmode enable, the client just don't call a keyPad when you tap a cell on the table. How are you even doing that haha? The only way is using script with function mentioned before.
Suggestion. Get the backup file, prepare a dev environment, upgrade, check if your result are equivalent and probe is a problem with the version.
From the script above, I can't really tell from where you're calling the keyPad, share the full scripts and used methods.
If you are using the adding a row idea, I don't see a reason to call the keyPad beside editing a value from the power table, right?
Here is my testing (Not have recorder)
Step 1, choose a cell and tap:
Thanks Jonathan.
I have another customer site running V8.1.7 - I did a quick test and got the same result as my first post.
However.......
It looks like the solution is to change the column definition to double instead of float.
I went back to my v8.1.1 customer, made the column double and presto... only the decimal places the operator enters are shown.
Thanks for all the help, appreciate the extra eyes on the problem.
[Edit]
I have touchscreen mode enabled on startup, the cell is marked editable, when the operator clicks the cell the input screen pops up
[/Edit]
Regards
Dave Rigby
I was going to mention this in my first reply, but thought I was just going crazy that time. I do tend to use double instead of float though for reasons you reminded me of. I've never actually checked the difference between the two..
Double, as the name implies, has double the precision 
In practice, IEEE-754 distributes the range of values it represents ‘well-enough’ across human domains - so there’s a lot of values closely packed together at the lower end, and a much larger distance between values at the upper end. However, it’s still an approximation, so especially with 32-bits, there’s many gaps.
E.G compare 0.01,
in float: IEEE-754 Floating Point representation explained
vs double: IEEE-754 Floating Point representation explained
0.01 can be exactly represented in 64 bits, but not 32.
However, there are still (infinitely!) many gaps in both sequences, by definition. It’s just that 64 bits is a whole lot more range to fill.
As for the touchscreen keyboard itself - I did file an issue when Nick first brought this up. It’s still sitting in our backlog; we do plan to improve things here, but I can’t provide any timeline.
Ah, no. It cannot be exactly represented as a binary fraction, no matter how many bits--it repeats. User interfaces just make it look that way, since double has way more significant digits that any UI wants to display.
Okay, fine, it’s not exact
It’s really easy to tell: Turn it into a fraction. If the denominator is not a power of two, it will repeat in binary. (Just like decimals repeat when the fraction’s denominator has factors other than two and five.)
