Nice concept, thanks Daniel.

But I don't know if LibreOffice should allow such behavior. It's only useful if you insert more numbers with decimal places than without.

In Tools > Options > Calc > Calculate there is a setting "Limit decimals for general number format" to fix a maximum number of decimal places. A new setting could be introduced similar to the setting in Microsoft Excel [1] with wording "Automatically insert decimals for general number format" with an identical number combobox.

Adding needsUXEval to get some input from the design team.

[1] https://fud.community.services.support.microsoft.com/Fud/FileDownloadHandler.ashx?fid=bfc35f10-67a2-4e7e-82a4-7847bf3092b6

Not a display setting, that would make no sense.

Rather, this would have to be an auto-format/auto-correct action. That is--as an aid to doing the _integer_ data entry; and to override "normal" numeric input.

Would expect that once entered, and a decimal place assigned, the number _must_ be handled as a numeric value and to take the number formatting otherwise applied to the cells.

Also, assume the auto-format/auto-correction would be activated against a selected column/row. But alternatively toggled globally to parse _any_ integer numeric data input.

And, what would happen if while the input mode is set against a cell (by row/column), one enters a floating point number with decimal? Assume it would revert to normal numeric input handling.

Finally, would the decimal auto-format/auto-correct position be applied counting from the start or from the end of input--or should that be settable.

Again this would be a data input formatting function--like using a "'" to set numeric input to be text.

In that context could see some utility.

Would be a dangerous setting for most users and useful for only a few (who are too lazy to press one key). Some corner-cases needs to be taken into consideration making the feature complex. I vote for WONTFIX. It's better realized via macro or per input sheet that is linked to another sheet showing the values of the first divided by 100.

I vote neutral - if that is allowed :p

(In reply to Heiko Tietze from comment #3)
> Would be a dangerous setting for most users and useful for only a few (who
> are too lazy to press one key). Some corner-cases needs to be taken into
> consideration making the feature complex. I vote for WONTFIX. It's better
> realized via macro or per input sheet that is linked to another sheet
> showing the values of the first divided by 100.

Hello, Heiko,

In my opinion, there's an error of thought. What, if you divide 1 by 100?

The described way to input numbers is very useful for accountants and tax advisors.

(In reply to Daniel Schunk from comment #5)
> In my opinion, there's an error of thought. What, if you divide 1 by 100?

Excel shows 0.01 when you enter 1.

(In reply to Heiko Tietze from comment #6)

> Excel shows 0.01 when you enter 1.

Absolutely! But 0.01 ≠ 1.00

I would have expected this result: 1.00

(In reply to Daniel Schunk from comment #7)
> I would have expected this result: 1.00

If you only want to show the decimal points you have to format the cell as currency. There is a currency symbol in the toolbar or apply it per Format > Cells... > Numbers = Currency or per shortcut shift+ctrl+4. If you don't want to see the currency sign format as number (shift+ctrl+1).

In your initial post you wrote
(In reply to Daniel Schunk from comment #0)
> If I type 5555, I'll get 55.55 in the spreadsheet.
And this is the same as 5555/100.

Excel has had this data _input_ aid since Office 2000.

It is a specialized numeric formatting conversion feature to convert integer constant _input_ to floating point positionally. Setting a positive shift moves the resulting decimal place left (numbers gets smaller), a negative moves the decimal place right (numbers get larger).

Scale of resulting number is not fixed, but depends on the amount of the shift set for the option (a range of 300 to -300) but also the length, in digits, of the integer value entered.

So, with a shift value of 2: 
input => becomes
1 => 0.01 
12 => 0.12
123 => 1.23
1234 => 12.34

and with a shift value of -2:

1 => 100
12 => 1200
123 => 12300
1234 => 123400

Again this is an aid for specialized numeric input. Handy for inputting a long list of numbers via keypad, but does not affect numbers already present on the sheet. 

Certainly not a core requirement, but probably worth implementing for those that would use this feature.  But that sounds more like an Extension to me.

*** Bug 116367 has been marked as a duplicate of this bug. ***

An inelegant workaround: https://ask.libreoffice.org/en/question/36835/how-to-setup-for-automatic-decimal/?answer=36948#post-id-36948

I agree with comment3, i vote for a no fix

"Handy" for some, neutral, at least two clear no, and some workarounds - WFM.

Thanks for creating the ticket anyway. It's always good to ponder on ideas.

*** Bug 130265 has been marked as a duplicate of this bug. ***

Surely Microsoft has some reason to maintain this feature for 20 years? If only a few excel users find this feature useful, surely that would justify MS removing this feature from excel? 

Yes it's 1 keystroke that you're removing. But that adds up over time. I come from a Mechanical Engineering background and CAD softwares advertise fewer mouseclicks as a selling point, because when you are clicking all day for days, weeks, months, it DOES add up. Improved efficiency is always value added for the customer in my opinion. 

I know I'm beating a dead horse now but let's say a user enters on average, 10 values a minute for 8 hours everyday, 5 days a week, 52 weeks a year. Each value requires one decimal point. Time to press that key might be 0.5 seconds. That still adds up to 173 hours a year. Even if you figure that's an overestimate, and cut it in half, that's 86 hours a year spent performing an action that could be automated. Figure that person earns $15 an hour, that action costs the employer $1300 a year per employee that is performing this type of job. 

Obviously any of you could figure that out but the comment regarding "it's just one key" is silly. So is adding values with the + key, yet we have an autosum function. 


I can't code unfortunately, but I'm willing to help in any other way that I can. Thanks

(In reply to cknapp from comment #15)
> I can't code unfortunately, but I'm willing to help in any other way that I
> can. Thanks

You can realize this as an extension. We have a macro team that surely can help you https://blog.documentfoundation.org/blog/2019/09/06/libreoffice-has-a-new-macro-team/

(In reply to cknapp from bug 1300265 comment #8)
> I see this has been ignored. ... I'm ... just disappointed that a feature 
> request ... is being discarded simply because the designers don't
> think "enough" people will use the feature.

Feel free to reopen the ticket if you cannot follow the arguments. We are a community project and all contributions are welcome.

(In reply to Heiko Tietze from comment #17)
> Feel free to reopen the ticket if you cannot follow the arguments. We are a
> community project and all contributions are welcome.

That's okay. It's clear that this feature that excel has isn't worth the time to even put on the project list, even at the very bottom. So I will just make do for now until Microsoft inevitably creates a snap of excel for linux and I'll just use that again. Hopefully these grear community projects will be able to compete without having very old established features that excel users have come to rely upon.

Is there a bounty program here for features? I'd throw $50 at the project if this can at least get put on the list to be added in the next year or two.

(In reply to cknapp from comment #19)
> Is there a bounty program here for features? I'd throw $50 at the project if
Thanks for this positive gesture!

> this can at least get put on the list to be added in the next year or two.
There is not yet a bounty program, but possibly it will be there somewhere in this year?

(In reply to cknapp from comment #15)
...
> Yes it's 1 keystroke that you're removing. But that adds up over time. I
> come from a Mechanical Engineering background and CAD softwares advertise
> fewer mouseclicks as a selling point, because when you are clicking all day
> for days, weeks, months, it DOES add up. Improved efficiency is always value
> added for the customer in my opinion. 
...

I agree with you. The function is also useful for tax consultants, for example, who have to enter many values.

From looking at the various comments, it looks like nobody really understands the importance of this feature to accountants, bookkeepers, and tax professionals.  All of us learn to use ten-key by touch as a basic, required skill in our profession, and ten-key is based on this feature. We use spreadsheets every day, and we must enter long columns of two-decimal figures without looking at the keyboard.  We are adapted and trained to do this by ten-key training because it saves a great deal of time and prevents many errors. Once this training is ingrained it is extremely frustrating to try to do data entry without it.  We NEVER use the decimal key in most situations. So by not making this change you are severely limiting Libre Calc's usefulness for serious accounting, bookkeeping, and tax professionals, and there are a lot of us. I'd love to get away from Microsoft, but the lack of this feature keeps me away from Libre, which is too bad because the concept and execution is otherwise so satisfactory.

*** Bug 154157 has been marked as a duplicate of this bug. ***

Created attachment 185973 [details]
Option in MSO

Seems to be a frequently requested option, so let's reopen.

While MSO provides this feature as a general option I wonder if it was better located at the cell style. Doing so makes it possible to have normal input and dedicated templates or a cell style / numbering format attribute for the accountant task. However, the attributes are usually stored in the document and without standardization we cannot do that.

Regarding the workflow we could follow the MSO example:
1234    => 12,34 (of decimal is set to 2)
1       => 0,01
=A1+1   => 1,01 (with A1 == 0,01)
=1234   => 1234
="1234" => <text>

Number formats are _display_ attributes, not input masks.
If you want to come up with per cell granularity of input mask/behaviour then introduce a new attribute.

(In reply to Heiko Tietze from comment #3)
> Would be a dangerous setting for most users and useful for only a few (who
> are too lazy to press one key).

And others have calculated the time used to type the decimal point.

For some of us, the burden is not the time or effort of actually
typing the decimal point.  The hard part is the concentration required
to inhibit a decades-old habit.  For me, that habit dates back to the
days of punched cards.  (Yes, my beard *is* a fine shade of white,
thankyouverymuch.  How did you guess?)

That said, I am not a big user of Calc, so my approval of this
proposal should count as some small fraction of one vote.

Terry.

(In reply to Heiko Tietze from comment #24)
> ... I wonder if it was
> better located at the cell style. Doing so makes it possible to have normal
> input and dedicated templates or a cell style / numbering format attribute
> for the accountant task. However, the attributes are usually stored in the
> document and without standardization we cannot do that.

No.

This asked feature is completely about a specific person's habits. it is intended to reduce load by utilizing muscle memory, and not requiring to concentrate on some detail that gets done automatically.

As such:
1. It is *NOT* imposed on other potential users of the document. Other users are free to not use this feature, and have all reasons so get angry, when suddenly, when *they* type '123', it automatically converts to '1.23'.
2. It is *NOT* expected to depend on file, or on specific column - just because that would mean that the user *has to* concentrate on details, and switch their muscle memory depending on file, column, or a specific cell.

It is definitely a per-user-profile setting, orthogonal to any "mask-like" possible features.

A possible code pointer to implement this feature would be ScInputHandler::EnterHandler (sc/source/ui/app/inputhdl.cxx), which (or the functions called from it) would check that the input text has only numbers and plus/minus (but no decimal / group separators; no formulas, percents, etc.), and the resulting data is numeric; then it would multiply the end result by respective 10^n. At least that would be the function, where I would start my research - which events happen when I finished entering the data.