Results 1 to 7 of 7
  1. #1
    Join Date
    Nov 2003
    Location
    Europe
    Posts
    369

    Question Unanswered: percentage entry and input masks

    hm. this should be quite simple, do not know what I am doing wrong.

    I want to store a percentage as double with 6 decimals (= percentage with 4 decimals) in the table, but still the user entry should be like this:

    In the form the user inputs 0,02 (2%) as simply 2, then the app actually store the following: 0,020000

    When entering 2,01, the db stores 0,020100, etc.

    But when setting the form field to percentage and specifying , I am required to enter data as 0,02 , when I want to "talk in percentage, ie. 2,0 % = 0,020 as stored...

    How can I enter percentage values as whole numbers, then speifying percentage decimals with a comma, still not having to enter all the rest of the zeros when the last real digit is typed?

  2. #2
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1

    Re: percentage entry and input masks

    This one is a bit bizarre I must say.

    May I ask why you need to use commas instead of decimals?

    There's a few issues you're going to run into storing the numbers with a comma. The first is, you MUST store it as a string. There is no way to push a comma into a number. The second is related to the first, if you use these percentages in any sort of calculation, you're going to have to parse the string into a viable float before they can be used.

    I don't know your exact situation, but I'm guessing life would be much easier if you store the percentages with standard decimals and format them for display when needed.

  3. #3
    Join Date
    Nov 2003
    Location
    Europe
    Posts
    369

    Re: percentage entry and input masks

    Originally posted by Teddy
    This one is a bit bizarre I must say.

    May I ask why you need to use commas instead of decimals?

    There's a few issues you're going to run into storing the numbers with a comma. The first is, you MUST store it as a string. There is no way to push a comma into a number. The second is related to the first, if you use these percentages in any sort of calculation, you're going to have to parse the string into a viable float before they can be used.

    I don't know your exact situation, but I'm guessing life would be much easier if you store the percentages with standard decimals and format them for display when needed.
    As long as the language is set to a country that uses comma as the decimal symbol this should not be an issue. I think that is beside the point. Don't think about that, if you have an answer where period/dot is part of the solution then fine, I just want to know how I can let users type 16, and have the computer display 16%, but store 0,16 (or 0.16 for that matter - we are storing using commas now, in a numeric field, so that is not the problem).

    - when a user want to specify digits, for example (using american digit symbol, period): 25.56%, the user should only have to type 25.56, then have it displayed as 25.56% but stored as 0.2556. How do I do that? One issue is to store 4 or perhaps 6 digits, but without forcing the user to enter all the trailing zeros if there are no further information after for example one digit.

    Just now, I cannot seem to get around having to type .2556 - which is not convenient for the users, they want to type 25.56 .

    FYI: in the field specification on the table, it is a numeric field set to Double, with Percentage as format and 6 digits.

  4. #4
    Join Date
    Nov 2003
    Location
    Europe
    Posts
    369

    Question Re: percentage entry and input masks

    When I enter 16 - wanting 16.0% to be displayed and 0.16 to be stored, the result is that 1600,00% is displayed and 16.0000 is stored in the table. I think it is strange that the otherwise convenient percentage format option only works "one way"..., ie. displaying a stored or entered 0.16 correctly as 16%, but does not allow the storing of such result values directly from the user to the table.

    There must be a way to come around this unnecessary "limitation".

    An input mask is not really relevant here.

  5. #5
    Join Date
    Dec 2003
    Posts
    172
    I want the answer to that one also.

    Joe G

  6. #6
    Join Date
    Dec 2002
    Posts
    117

    Strange Way

    I would like to see that one accomplished as well.

    Can't we all just get along? Use the good ol' fashion "." PERIOD!

  7. #7
    Join Date
    Dec 2003
    Posts
    172

    my deleted post

    I had posted a solution but found the values did not enter reliably - hence the deleted post.

    JoeG

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •