Consistency using dot [.] for decimals

Changing the amount of the [Statement Balance] in [Bankreconciliations] I have to use the dot [.] to get decimals.

Changing the amount of the [Unit price] in for instance a Purchase Invoice I need to use a comma [,] to get the decimals.
(In the example you see what happens when using a dot).

It would be nice if throughout the program the dot, including the Numpad dot could be used for the decimals, or make it interchangeable somehow.

The only thing we can see in your screen shot is the result—a dot. We cannot see what you typed to obtain that. So it is not clear what you think the problem is. Are you complaining that you typed a comma and got a dot? Or that you typed a dot and did not get a comma?

It also is not clear whether you used the dot on the main keyboard or the number pad in each case (if you typed a dot).

I also wonder if you are using the software hack you wrote about a few days ago to substitute commas for number pad dots? If you are, maybe it did not work as you hoped?

Allright, hopefully these images will show you what I mean.
First, the layout of the keyboard I am using. (In these examples I don’t use the Autohotkey hack).
Language Dutch, Keyboard US-International
keyboard_used

The amount I want to put in is: 123,45 onehundredtwentythree comma fourtyfive

Let us first have a look at [Bankreconciliations].
If I use the normal dot or the numpad dot when entering 123.45 in [Bankreconciliations] like this:
Using_dot_bankreconciliation

Then this is the result:

If I use the normal comma when entering 123,45 in [Bankreconciliations] like this:
Using_comma_bankreconciliation

The result is:

Now let us switch to [Purchase Invoice].
If I use the normal dot or the numpad dot when entering 123.45 in [Purchase Invoice] like this:


The result in the field [Amount] is 12.345,-.

If I use the normal comma when entering 123,45 in [Purchase Invoice] like this:


The field [Amount] shows 123,45.

Based on this I come to the conclusion that there is an inconsistency when entering a value with decimals.

Thanks. That helps. I honestly don’t know if that’s an operating system problem, a Manager problem, something to do with whatever library software Manager uses for number preference conversions, or something else. I’ll put this into the bugs category to be sure @lubos sees it.

@ries could you check the latest version 20.7.96 to see whether it fixes your issue?

According to my tests with v 20.7.97, this is not resolved, @lubos.

With number format set to:

Screen Shot 2020-07-19 at 10.38.56 AM

Using either the standard or number pad dot for a decimal separator upon input of the number 123,45, the dot is ignored as a decimal separator and the thousands separator of the preference setting governs the Amount field:

Screen Shot 2020-07-19 at 10.35.14 AM

After updating, you can verify that the decimal separator has been ignored:

Screen Shot 2020-07-19 at 10.35.43 AM

And the View screen shows the incorrect value:

Screen Shot 2020-07-19 at 10.35.29 AM

Only if a comma is used for the decimal separator upon input is the value stored and displayed correctly:

Screen Shot 2020-07-19 at 10.44.36 AM => Screen Shot 2020-07-19 at 10.44.53 AM

So I am moving this back to bugs. (There is a possibility I misunderstood what you intended the fix to accomplish. But I thought your goal was to enable the number pad dot to be used as a decimal separator during input.)

If your decimal separator is set to comma in Manager, then Manager will accept only comma as your decimal separator. That’s how it should be. It cannot accept both dot and comma interchangeably because dot can be used as a thousands separator.

As far as numpad goes, pressing dot key will actually produce comma character if you are using appropriate keyboard layout. But this should be configured at operating system level.

Understood, @lubos. This makes sense to me. From your earlier post, I thought you were aligning with @ries and making the number pad dot function as a comma under relevant number format preferences.