The Table View window is not showing you the correct value. The StringFormatter really does return 0.110 and the Logger transformer proves this.
When you write to Excel, the column is a number, and a number column in Excel automatically trims trailing zeros. To fix this you must either:
Use a String column type in the FME schema definition
Set up an Excel file in which the number is defined as 3 decimal places, and use that as the template in FME. Then a number type shows the correct 3 places.
You can use the rounder with 3 places and then a StringPadder with desired length as 3, right pad, and 0 as the padding value. That will append a 0. But, the -0.3f should work.
Yes I can modify the parameters in Excel and It works but FME must handle it.
My purpose it's manage and configure data with FME and not Excel to simplify the work.
The other value like 335.670 are formatting when we want (Print Screen 1)
The print screen 2 show the act of formatting in excel and the result (ex 0.970 or 6.980).
Is it possible, it's a bug in FME?
Print Screen 1
Print Screen 2
It's difficult to say if it's a bug, because it works for my tiny test case. Are you able to post a minimal workspace here that demonstrates the issue?
You can use the rounder with 3 places and then a StringPadder with desired length as 3, right pad, and 0 as the padding value. That will append a 0. But, the -0.3f should work.
Hello,
Sorry, your solution doesn't work with my Workspace and Data :(
I'm starting to suspect that FME is trying too hard to be intelligent and preserve the input float datatype, so that when it sees 1.110 cast as a float, it displays as 1.11, because realistically, that's what it is.
Try chaining two StringFormatters together, the first one with format string "s" to force the float to a string-like representation, then the next with "-0.3f" for padding.
I'm starting to suspect that FME is trying too hard to be intelligent and preserve the input float datatype, so that when it sees 1.110 cast as a float, it displays as 1.11, because realistically, that's what it is.
Try chaining two StringFormatters together, the first one with format string "s" to force the float to a string-like representation, then the next with "-0.3f" for padding.
Wonder if it could be related to the attribute type preservation in 2020?
I'm starting to suspect that FME is trying too hard to be intelligent and preserve the input float datatype, so that when it sees 1.110 cast as a float, it displays as 1.11, because realistically, that's what it is.
Try chaining two StringFormatters together, the first one with format string "s" to force the float to a string-like representation, then the next with "-0.3f" for padding.
The Table View window is not showing you the correct value. The StringFormatter really does return 0.110 and the Logger transformer proves this.
When you write to Excel, the column is a number, and a number column in Excel automatically trims trailing zeros. To fix this you must either:
Use a String column type in the FME schema definition
Set up an Excel file in which the number is defined as 3 decimal places, and use that as the template in FME. Then a number type shows the correct 3 places.
The Table View window is not showing you the correct value. The StringFormatter really does return 0.110 and the Logger transformer proves this.
When you write to Excel, the column is a number, and a number column in Excel automatically trims trailing zeros. To fix this you must either:
Use a String column type in the FME schema definition
Set up an Excel file in which the number is defined as 3 decimal places, and use that as the template in FME. Then a number type shows the correct 3 places.
I hope this is helpful.
Hello Mark
Thank for your answer.
The value is Always viewed as 0.11 in FME but I set up a Template Excel File where the number is defined as 3 decimals places and it's good.
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.