Note quite. And, as an additional requirement I was stripping the decimal. 12345.1234 would yied "123451234". 12.0 would be "120" -123 would be "123-". This is the burden of working with the mainframe.
The more I thought about it, I had to force the function to pass the number of decimal places as an arguement. If the model that calls the function doesn't pass the correct number, the results will be unpredictable (often zeros).
I'd love to hear others solutions and ideas to get arround this though.
I'm close, but it's not perfect. "#.0" is the problem. Here's what I've got so far...
The value captured from the report is RptNum.
StrDec represents the decimal portion of RptNum, using:
The final Result field uses:
Hopefully this moves you ahead somewhat.
A pretty straightforward fix for the 12.0 case:
Trim(Str(Abs(Int(RptNum))))If(Len(StrDec)=0,"0",StrDec)If(RptNum<0,"-","+")[/code]But if you need more decimal places than just the single forced significant digit, "0" above, then you could perhaps add a runtime parameter for the number of sigificant decimal places to use, and then build a lookup calculated field named FillZero:
6 000000[/code]Etcetera, as needed.
A nice little Excel-like Repeat() function would have been good here, but that's not an option at the moment.
Then the formula above would become: