Forum > FPSpreadsheet

Precedents and Dependents

<< < (2/2)

You are asking for memory leaks with such code, why not:

--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---procedure Precedents(aFormula : tSFormula;var mylist:TStringlist);  if assigned MyList then  begin    MyList.Duplicates := dupIgnore;    aFormula.Parser.IterateNodes(@CollectCells, MyList, nil);  end;

What is your intention? To optimize formula calculation? For this purpose each cell should contain a list of the formulas which reference this cell. So, when this specific cell is changed, the formulas are known which must be recalculated (rather than all as it happens currently).

I refrain from adding additional information to the cell records (TCell) directly because users sometimes have huge spreadsheets and every byte added to the cell record adds to the overall memory load multiplied by the number of cells even if that new feature is needed only by a single cell.

The worksheet already now has several AVLTrees for various purposes: Cells, formulas, cells, hyperlinks. In each of these trees the required information is addressed by means of the row and column indices.

Maybe there should be a new FormulaCalculationTree. Each items in this tree should contain a list of pointers to the formulas which use the associated cell. So, when a formula is entered it is parsed and at this moment it is known which cells are needed by it (similarly as shown in the previous post). Then the formula should be added to the FormulaCalculationTree for each of these cells. When a formula is edited the old formula must be parsed so that it can be deleted from all FormulaCalculationTree items. Likewise, when a formula or cell is deleted.

@Thaddy, Sure, it is safer, however I am used to generating new class instances and destroying them in the calling routine. If I do not destroy it in the calling routine then it is a (smaller though) memory leak.

@wp, I have some spreadsheets, where columns should look like identical, but sometimes (beyond my control) the same purpose cells are entered into different rows in different columns. So, I try to find if cell1(row1, column1) is the "same" as cell2(row2<>row1, column2<>column1), so make a lot of iteration to "guess" it. One step of the guessing is to check if they add to the same row. E.g. C10 is +C12+C15 and D10 is +D12+D25, so it is likely (a lot of other checks are also done) that C15 and D25 are the same purpose, so I can merge row 25 into row 15. So when I compare C15 and D25 during the guessing, I check where they add into. Now for C15 I iterate all functions (only in column C though) to see that it is C10 where it adds into, and so for D25 to find D10. This step I thought to simplify by a quicker step to find the descendants. Anyway, it is a great package and with one extra iteration I can do it.


[0] Message Index

[*] Previous page

Go to full version