Conditional formatting not saving correctly Think this is a bug as its only started since upgrading to new version looks like i'll have to revert to the ealier version Steps to reproduce: I have a grid of cells selected (approx 48 X 120) these cells have Conditional formatting set on them Enter a letter in any of the cells (say 'r' for red) and that cell will formate to red - I have 4 different colours I can set this up no problem and it works ok But when I reopen the spreadsheet the formatting towards the bottom of the grid does not work - just shows the inputted letters If I look at formatting>> Conditional formatting>> manage the 'range' has changed Current behavior: Conditional formatting not saving correctly Expected behavior:to save correctly Platform (if different from the browser): Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
I need detailed instructions to reproduce this. This means exact instructions what to do at which step. Without these information I can't fix this problem. Thanks.
Created attachment 69796 [details] attachment-9496-0.html Hello My set up W7 64x and Libreoffice Version 3.6.3.2 (Build ID: 58f22d5) Rather than try to explain I've attached a worksheet that shows the problem But briefly the grid set in Conditional formatting changers after saving After trying to reproduce this problem I think the cause is that the grid contains merged cells - as a grid without merged cells worked. However in the previous Libreoffice version the grid worked ok regardless of the merged cells Conditional formatting >> manage, should show E7:AZ121 Cell value is = "b" That is what it shows when first set, Observe all cells correctly formatted Save, close, reopen Look towards the bottom of the grid and you'll see that some of the cells are no longer formatted The saved grid has changed Hope this is enough for you to see the problem - and its fixable Graham :-) ->--------------------< On 08/11/2012 18:19, bugzilla-daemon@freedesktop.org wrote: > > *Comment # 1 <https://bugs.freedesktop.org/show_bug.cgi?id=56844#c1> > on bug 56844 <https://bugs.freedesktop.org/show_bug.cgi?id=56844> from > Markus Mohrhard <mailto:markus.mohrhard@googlemail.com> * > I need detailed instructions to reproduce this. This means exact instructions > what to do at which step. > > Without these information I can't fix this problem. Thanks. > ------------------------------------------------------------------------ > You are receiving this mail because: > > * You reported the bug. >
Created attachment 69797 [details] attachment-9496-1.dat
Created attachment 69798 [details] ME Activity4.ods
At least in master this document can be saved without any data loss.
Ok reading the bug report again. The attached file is already wrong and only contains the range "collect 2'.E7:'collect 2'.AZ99 'collect 2'.E101:'collect 2'.AZ121 'collect 2'.E100:'collect 2'.AA100 'collect 2'.AZ100:'collect 2'.AZ100" Do you have the original file that is not wrong? Otherwise you can fix it by defining the range newly in 3.6! In 3.6 we switched from cell style based conditional formats to range based conditional formats which might create some problem for some documents. However after you have range based conditional formats you will always be able to see and beginning with 4.0 you will be also able to dynamically change the range of the format.
That is the original file, when its saved the range changers Looks like I'll just have to go back to 3.5 maybe 4.0 will work Graham :-) ->--------------------< On 11/11/2012 07:50, bugzilla-daemon@freedesktop.org wrote: > > *Comment # 6 <https://bugs.freedesktop.org/show_bug.cgi?id=56844#c6> > on bug 56844 <https://bugs.freedesktop.org/show_bug.cgi?id=56844> from > Markus Mohrhard <mailto:markus.mohrhard@googlemail.com> * > Ok reading the bug report again. > > The attached file is already wrong and only contains the range "collect > 2'.E7:'collect 2'.AZ99 'collect 2'.E101:'collect 2'.AZ121 'collect > 2'.E100:'collect 2'.AA100 'collect 2'.AZ100:'collect 2'.AZ100" > > Do you have the original file that is not wrong? Otherwise you can fix it by > defining the range newly in 3.6! > > In 3.6 we switched from cell style based conditional formats to range based > conditional formats which might create some problem for some documents. However > after you have range based conditional formats you will always be able to see > and beginning with 4.0 you will be also able to dynamically change the range of > the format. > ------------------------------------------------------------------------ > You are receiving this mail because: > > * You reported the bug. >
Created attachment 70348 [details] LibO files with bug
Comment on attachment 70348 [details] LibO files with bug I have conditional formatting that work well on 3.5 I've done the same with 3.6 and it doesn't work. I delete only the numbers in the grid. All the conditionnal formatting is missing.
I'm using LibreOffice 3.6.4.3 under Win XP and I've got the same problem. .ODS documents with conditional formatting created with and working OK in LibO 3.5 don't show the conditional formatting when opened in 3.6.3.4 After adding conditional formatting again to the document, it seems that using "save" doesn't work. Conditional formatting is saved only when using "save as" and using a different filename. Best Regards, Eric Ficheux
I can confirm this bug on platform Win XP 32 with LibreOffice 3.6.4.3
[Reproducible] with smaple 2012-11-21 06:26 UTC, ledoux andparallel installation of "LOdev 4.0.0.0.beta1 - GERMAN UI / German Locale [Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7)]" {tinderbox: @6, pull time 2012-12-06} on German WIN7 Home Premium (64bit) with separate /4 User Profile for Master Branch. After having marked and deleted contents of B4:J12 all CR itemx except L4T12 have been deleted. And the bad news is that UNDO will not bring back CF (Bug 57176). I think the core of the problem has nothing to do with FILESAVE, because CF vanishes immediately with deleting th numbers in a.m. Sample document I did some tests in B7:D9. I deleted (<Del>) cells one by one D9 ... C9 ... B9 ... D8 And tested with contents 2 or 1 for C7 after each deletion, red/green was still ok after all 9 Cells have been deleted. Closed / reopened, now deleted B7:D7 ... B8:D8 ... B9:D9. Now CF for C7 was destroyed after last deletion. I did not test all these details systematically, but the core problem is Still [Reproducible] with parallel installation of "LOdev 4.0.0.0.beta1 - GERMAN UI / German Locale [Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7)]" {tinderbox: @6, pull time 2012-12-06} on German WIN7 Home Premium (64bit) with separate /4 User Profile for Master Branch Was more or less ok with Server Installation of "LibreOffice 3.6.0.4 German UI/Locale [Build-ID: 932b512] on German WIN7 Home Premium (64bit) (before implementation of CF-Ranges concept).
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.0.3 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-02-19
(In reply to Rainer Bielefeld Retired from comment #12) > After having marked and deleted contents of B4:J12 all CR itemx except L4T12 > have been deleted. And the bad news is that UNDO will not bring back CF (Bug > 57176). Reproduced with attachment 70348 [details], sudoku_libreO36_hard2_bug.ods. Win 7 Pro 64-bit, LibO Version: 4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432 Locale: fi_FI
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
For me, this bug no longer appears