Created attachment 69152 [details] Try to change the T1 column so that conditional formatting has a limit of 5 and not 2.5. Column T2 changes too. In the following file, which worked perfectly in previous versions, if I change the conditional formatting of the column marked T1 so that the style of the numbers switch to "numerirossi" for a value <5, then the style of the column marked T2 changes too. This seems not to happen in new files, but breaks my files from previous LO releases.
Note: the column T2 was created by "insert column", so it is a clone of the column T1. If I "clean direct formatting" on the two column and recreate the conditional formatting, all is ok. So it seems that when selecting just a column, the program fails to "separate" the conditional formatting from the other one. By the way, the dialog is quite strange too, showing just the first part of the rule, as if something where fiddly.
Created attachment 69154 [details] (Broken) look of the conditional formatting dialog
Hmmm... this comment smells very suspicious: https://bugs.freedesktop.org/show_bug.cgi?id=54621#c8 (Copied here: Ok, the problem is ScRangeList which is a ref counted class with an annoying copy behavior + ScDeleteObjectByPtr. The solution is to make ScRangeList a non ref counted class, copy c'tor and operator= cloning the members and not copying pointers + removing ScRangeListRef.)
Romano: I won't have much time tonight so I can't test right now your bug. Could you give a try to LO 3.6.3 prerelease http://www.libreoffice.org/download/pre-releases/ ? BTW, the comment you quoted is from a core dev. Of course, everybody can make a mistake but could you explain why it could be suspicious for everybody (since I'm just a beginner for C++)? If interested, you can build LO by following this link: http://wiki.documentfoundation.org/Development/Native_Build
(In reply to comment #3) > Hmmm... this comment smells very suspicious: > > https://bugs.freedesktop.org/show_bug.cgi?id=54621#c8 > > (Copied here: > Ok, the problem is ScRangeList which is a ref counted class with an annoying > copy behavior + ScDeleteObjectByPtr. > > The solution is to make ScRangeList a non ref counted class, copy c'tor and > operator= cloning the members and not copying pointers + removing > ScRangeListRef.) This comment has nothing to do with your issue. I doubt that you understand what I wrote in this comment. This comment is only about an issue with one of our internal data structures but has nothing to do with your problem. Your file contains a conditional format that is defined for D8:F16 so you need to separate the formats. This is not a bug but just a small inconvenience that we have when we transformt he old style based conditional formats to range based conditional formats. As soon as you have range based conditional formats working with them is much more easy. You can begining with 3.6 therefore also check where conditional formats are applied through Insert->Conditional Formatting->Manage which would be impossible with style based conditional formats. The UI problem has been fixed in master for months now but can't be backported because it will break the String freeze. P.S. In master/3.7 you can already easily change the range a conditional format is applied to by just selecting the range in the conditional formats dialog.
Sorry if the comment above sounded offensive. It was just a gut feeling, evidently wrong, on the base that the problem seemed to arise from a strange behavior on copy, as if the was a reference connection between the two conditional formatting ranges instead of a separate copy. It was not meant to sound accusing, I was just trying to help --- again, sorry. I have explained very badly my problem, too. My problem is that yes, I have a conditional format on D8:F16 (not sure about indexes, but the idea is ok), making the number red if they are less than 5. Now I select just the last column of that format, and modify the limit (5) to be 2.5. Quite surprising, all the conditional format will change, and not just the selected column. I do not remember a behavior like that in previous versions of LO (or OO.org for that matter); but maybe, again, I am wrong. Simply it doesn't seem the inteuitively correct result... to me.
> I have explained very badly my problem, too. My problem is that yes, I have > a conditional format on D8:F16 (not sure about indexes, but the idea is ok), > making the number red if they are less than 5. Now I select just the last > column of that format, and modify the limit (5) to be 2.5. Quite surprising, > all the conditional format will change, and not just the selected column. I > do not remember a behavior like that in previous versions of LO (or OO.org > for that matter); but maybe, again, I am wrong. Simply it doesn't seem the > inteuitively correct result... to me. That is one problem with range based conditional formats. IT will be much better in 3.7/master. In 3.6 you'll see th range always in the title of the dialog. It is not possible to update only a part of a range at the moment therefore if you select an area that contains already a conditional format it will just pick this one up. In 3.7 we will have overlapping conditional formats and you can change the range of a conditional format in the dialog. This should then solve all the problems you mentioned. It still means that you have adapt your workflow a bit and get used to using the Manage Conditional Formats window. But in the end it allows much more complex conditional formats and fixes a lot of problems that were around the handling of conditional formats. If you want to test it most of the changes are already available in the daily builds.
Thank you very much for your explanation, now I understand. A last question: what will happen editing the same file with 3.4 and 3.6? I have the last Ubuntu on my laptop, but the computer in my office run the 12.04 LTS, and probably I will need to edit the file on the two machines (the directories are synced with unison). Thanks again for your time.
I still think there is a bug, nevertheless. Look at the test_new_cf.ods file. If I define a new conditional format, says, on column B (from B4 to B11), then I do an "insert column", the new column will have the conditional formatting (ok) but when opening the conditional format dialog on the newly created C column the dialog says "conditional formatting for B4:B11", and looking at "conditional formatting -> managing" seems that the C column is not included in the conditional formatting ranges. But the conditional format of B column is applied to numbers in C. Should I open another bug? Or it's me again not understanding the new feature?
Created attachment 69184 [details] Column C has conditional formatting albeit from ->manage seems not to be covered
And by the way, with respect to comment #9: exporting the file to MS Excel format gives a file that has column C without conditional formatting.