Apache OpenOffice (AOO) Bugzilla – Issue 76242
carsh when do "optimize"--"Distribute columns enevly" in nested tables
Last modified: 2013-08-07 14:42:39 UTC
After inserting a table in another table, carsh occurs when do "optimize"-- "Distribute columns enevly". The bug can be described as follows: 1.Create a new writer document; 2.Insert a 5 x 5 table; 3.Locate the cursor in the first cell, repeat the operation according to step 2; 4.Select two or more neighboring cells in the outer table other than the first cell; 5.Click "Optimize" in the table toolbox, and then click "Distribute Columns Evenly", crash.
MRU->FME: as described, when having nested tables and distributing the neighbor cells evenly, Writer crashes.
When do "optimize"--"Distribute columns enevly" in nested tables, the cause of crash is aWish[i] in SwDoc::AdjustCellWidth in file sw\source\core\docnode\ndtbl1.cxx. In the case of nested tables, the value of "nCnt" is 0. So when do "nWish /= nCnt", writer crash. For the sentence int nDiff = aWish[i] in case of nested tables, nDiff is always 0. So, I think the reason is the value of aWish[i]. I want to know its value is from where? And the meaning of aWish[i] is what? anybody can give me some introduction?
aWish contains the 'wished' column widths referring to the width of the contents of the cells. In my opinion these values are only useful if the optimal column width should be calculated. For a simple 'space equally' operation, the algorithm should be straightforward: Sum up the column widths and divide by the number of columns. Anyway, the algorithm as implemented there works, except from a bug in lcl_CalcColValues: pTab->FirstCell() gives us a cell frame from the outer table. At the end of the loop, pCell = pCell->GetNextLayoutLeaf() gives us a cell frame in the inner table which causes the while loop to be finished (leaving aWish with to little values, resulting in nCnt = 0). IMHO, all cell frames of the inner table should be skipped and the while loop should continue with the next cell frame of the outer table. Hope this helps.
fme->lijian: Do you like yo take over?
lijian->fme: Yes, I have done some work on this issue. I'd like to take over it. I'll continue to maintain my attention on this.
lijian->fme: I have repaired this bug,please have a look at the patch file.
Created attachment 45211 [details] the patch file
I'll have a look.
Block meta issue
lijian->fme:Hi frank,have you looked at the patch file? Is the patch I submitted reasonable? Look forward to your reply.
fme->lijian: Thank you for your patch. I would suggest to fix this bug in lcl_CalcColValues instead of fixing it in ImplNextLayoutLeaf(), because NextLayoutLeaf() is also called from a couple of other functions, therefore a more local fix would reduce the risk of regressions.
lijian->fme:I have submitted a new patch for this issue. Please have a look at it. Well, I think I should make some explanations first. I agree with you that fixting it in lcl_CalcColValues is safer, but we must make some changes to the call of GetNextLayoutLeaf(), I think. Because function GetNextLayoutLeaf() returns the wrong layoutfrm-inner table cell and we should not change GetNextLayoutLeaf(). So I writer a new function GetNextLayoutCell() same as GetNextLayoutLeaf() except those changes in my last patch. What do you think of the new function I write ? Expect your reply.
Created attachment 45387 [details] a new patch file
fme->lijian: I'd prefer not to introduce a new function for this very special purpose. Instead I suggest to keep the call of GetNextCellLeat() bug skip any cells we do not want to process. So we could change the while(..) condition to while ( pCell && pTab->IsAnLower( pCell ) ) to prevent the while loop from breaking if GetNextCellLeaf() brings us to the inner table. Additionally we would have to adjust the if(...) condition right after the do{ to skip any cells that have a different upper table cell than pTab. This would be a minimal code change and should do the job. What do you think?
lijian->fme:Thank you for your kindly reply. I have totally understood what you mean, and agree with you very much. I've made a new patch according to your suggestions. I think this one may be appropriate. Please have a look.
Created attachment 45451 [details] the patch file
fme->lijian: Thank you for your patch. Looks good to me. Did you already do some testing, checking your patch with various table-in-table and common situations? In this case I'll add it to cws swqbf97.
lijian->fme:For this patch, I have tested it as much as I can. It works fine so far.Thank you for your concern.
fme->lijian: Thank you. I applied your patch to cws swqbf97, ndtbl1.cxx rev. 1.16.278.1.
FME: Ready for QA.
Verified fix in CWS swqbf97.
.
Checked in OO 2.3 dev build 680m221.