Bug 120670 - Writer: If editing value in table and leaving the field, it is loosing user-defined Number Format (per Comment 6)
Summary: Writer: If editing value in table and leaving the field, it is loosing user-d...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Tables-Formulas
  Show dependency treegraph
 
Reported: 2018-10-18 06:27 UTC by Hans-Peter Jansen
Modified: 2019-01-17 11:21 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
A Writer document with an invoice table (10.85 KB, application/vnd.oasis.opendocument.text)
2018-10-18 06:27 UTC, Hans-Peter Jansen
Details
A Writer document with an improved invoice table (11.06 KB, application/vnd.oasis.opendocument.text)
2018-10-18 10:23 UTC, Hans-Peter Jansen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hans-Peter Jansen 2018-10-18 06:27:05 UTC
Created attachment 145796 [details]
A Writer document with an invoice table

Dear everybody,

attached is a writer document, that demonstrates an area, where Writer could improve a little, and any user of similar table will celebrate!

It shows a typical simple invoice table, containing a few items, and each item line contains a formula for calculating the unit sum. Below that, it comes with the usual summing, VAT, etc.

Issues:

 * When adding an item below the microbes (add table row below), it is missing the sum formula, and consequently, this item is missing in the net amount sum. 
 * Moreover, with removing an item (delete table row), all summing formulas are invalidated, and have to be redone. 
 * Another minor issue lurks in the VAT field (A9), if simply editing the VAT value, and leaving the field, it is loosing its special VAT value format. Reassigning the format and replacing the content with just the value is necessary to recover. 

Discussion:

Of course, this behaviour could be changed by embedding a Calc table, but this comes with a price to pay. Apart from the inconvenient handling, it creates issues with page break, etc... 

I'm using such tables since more than 15 years with SO, OO, LO, and I'm enjoying todays state a lot, as it preserves the item row formatting, when adding rows. This used to fail in former times.

Solving these issues would make a lot of people, that create invoices with LO, very happy. I'm sure, I know some of them...
Comment 1 Mike Kaganski 2018-10-18 07:11:46 UTC
Hi! Thanks for the suggestions.

While I agree that the last suggestion is a valid issue, I suppose that first two bullets in the list are not.

> * When adding an item below the microbes (add table row below), it is missing
> the sum formula, and consequently, this item is missing in the net amount sum.
> * Moreover, with removing an item (delete table row), all summing formulas
> are invalidated, and have to be redone.
This one is because the sum formula in your Net Amount lists individual cells. In this case, the program has no way of knowing that adding a row requires to modify the arguments to a formula. If you use simply `=sum(<D2:B7>)` instead of `=sum(<D2|D3|D4|D5|D6|B7>)`, it will work as expected. Well - you could have valid reasons to not include the last line (Shipment) into the range; then you could simply add an empty row below the Microbes, assign it a minimal height, remove inner borders (so it would look like simply double-border), and include it into the range formula (in that case, it would look like `=sum(<D2:D7|B8>)`). Then adding rows below Microbes would work fine, and removing rows also would work (except for the rows explicitly mentioned in the formula).
Comment 2 Hans-Peter Jansen 2018-10-18 10:23:07 UTC
Dear Mike,

thanks for your quick response and valuable suggestions.
I've no idea, why I stuck with the silly sum formula. Most probably by simulating the ∑ method... 

'=sum(<D2:B7>)' is almost fixing 2 of the 4 issues mentioned.
I say almost, because, it doesn't work for removing the first item, but then
'=sum(<D1:B7>)' is doing fine for that case, too. 

Thank you very much, will incorporate such adjustments to all invoice and offer templates in a second.

What's remaining is the third bullet, and the first half of the first. I'm sorry for not describing the first bullet properly, and for not splitting this topic in two issues, which it deserved. Here is the first part, which wasn't formulated properly:

 * Adding a row of another issue is missing to clone the sum formula for the new row (amount * unit price).

I've attached an updated version of the test file, incorporating the changes, you suggested for further discussion and hopefully, to support somebody, who might want to tackle the remaining issues.
Comment 3 Hans-Peter Jansen 2018-10-18 10:23:57 UTC
Created attachment 145801 [details]
A Writer document with an improved invoice table
Comment 4 Hans-Peter Jansen 2018-10-18 10:26:04 UTC
Grrr:

 * Adding a row for another item is missing to clone the sum formula for the new row (amount * unit price).
Comment 5 Timur 2019-01-11 16:38:14 UTC
(In reply to Hans-Peter Jansen from comment #4)
>  * Adding a row for another item is missing to clone the sum formula for the
> new row (amount * unit price).
I don't understand what you would like. Clone what, row where cursor is? 
We need steps, with Experienced and Expected result. But, that must be a new request.

This bug with multiple issues is Invalid report. 
But we can convert it to a proper bug for this:

(In reply to Hans-Peter Jansen from comment #0)
>  * Another minor issue lurks in the VAT field (A9), if simply editing the
> VAT value, and leaving the field, it is loosing its special VAT value
> format. 

Looks like a bug. Please explain what's value format here. So that we can understand what happens with s simple change, let's say from 12,3% to 17%.
Comment 6 Hans-Peter Jansen 2019-01-16 16:43:18 UTC
Thanks Timur, for your reply.

(In reply to Timur from comment #5)
> (In reply to Hans-Peter Jansen from comment #4)
> >  * Adding a row for another item is missing to clone the sum formula for the
> > new row (amount * unit price).
> I don't understand what you would like. Clone what, row where cursor is? 

Done: https://bugs.documentfoundation.org/show_bug.cgi?id=122763

> We need steps, with Experienced and Expected result. But, that must be a new
> request.
> 
> This bug with multiple issues is Invalid report. 
> But we can convert it to a proper bug for this:

Okay, understand. Lesson learned.

> (In reply to Hans-Peter Jansen from comment #0)
> >  * Another minor issue lurks in the VAT field (A9), if simply editing the
> > VAT value, and leaving the field, it is loosing its special VAT value
> > format. 
> 
> Looks like a bug. Please explain what's value format here. So that we can
> understand what happens with s simple change, let's say from 12,3% to 17%.

The value format is '0,0%" VAT"'. If you load the attached document, put the cursor in the VAT field (A10), and edit the value to say "13,2", and tab out of the field, the format is lost (-> Text '@'), the new value is displayed left aligned, although the field is still right aligned(!), and the calculation in B10 fails (-> 0,00 €). I wasn't able to recover from this without reassigning the specific %-format (0,0%" VAT"), and *enter* the plain value again. The only proper way to change the VAT value for an experienced user is selecting the whole value, and replacing it with a plain number.

I would expect the field A10 to keep the assigned format, and just accept the new value. Then, the calculation in B10 wouldn't fail as well, I bet.
Comment 7 Timur 2019-01-17 08:45:37 UTC
I change the title and confirm since this looks like a bug. Repro 6.3+.
We still need an explanation why this happens and a check for being a duplicate.