Confirmed in v3.6.  This preference has two completely different and unexpected behaviors.

what were you expecting?  this is not something people usually complain about.

BTW I think you are mistaken in blaming the "automatic decimal point" option, that is just for convenience.

The display of integer 125 as 125.00 should be independent of the automatic decimal point preference; the decimal places are set by the account's (and therefore usually the account commodity's) fraction. That's 100 for most real currencies (for a few, e.g. the Japanese Yen, it's 1) and 1,000,000,000 for some so-called cryptocurrencies. 

The automatic decimal point preference enables the automatic insertion of a decimal point according to the commodity's fraction, so if the fraction is 100 then the decimal is inserted between the second and third digits from the right (or the left in RTL languages). If you want to enter 125 dollars/euro/pounds sterling with that preference set you'd enter 12500 and the entry would be converted to 125.00.

The only possible unexpected behavior would be if unchecking the preference caused the display of 125.00 in an accuont with the fraction set to 100 to display as 125.

Does it?

First of all, please stop trying to argue with me.  I am doing you a service by reporting potential problems here.

I believe I was testing stocks with a fraction of "1" and that seems more relevant now.

And no, they are not independent.  When I enable automatic decimal point, all of my stocks ledgers are displayed like 125.00.

Additionally, for a stock fraction of 1000, any zero balance is normally displayed as "0" but then becomes "0.00" after enabling automatic decimal point.

Testing along this direction... if I trade "1" share with a price of "1" and a fraction of 1000, the ledger normally displays no decimal place in the Shares and Balance columns, but the Price as "1.0000".  When I enable automatic decimal point, the Shares and Balance columns both change to "1.00"

(In reply to Robert Chapin from comment #5)
> First of all, please stop trying to argue with me.  I am doing you a service
> by reporting potential problems here.

Please remember that GnuCash is Free software, developed, maintained, and supported entirely by volunteers. If you're doing anyone a service by reporting bugs it's to the other users, not those volunteers.

(In reply to Robert Chapin from comment #6)
> Additionally, for a stock fraction of 1000, any zero balance is normally
> displayed as "0" but then becomes "0.00" after enabling automatic decimal
> point.
> 
> Testing along this direction... if I trade "1" share with a price of "1" and
> a fraction of 1000, the ledger normally displays no decimal place in the
> Shares and Balance columns, but the Price as "1.0000".  When I enable
> automatic decimal point, the Shares and Balance columns both change to "1.00"

Thanks for clarifying.

For Info: the background to this goes back to adding machines and till registers before electronics which had a "00" key as well as a "0" but no decimal point.  People in accounting were used to keying "1" "00" for a whole dollar / GBP / whatever (Eur didn't exist) and this has persisted to this day on accountants desk calculators.

The "Automatic decimal point" should only affect money values at the moment of entry, i.e. shouldn't affect the actual amount that gets recorded.

Ah, OK.  Let's try this as a recipe.

Open a commodity account; I tested on a Stock.
With the commodity a/c visible Edit / Pref / Gen / tick Auto decimal and put 8 in the decimal places box.

It looks weird but I think the numbers are actually right.

Is that what you mean, RobertC ?  If so update the version to 3.7 above and understand that this is cosmetic and you sorta made it happen.

We are still talking about two completely different features being controlled by a single checkbox?

I'm not sure where Wm's going, but I see what you're saying about the display in the register changing with that preference and I agree that it's wrong. It shouldn't impact the display, only input.

I wouldn't say features.

The "00" entry behaviour is a hangover and I'm going to use this bug to propose it is removed, very few people that use it will be alive in two decades time and gnc users include people older than me :)

The other behaviour isn't worth crying about as the number of decimals *shown* right of the decimal point doesn't change the number.  Further, gnc actually uses fractions internally for some numbers [1] anyway.  I have updated this to 3.7 because it is live and to Hardware: All because I think it is hardware independent.

[1] RobertC: what is the decimal representation of 1/3 is the obvious example

JohnR: I'm thinking the "automatic decimal point" on entry is archaic (before gnc could have been conceived of) and not much used as evidenced by RobertC playing with it and us (for some value of us) discovering that it actually did something we weren't aware of.

I'm not familiar with the internals, but I agree with John's last comment. 
"1.00" is a hideous representation of a security that trades on a fraction that is not 100.  So this can't be working as intended.

While I agree that the option is surely obsolete I'm also sure that if we remove it someone will complain, perhaps even Robert: After all if he didn't want to use the auto-decimal entry then he wouldn't have bothered with the bug report, he'd have just left the option disabled.

So I've removed the option's effect on numeric display and left the rest alone.

Possibly.  I was going to try it and see if I can key numbers any faster without the period.  It may be useful if it works as advertised.

Oh, my.  You really don't read well do you, RobertC


I was going to say (to the world at large)

I'm happy with that.

My comment before our words crossed was

==
Yup, I'm suggesting we get rid of it altogether.  You can't have a problem with a mixed up function or feature that doesn't exist :)
==

So I'm hoping RobertC will have learned something about getting something done.