Apache OpenOffice (AOO) Bugzilla – Issue 51429
Search and replace w/o color changes cell color
Last modified: 2013-08-07 15:12:27 UTC
Please fix Calc so that it retains the color of replaced text in a 'Find and Replace' operation - or maybe even enhance the replacer making it possible to set the text color/format for the Find and Replace source and destination fields like in Writer. Excell has this same frustrating bug so you could get a real advantage here merely by fixing the bug. When you 'Find and Replace' in the spreadsheet it's currently not possible to set the color so that it changes the color of a certain word throughout the spreadsheet (only solution is to copy paste inti MS Word !! :( - as Writer allows it color/format _only_ on its non-Calc-imported text and Calc itself can't do it). So when you somehow finally DO have, say, a 10.000 words Calc-manuscript with the words "MAIN CARACTAR" in a certain color and you realize you misspelled it and have to change it into "MAIN CHARACTER" you make a 'Find and Replace' on the string "MAIN CARACTAR" and replace it with "MAIN CHARACTER" - and since you CANNOT set the color you of course assume that Calc leaves the color as it is! - But NO. It changes every replacement on that string into the wrong color - even the whole cell color. I really hope you can fix this. Cheers -- David
Hi, could not reproduce using your description and OOo1.9.113 . Please provide a document and a step by step description based on this file on how to reproduce your Issue. Frank
Created attachment 27791 [details] Spreadsheet for repro og color replace bug.
I've created an attach now. Just open it in Calc and replace "buck" with "bug" and watch as all the text coloring is destroyed even on OTHER words than "buck" whereas it should have left the coloring alone. The best fix would be to allow styling in both the Find and Replace fields like in Writer. Cheers -- David
Hi, my first tries involved a single word in a cell, making the attribute set on the cell property. Your example is to use a so called Edit cell. Such cells have the attributes set on the string itself. So search and replace for non Edit cells work. As your file contains Edit cells and this isn't a defect (the search and replace facility is designed in this way and is in this way compatible to Excel) this Issue is a new Feature request and will be handled by the requirements team. Frank
A new feature - ok. Well both me and my colleagues clearly thought of this as an error in the program. I mean it didn't do what we "told" it. That's of course a non-programmer's view of such problems (most program problems actually). Any regular user will consider it an error. Being sort of of in-between myself, I'd call it a design flaw (like most other problems I've encountered with OOffice - and of course MS office). I'm glad you acknowledge it as something missing at least :) - hope it'll be looked into soon. Generally user interfaces should of course let the user know if it - even by design - doesn't do as she/he would expect. If not, I consider it a user- interface bug. I hope in the future I can somehow figure out which problems are "by design" and categorize them correctly when I report them. Thanks for your answer. (I can recommend Jef Raskin's small interface book The Humane Interface - it's available here online: http://safari.informit.com/?XmlId=0201379376 )
setting keywords.
*** Issue 59887 has been marked as a duplicate of this issue. ***
I think there is at least one quite serious bug in this "feature". The lost of formatting (not just colors but italics and bolds) can't be undone. Only the replace operation is undone, but formatting remains lost for good. I think that any issue where user data are lost is quite serious and should be treated with appropriate priority.
If undo doesn't work I'll take the liberty of calling it a defect. I mean the formatting getting lost for good (replace not working as any user will expect is perhaps still a "feature" but I hope you can fix both as a bug now). - David
*** Issue 85004 has been marked as a duplicate of this issue. ***
Please have a look on issue 103342 too.
*** Issue 108964 has been marked as a duplicate of this issue. ***