I've re-opened this bug. (While I'm here, please accept my apologies for using a complicated attachment originally, which has for a while been obsoleted and I've replaced it with the second of the two non-obsolete attachments, the 14.38 KiB one):
The bug still exists in last night's 4.2.0.0.alpha0+ Win-86@6 build if you use that second attachment, the one named "Simple Conditional Format paste bug demo with instructions in worksheet" (actual filename = CFpasteBug.ods) -------- Version: 4.2.0.0.alpha0+ Build ID: 6372309a0d285f4a176dbcded3f18b72220e123 That's the current nightly build from http://dev-builds.libreoffice.org/daily/master/Win-x86@6/current/ Windows 7 Professional, 32-bit. AMD Turion 64 dual core. 4GB RAM. -------- You only need to get to step 4 to confirm the bug from these instructions (included also in the spreadsheet) 1. Select range B1:E1 2. Edit/Copy 3. Select cell B2 4. Right click on B2, Paste Only ► Number (click Yes to confirm paste) The range B2:E2 does not display its conditional formatting (red or green coloured background) as it should, only the underlying bold, centered plain formatting on a "No Fill" background. The CF is still associated with the range B2:E2 (see Format/Conditional Format/Manage to confirm). You can easily restore it to be visible using Format Paintbrush to paint the format from B2:E2 back into B2, which acts as a "Refresh" function for the Conditional Format in that range. Calling the Format Paint in this way would be a suitable fix, though it's probably not very efficient. The same applies using Paste Special... and pasting anything that doesn't include pasting the formatting from the source range to destination range seems to prevent the Conditional Formatting from being displayed. I think this tells us what is missing from the code. My pure guess is that some function call that was not obviously important was not replicated during a code rewrite that was intended either to reduce Java dependency from the old OpenOffice.org codebase or to allow new and fancy CF such as Color Scales around about the time of LibO 3.6. After all, why would you need to concern yourself with formatting in the target cells if you're not pasting the formatting from Source to Target. (For normal formatting this is true - not for formatting that's Conditional on the cell value). I'm familiar enough with the program behaviour in this regard (the edge cases where the bug is or is not present) that I've suggested below how I'd go about trying to trace and fix the bug in principle, albeit that I am not capable of achieving it myself in practice any time soon. Bug 57661 has been fixed for a while, and had exhibited similar behaviour (when using Delete to clear the values from cells with Conditional Format, the CF did not display and Undo would not fix it either). Perhaps the patches used there can reveal the correct functions to call to refresh/recalculate the Conditional Format display, or that code can itself be made into a function or method we can use for this fix to avoid code duplication. I have not developed a full software application in 16 years. I've never worked on a team software project, so I would need a huge learning curve to set up a dev environment for myself and delve into the LibO codebase myself. I intend to set up a Linux dual-boot in the next month or two, and will probably attempt to set up a dev environment then and try a little tinkering, but for now, I'm unable to pull my weight. So please recognise my limitations, and that all the LibO developers have my utmost respect and admiration. I may be making incorrect assumptions about the code structure and I do not wish to "teach my grandmother to suck eggs" or make out that debugging is easy. You clearly are all far better programmers and software engineers than I ever was. I merely try to make a suggestion that may be helpful to someone who knows what they are doing and has set up the right debugging tools. It may also be the case that the correct code is already in there but a bug in the conditional branching (e.g. IF... THEN) isn't making it execute when it needs to. SUGGESTED PSEUDOCODE APPROACH TO SOLUTION I've made many assumptions about the code structure, object.method and condition statements and have written in some kind of object-oriented pseudocode (please forgive my syntax, I've a nasty feeling my comment delimiters are back-to-front - it's been a long time - and I'm making no attempt to trace or handle exceptions): At the end of any Paste Special... action which pastes from a SOURCE Range to a TARGET Range, before returning control to the user interface or calling function/method, include the following steps: */ START of object-oriented pseudocode /* */ all the rest of the Paste Special... function goes above here */ */ Recalculate Conditional Format based on new contents of Target Range if format was not overwritten during Paste and if Conditional Formatting is present within the Target Range /* IF (PasteSpecialDialog.FormatCheckbox.state == FALSE) THEN { IF (TargetRange.Format.conditionalFormatIsPresent == TRUE) THEN { TargetRange.ConditionalFormat.recalculate(); } } return returnCode; } /* return from Paste Special... function */ /* END of pseudocode */ (As we're dealing with a range of many target cells, some of which might intersect with ranges that include CF and some of which might not, it might require some loop and only require recalculation for target cells where CF is present to avoid slowing down copy/paste where CF is not present, which probably represents most spreadsheet users. I wouldn't want this fix to slow down a copy and paste of 10 000 cells with normal formatting only) I'd hope it would be possible in a debugger to step through and find the functions called when using Format Painter onto the same target range as the source range (which I presume is the same as Paste Special... with only the Format box selected). It seems clear that if there is CF in the target cells it must be reevaluated whenever the values or text in those cells are changed, and it appears that is not happening unless the format from the source range is also pasted. I also realise that it may require additional changes to ensure that the Undo function will work properly and refresh the CF when the original values in those cells are restored (I've no idea how Undo is implemented) Sorry for the length of the post, but I hope I've clarified the edge cases where this bug does and does not seem to occur, in the hope this may narrow down the hunt. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1099246 Title: [Upstream] Undo does not preserve conditional formatting To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/1099246/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
