Bug 38741 - Number FORMATTING in TABLES: option 'Negative numbers red' does not work under certain circumstances
Summary: Number FORMATTING in TABLES: option 'Negative numbers red' does not work unde...
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.0 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-28 03:13 UTC by burkhard.kasten
Modified: 2015-02-11 19:58 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
example and screenshots (55.99 KB, application/vnd.oasis.opendocument.text)
2011-06-28 03:13 UTC, burkhard.kasten
Details

Note You need to log in before you can comment on or make changes to this bug.
Description burkhard.kasten 2011-06-28 03:13:47 UTC
Created attachment 48509 [details]
example and screenshots

Create a Text Document.
Insert a table
Enter a number -€123,45(tab) - it appears in red .
right click in Field, select "change number format"
Try to uncheck "negative in red" - it is not possible!

Select other Format.
Try to uncheck "negative in red" - Writer crashes!

screenshots of selections in file.

LibO 3.4 release, german.
windows xp 32 bit, including all actual patches
Error occurs also in suse linux 10.1, 64 bit, german.
no printers involved.
Comment 1 Eike Rathke 2011-08-05 12:18:48 UTC
This should be fixed in the mean time, please try the 3.4.2 release and close this bug if fixed.
Comment 2 burkhard.kasten 2011-08-08 03:44:02 UTC
Sorry, this function is still faulty.
Writer does not crash but:

1st entry:
(-1.234 €) (#.##0 [$€-407];[ROT]-#.##0 [$€-407]):
"red" is checked. when unchecking: left column switches from currency to number.
2nd entry:
(-1.234,00 €) (#.##0,00 [$€-407];[ROT]-#.##0,00 [$€-407]):
"red" is checked. when unchecking: left column switches from currency to number.
3rd entry:
(-1.234,-- €) (#.##0,-- [$€-407];[ROT]-#.##0,-- [$€-407]):
"red" is checked. when unchecking: left column switches from currency to number.
4th entry:
(-1.234,00 EUR): (#.##0,00 [$EUR];[ROT]-#.##0,00 [$EUR]):
"red" is checked. when unchecking: left column switches from currency to number.
5th entry:
(-1.234 DM): (#.##0 [$DM-407];-#.##0 [$DM-407]):
"red" is unchecked. ok.
6th entry:
(-1.234,00 DM): (#.##0,00 [$DM-407];-#.##0,00 [$DM-407]):
"red" is unchecked. ok.
7th entry:
(-1.234 DM): (#.##0 [$DM-407];[ROT]-#.##0 [$DM-407])
"red" is checked. when unchecking: left column switches from currency to number. DISPLAY IS BLACK!

etc.
Comment 3 Björn Michaelsen 2011-12-23 12:24:22 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 4 sasha.libreoffice 2012-02-16 04:46:26 UTC
@ burkhard.kasten
In 3.5.0 still reproducible?
Comment 5 Roman Eisele 2012-05-03 04:19:51 UTC
This is a Writer bug, therefore changed 'Component'.
Comment 6 Roman Eisele 2012-05-09 03:21:10 UTC
PARTIALLY REPRODUCIBLE with LibreOffice 3.5.3.2 (Build-ID: 235ab8a-3802056-4a8fed3-2d66ea8-e241b80), German langpack installed, on MacOS X 10.6.8 German.

First I followed the steps to reproduce in the original description. Everything worked as expected: unchecking "Negative in red" makes the number appear black; selection other formats does not crash. OK.

Secondly, to match comment #2, I tried to apply all available number formats one by one to a cell containing '-1.234 €' (this means -1234.00, not -1.234, because the reporter uses a German UI and therefore '.' is used as thousands separator, not as decimal separator). For all formats which default to negative numbers in red, I tried to uncheck the checkbox "Negative in red". Everything worked as expected. OK.

Both tests were done with a new Writer file.

Thirdly, I tried the sample file 'Test4.odt' provided by Burkhard Kasten. And here, of course, unchecking the "Negative in red" checkbox DOES NOT change the color of '-123,45 €' in the 1st cell of the table. Changing the format does not crash, but also does not help.

So IMHO there are still problems with the number format in the original sample file -- and maybe in other existing .odt files. In a new .odt file, I can't reproduce the bug for now.
Comment 7 Roman Eisele 2012-05-10 02:29:59 UTC
Wait, I tryed again --

PARTIALLY REPRODUCIBLE with LibreOffice 3.5.3.2 (Build-ID:
235ab8a-3802056-4a8fed3-2d66ea8-e241b80), German langpack installed, on MacOS X
10.6.8 German.

The crash is really fixed, but unchecking "Negaive in red" still does not work under some circumstances. It is just some steps harder to reproduce the problem now.

Steps to reproduce:
1) Create a new Writer document.
2) Create a new table (from Menu, select Table > Insert > Table ...) with 2 rows and 2 columns (default).
3) In the first cell, enter "-€123,45"
4) Press the Tab key. The text in the 1st cell changes to "-123,45 €" (OK) and is red now.
5) Save the document as .odt file.
6) Close it.
7) Open the document again via menu "File > Open ...".
8) Click in the first cell of the table (still containing "-123,45 €" in red).
9) Optional: select the complete text of the cell (this does not make a difference.)
10) Right-click the cell and select "Change number format" from the popup menu.
11) In the dialog window "Number format", uncheck the checkbox "Negative in red".
12) Click OK / Press Enter.

Expected result: the text "-123,45 €" in the first cell is no longer red.
Actual result: the text is still red.

Repeating steps 8 to 12 does not change anything.

I can temporarily 'repair' the table if I select the complete text of the 1st cell and set the text color to "automatic". After this action, I can again check and uncheck the "Negative in red" checkbox, and the text color changes accordingly.

If I close the document again, leaving the checkbox "Negative in red" checked, and then open the document again, the behaviour is again wrong (unchecking the checkbox does not work).

But if I close the document, leaving the checkbox "Negative in red" NOT checked (so that the number appears in black), and then open the document again, the behaviour is right: I can again check and uncheck the "Negative in red" checkbox, and the text color changes accordingly.

So, whenever the document is saved and closed, while the checkbox "Negative in red" is checked, the checkbox will not work when I open the document again.
Comment 8 Roman Eisele 2012-05-10 02:50:03 UTC
@Sasha:
Could you please try if this behaviour (see my comment #7) is reproducible on Fedora and/or Windows? Or something similar? Thank you!

*

Changed the Summary field to reflect the current (reproducible) problem more exactly (that the crash is no longer reproducible is said by the original reporter in comment #2, too!).

*

The behaviour I reproduced in comment #7 is also reproducible with LOdev 3.6.0alpha0+ (Build ID: c92c5c6; installation file: master~2012-05-03_05.23.04_LibO-Dev_3.6.0alpha0_MacOS_x86_install_en-US.dmg).

Single difference: the trick to 'repair' the table via selecting the complete text of the 1st cell and setting the text color to "automatic" seems not to work anymore. The text of the 1st cell stays red, whatever I do.

Will try a newer Master build later.
Comment 9 sasha.libreoffice 2012-05-10 04:48:37 UTC
Not reproducible in 3.5.3 on Fedora 64 bit
IMHO Writer can not understand word [ROT] in comment 2. In my case used word [RED].
Comment 10 Roman Eisele 2012-05-10 09:47:32 UTC
@Sasha:
Thank you very much for testing!

(In reply to comment #9)
> Not reproducible in 3.5.3 on Fedora 64 bit.

Good ... but I can reproduce it every time, even after deleting my complete User profile. Strange. This issue must be either OS-dependend, or complicated in another way.

> IMHO Writer can not understand word [ROT] in comment 2. In my case used word
> [RED].

Ah, good idea! But the German '[ROT]' is supplied by LibreOffice itself, because the original reporter (and both me) use a German locale. It looks like this issue depends on the locale setting. I will experiment a bit in the next days and report here again if I come to some conclusion.

@Sasha:
Which UI language and which locale setting (in LibreOffice, "Tools > Options > Language settings > Languages") did you use for your test? Thank you again!
Comment 11 sasha.libreoffice 2012-05-10 22:16:02 UTC
UI English, Locale Russian
Comment 12 Walter 2014-06-02 12:24:56 UTC
Since it is a listbox there is no option to uncheck!
I tried to reproduce the bug on Libreoffice but worked fine for me.
It might have been resolved in the newer version.

Version: 4.1.2.3
Build ID: 40b2d7fde7e8d2d7bc5a449dc65df4d08a7dd38
Windows 7 (64-bit)

I am marking it as NEEDINFO to verify whether the bug is reproducible on the newer version of Libreoffice.
Comment 13 QA Administrators 2015-01-10 18:06:37 UTC
Dear Bug Submitter,

This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.

For more information about our NEEDINFO policy please read the wiki located here: 
https://wiki.documentfoundation.org/QA/FDO/NEEDINFO

If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.


Thank you for helping us make LibreOffice even better for everyone!


Warm Regards,
QA Team

Message generated on: 10/01/2015
Comment 14 QA Administrators 2015-02-11 19:52:07 UTC
Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided):

a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. 
Please do not:
a) respond via email 
b) update the version field in the bug or any of the other details on the top section of FDO

Message generated on: 2015-02-11
Comment 15 QA Administrators 2015-02-11 19:58:19 UTC
Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided):

a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. 

Please do not:
a) respond via email 
b) update the version field in the bug or any of the other details on the top section of FDO
Message generated on: 2015-02-11