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).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.