Created attachment 117310 [details] Test value for conditional formatting rule shifted down two rows after saving and reopening I created a conditional formatting rule applying to $G3:$G1048576. The test value was $H3. The rule worked correctly during the session in which it was created. However, when the file was saved and reopened, the rule's test value had shifted down two rows to $H5. (While I was able to edit the corrupted rule in Manage Conditional Formatting, I was unable to save the correction, as Manage Conditional Formatting's OK button is nonfunctional. A separate report has been filed for that bug.) Subsequent saves and reopens do not seem to shift the test value any further. In the attached spreadsheet, entries in the column "$ Calc" (Calculated Price, Column G) are supposed to turn red (via the ErrorInDataEntry style) if "$ Calc" is not equal to "$ Paid," indicating that there has been a data-entry error in the "Gal" (Gallons Purchased, Column E), "$PG" (Price in Dollars Per Gallon, Column F), or the "$ Paid" (Price Actually Paid, Column H) columns. I originally specified a test value of "$H3" for the specified range, which is $G3:$G1048576. The rule functioned correctly during the session in which I created it. However, saving and reopening the spreadsheet caused the test value to change from "$H3" to $H5", causing all entries in G to turn red.
Created attachment 117312 [details] Sample file modified. Hi @Peter, Go to G3 then edit conditional format, condition has $H5 not as I think must be $H3, with this change works properly. Entering a relative address the condition point to the relative position where you are where you are going to edit the condition. To avoid mistakes using relative references is better go to the first cell where conditional range begin. Save and reopen, conditions works fine for me. Please if you are not agree reopen it.
This bug is not about the error in this particular conditional formatting rule, nor about how to fix it. It is about the fact that saving, closing, and reopening the file is what introduced the error. When I created the conditional rule, it was correct and it functioned correctly. The test value was at $H3 and the range it applied to was G3:G1048576. When I deliberately introduced a data-entry error, the entry in column G turned red (because it applied a style with red text-color font effects). The other entries in column G remained black (their default style). Then I saved the file, closed it, and reopened it. All of the entries in column G were red and I saw that the conditional formatting rule's test value had changed from $H3 to $H5. I did not make this change. Something in the first save-close-reopen process did it. It appears to be a bug.
Have you open your file modified?
Yes, thank you. I am now wondering if the two bugs I filed are tied to my particular build or are the result of a corrupt install. I'm using: Version: 4.4.4.3 Build ID: 2c39ebcf046445232b798108aa8a7e7d89552ea8 Locale: en_US As I noted in the other bug report, if you successfully edited the conditional formatting rule using the same build, I will probably have to reinstall LibreOffice.
Try then resetting the user profile. https://wiki.documentfoundation.org/UserProfile
Well this is embarrassing, curious, and highly inconvenient. Resetting my profile seems to have eliminated the first bug (can't save rule edits) in both Windows and Linux, and it eliminated the second bug (rule corrupted after save, close, and reopen) in Linux. I haven't tested the second bug in Windows yet, but I have no reason to believe it's still there. I've done almost no customizing in Calc -- I only made the default fonts a little bigger, if memory serves. However, I have made extensive customizations in Writer -- macros, keyboard mods, toolbar mods, etc., etc. I guess I am going to have to try restore these piecemeal and hope that I don't inadvertently reintroduce the corruption. Thanks very much for your patience and help; I appreciate it very much. All the best.