<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> On 06/01/2012 02:56 AM, Daniel Bankston wrote: <blockquote cite="mid:4FC875B5.6040703@gmail.com" type="cite"> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> I think before I can move forward, I need to know what to do about ScMyTables::IsMerged(), ScMyTables::DoMerge(), and ScMyTables::UnMerge().  ScMyTables references its own merge methods, but I'm not sure what would cause these methods to be actually be called.  They aren't called on the test files I've tried so far.  As we have discovered, the merge methods in ScXMLTableRowCellContext are called, though.  What do you sc gurus think? I need to figure out what to do with the merge methods because the ScMyTables add/new/insert row/column methods reference the ScMyTables merge methods (although the code path that references them never seems to be taken.) <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </blockquote> Hi, Kohei and Markus, With the attached diff (diff to the latest pushed commit on feature/gsoc-calc-perf), I was able to build and open my test ods files with merged cells and content without problems.  The patch removes the ScMyTables merge methods and adjusts the add/new/insert row/column methods.  The big thing here is in ScMyTables::InsertColumn/Row(), there is a for loop that never seems to be entered that contains calls to IsMerged() and UNO interfaces.  If the logic in the for loop isn't needed, then ScMyTables::InsertColumn/Row() is unnecessary, and we can just directly call ScMyStylesImportHelper::InsertCol/Row() from ScMyTables::NewColumn/Row(). I won't commit this until you guys have had a chance to give input and guidance on it. Respectfully, Daniel Bankston </body> </html>