https://bugs.freedesktop.org/show_bug.cgi?id=60306
--- Comment #23 from Markus Mohrhard <[email protected]> --- (In reply to comment #22) > I tested the patch from comment #20 (remove the copied cond format cell attr > entries) It helped to show the green border around the cell "I28" but it did > not really work. I did the following test: > > 1. I followed instructions from the comment #0 > > Result: Green border around the cell "I28" which looks promissing > > 2. Changed the data in the cell "T28" from "March 2012" to "March 2010" > > Result: It still shown the green border. > Expected result: It should remove the green border and show red strike > over the "I28" cell > because the condition is not longer true > > > Alternative test is to copy rows 65 and 66 from the source.ods. The result > is that both "I28" and "I29" cells have the green border. The expect result > is the red strike over the "I29" cell. > > Observation: It helped me to safe the "SampleTarget.ods" document as > "SampleTarget.new.ods" and > reload. > > This helped also without the patch in the comment > #20. > > => It seems that the problem is rather in refreshing > or recalculating the formatting. > > > Observation 2: If I had the patch from the comment #20, it helped me to do: > > - open "Format/Conditional > Formatting/Manage" > - select the range "I28:I29" > - press "Edit" > - press "OK" to close the edit window (no > change is needed) > - press "OK" to close the manage window > > Result: The cell "I29" become the red strike > as expected > > This does not help without the patch in > comment #20 > > => the patch in the comment #20 actually makes > a difference. Hey Petr, so let me leave some comments about the patch and why saving, closing and then reopening will always fix the problems that I fixed with the patch in Comment 20. First why save, close reopen fixes the problem: We store the information about conditional format ranges in two places: The ScConditionalFormat::maRange as a ScRangeList and inside of the cell attribute storage for fast look-up. The big task is now to keep the two in sync because for import/export and nearly all update conditional format tasks the ScConditionalFormat::maRange information is the important one. However for rendering we use for performance reasons the one in the cell attribute storage. So now why does my patch solve the problem (I have to check the problem you mentioned). The cell attribute storage stores as I mentioned the information which conditional format is applied to a cell. This is done by a vector storing an index od the conditional format (in ScConditionalFormatItem with ID ATTR_CONDITIONAL). Now when we copy&paste we copy the cell information from the old document into the paste area of the new document. This cell information also contains the old index which is not the same index as in the new document. Additionally in ScTable::CopyConditionalFormat we add the index of the copy to the the paste area but after the old index. Therefore the conditional format with the old index is evaluated first. So removing the old conditional format information in the copy&paste case is always correct and has to happen outside of the IDF_ATTRIB case as we want to clean it always. In case of IDF_ATTRIB we also copy the conditional format and add the information into the cell information by ScDocument::AddCondFormatData -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
