Created attachment 44052 [details] Test1 shows block before moving If you set up a conditional format on a block of cells, as I have in Test1, and if that conditional format is liked to a relative cell, the correct changes are not made to the conditional format formula if the cell block is moves as in Test2. Notice what happens to the conditional format in j16 (and others) in Test1 when I move the whole block to get to Test2 Bugger, this will only take 1 attachment. I will submit Test2 manually if you cannot see that the format of j16 changes when you move the whole block by highlighting it with the cursor and moving as a block.
Could you please provide detailed steps to reproduce the problem?
Created attachment 44193 [details] Position of the data block after moving Note the way the relative cells have changed in the conditional formatted cells....they have not kept in sync with the move.
(In reply to comment #1) > Could you please provide detailed steps to reproduce the problem? I have done.....I have even gone 1 better and set up an experiment showing before and after....do you mean you want me to say " go to cell j16, set it up as a conditional formatted in the following way"....you only have to go to the cells as I outlined above to see what the formatting is...then move the block to a new position as in test2....
[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
needinfo keyword redundant by needinfo status.
This is a Calc bug, therefore changed Component accordingly.
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
reproduced in 3.6.0 on Fedora 64 bit When I copy-paste cell J16 to another sheet, it looks the same. But when I copy-paste it with adjacent cell, it looks different. Format->Conditional formatting->Conditional formatting also differs. I am not sure that have done all correct, therefore set status to Unconfirmed
Marking as NEEDINFO. I don't see any different. Attaching an image showing what I see, if you could tell me exactly what I'm looking for I'll confirm it. LibO Version: Version 3.6.1.2 (Build ID: e29a214)
Created attachment 68559 [details] FDO#34949
If you create conditional formatting on A1:B1 using four formulas all like LEFT($B1)=”s” the result of copy A1:B1 and paste special of formats only to eg A2:B4 gives garbage values for the tests. Setting up conditional formatting separately on A1 and B1 each using four formulas like LEFT(B1)="s" and then doing copy and paste special of formate only to eg A2:B4 gives the correct result. There is something clearly going wrong here in my first point, so setting status back to NEW.
** 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.0.5 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) 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: 2015-09-03
Moving means: select the cells you want to move. Click and drag it somewhere. Not copy & paste. As said in the description: "when you move the whole block by highlighting it with the cursor and moving as a block." No problem observed, so closing as WFM. If someone wants to set this to NEW again, please provide a screenshot showing the problem! Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 66d2b72667792cb18b25805387824d636e2a455c TinderBox: Win-x86@39, Branch:master, Time: 2015-11-18_02:35:53 Locale: fi-FI (fi_FI)