Bug 147233

Not really clear what this is about. Please try to give an example.

(In reply to Timur from comment #1)
Do you find display consequences (and modification possibilities) reasonable according to the referenced software documentation for the functionality “Calculating in text documents”?

Which descriptions would other users find more pleasing and helpful for the observed software behaviour?

As Timur said, please give an example and some steps to reproduce.
=> NEEDINFO

Created attachment 178569 [details]
Example for the software functionality “Calculating in text documents”

(In reply to Dieter from comment #4)
> As Timur said, please give an example and some steps to reproduce.

Do you understand the attached test document better than the available software documentation?
https://help.libreoffice.org/7.3/en-GB/text/swriter/guide/calculate.html

Created attachment 178570 [details]
Screenshot for a questionable software behaviour with calculation results

Would you find editing effects occasionally questionable for desired automatic display updates at the shown place?

Thank you for the sample document. But I can't eee the problem: 2,34 € + 1,26 € = 3,60 € is correct. And everything is in line with documentation. So what is your expected result?
=> NEEDINFO

(In reply to Dieter from comment #7)
> … But I can't eee the problem: …

* Did you notice that parts of the computation result display can be marked and modified?

* Should the number format representation be kept consistent for such a test case?

* May I expect that the original formula can become write-protected?


By the way:
I suggest to compare the software behaviour with functionality from fields.
https://help.libreoffice.org/7.3/en-GB/text/swriter/guide/fields.html

(In reply to Markus Elfring from comment #8)
> (In reply to Dieter from comment #7)
> > … But I can't eee the problem: …
> 
> * Did you notice that parts of the computation result display can be marked
> and modified?

It wasn't clear to me, that you refer to that behaviour. Please write proper bug reorts:
- Actual result (formula can be modified without formula editor)
- Expected result (Formula should only be modified in formula editor)
Is this correct?

Not sure, if this is a bug or enhancement request. I add esign-team for double-check.

(In reply to Dieter from comment #9)
> - Actual result (formula can be modified without formula editor)
> - Expected result (Formula should only be modified in formula editor)

I find that this wording expresses an other software variant than my expectation.

I propose to increase the distinction between the construction of a formula and the corresponding computed value display.

* I imagine that a formula can be edited by some means (besides the widget which is supported at the moment).

* Would a setting be helpful for switching between source modification and another (visual) representation (similar to the existing configuration option for fields)?

It is possible to insert a formula in plain text, for example F2 > =1+1. The result is a field with the type "inserted formula" and editing is possible only via the fields dialog.

I suggest to do the same for table formulas, as requested in this ticket. That means F2 goes into the formula edit mode as today but the calculated result would be a field (with proper shading). Double click on the field probably requires to go into the formula edit mode as the fields dialog has no knowledge of table cells. Consequently we cannot use the field dialog to define the the number format but have to keep it per table cell.