How to format a number with an implied decimal
-
I didn't vote a one. I was given the choice of Yes or No was this answer helpful. I selected no. I didn't even realize I was voting I was just answering a yes or no question. Thanks I will look at your suggestion. BTW Your answer didn't have the Yes or No question.
smesser wrote:
BTW Your answer didn't have the Yes or No question.
That's because mine was a General message and not an Answer. Take a look at the Message Type for this.
Deja View - the feeling that you've seen this post before.
-
Yes, that works but not under the contraints I layed out in my question. The code doesn't know where the decimal is implied or not. If I used your solution it would be right if for this client as he wants an implied decimal but wrong for everyone who doesn't want an emplied decimal point. I am looking for a workaround to not have to pass in either the decimal is implied or not hense my question about how to solve this via applying a format.
smesser wrote:
not under the contraints I layed out
Which are fairly silly. Why take a decimal, convert to string, convert back to decimal, and then convert back to string again? Why wouldn't the caller simply use
(val * 100.0M).ToString ( "000000" )and be done with it? What benefit would your method provide? -
That, can be done as well but then your adding code to the UI part of the tool that will be used by possibly one client on only one type of field. I know I am being picky. Currently an item that can be written to a flat file has the following options: Field: Length: 10 Type: (float, int, etc) Format: 0.00 Padding: Space Padding Side: Right Default Value: None If I were to add a new field Implied Decimal It would only apply to one type of all the types and therefore essentially a hack, in my opinion. I realize that if the client can't fix this on his end I may have to put in a hack, but I am trying to leave that as a last resort.
It is quite common to have "implied decimal" in an interface file, so it's not really a hack. You should not need to have a new field, just need to make your tool more flexible in configuring the format of various numeric values (rates, amount, exchange rate).
-
smesser wrote:
not under the contraints I layed out
Which are fairly silly. Why take a decimal, convert to string, convert back to decimal, and then convert back to string again? Why wouldn't the caller simply use
(val * 100.0M).ToString ( "000000" )and be done with it? What benefit would your method provide?The contrains aren't silly they are provided by the client. My problem comes in trying to make a tool generic enough to provide all clients with their needs. Again this method would work if all clients wanted to use an assumed decimal point. In the end I ended up using the format string "000000%" which multiplies by one hundred thus given me the assumed decimal place. Then in my ProcessNumber method I remove the "%" if it exists. The "%" will only exist if I am using the assumed decimal approach and I can still use standard formatting for all clients. Problem solved.
-
It is quite common to have "implied decimal" in an interface file, so it's not really a hack. You should not need to have a new field, just need to make your tool more flexible in configuring the format of various numeric values (rates, amount, exchange rate).
Your probaby right. However, I was trying to stick with the standard string formatting options. In the end as I noted above I did the following: I ended up using the format string "000000%" which multiplies by one hundred thus given me the assumed decimal place. Then in my ProcessNumber method I remove the "%" if it exists. The "%" will only exist if I am using the assumed decimal approach and I can still use standard formatting for all clients. Problem solved.
-
Your probaby right. However, I was trying to stick with the standard string formatting options. In the end as I noted above I did the following: I ended up using the format string "000000%" which multiplies by one hundred thus given me the assumed decimal place. Then in my ProcessNumber method I remove the "%" if it exists. The "%" will only exist if I am using the assumed decimal approach and I can still use standard formatting for all clients. Problem solved.
-
Just pray that the system doesn't use currencies that has no "cent", ie Won, Dong, Yen. ;)
Yeah, I took that into consideration, the amounts are always even dollar amounts and always US currency. thanks
-
The contrains aren't silly they are provided by the client. My problem comes in trying to make a tool generic enough to provide all clients with their needs. Again this method would work if all clients wanted to use an assumed decimal point. In the end I ended up using the format string "000000%" which multiplies by one hundred thus given me the assumed decimal place. Then in my ProcessNumber method I remove the "%" if it exists. The "%" will only exist if I am using the assumed decimal approach and I can still use standard formatting for all clients. Problem solved.
:wtf: As long as you have the "000000%" format, why not just use it and not bother with this method? I still see no point for this method. What benefit does it provide? What's the point? I suspect you're doing something upstream that you shouldn't be.
-
:wtf: As long as you have the "000000%" format, why not just use it and not bother with this method? I still see no point for this method. What benefit does it provide? What's the point? I suspect you're doing something upstream that you shouldn't be.
The point is that the format specifier "000000%" multiplies by 100 and adds the percent sign. So, given 15.00 the result of applying the above format string yields 001500%. The percent sign is undesirable and needs to be striped out. So the method I mention always strips out the % if it exists as I will never need to send a percentage. So, I have accomplished my needs by still allowing standard formatting to be used. I could have created a custom format specifier "000000i", and then in my number processing method look for i and then use implied decimal formatting.
-
The point is that the format specifier "000000%" multiplies by 100 and adds the percent sign. So, given 15.00 the result of applying the above format string yields 001500%. The percent sign is undesirable and needs to be striped out. So the method I mention always strips out the % if it exists as I will never need to send a percentage. So, I have accomplished my needs by still allowing standard formatting to be used. I could have created a custom format specifier "000000i", and then in my number processing method look for i and then use implied decimal formatting.
Yes, I see that, but what I still don't understand is why you are doing
**decimal.Parse ( d.ToString() )**.ToString ( "000000%" ).Replace ( "%" , "" )whend.ToString ( "000000%" ).Replace ( "%" , "" )should be all you need. If the calling routine has the format string, why doesn't it simply use it? Why do a bare ToString and then call this method... which first undoes the ToString? Why not at least have this method take the decimal directly rather than a string? -
Yes, I see that, but what I still don't understand is why you are doing
**decimal.Parse ( d.ToString() )**.ToString ( "000000%" ).Replace ( "%" , "" )whend.ToString ( "000000%" ).Replace ( "%" , "" )should be all you need. If the calling routine has the format string, why doesn't it simply use it? Why do a bare ToString and then call this method... which first undoes the ToString? Why not at least have this method take the decimal directly rather than a string?You have assumed that I get the number as a decimal. I get all the values as a string and also their type. I also wanted to be able to default to "0.00 if no formatting was supplied as most client are fine with that format. 1. I parse to decimal as I get it as a string. 2. I default to 0.00 if no format is given 3. I apply the formatting 4. I remove the % if exists 5. I return it as a string since if will be written to a flat file. If the calling routine did the work and then I need this functionality some where else then I have to maintain multiple copies. Maintaining the code in a method allows me to for example default to 0.00 Besides at this point we are trying to impose our coding style on each other which is fruitless. I appreciate your ideas but you haven't raised any points that help me solve my problem any better.