opening a spreadsheet taking long ...
michael.meeks at collabora.com
Wed Jun 3 08:20:16 UTC 2020
Switching this to the public dev list - it prolly belongs there and
re-attaching your profile; even if the document is not publishable.
On 03/06/2020 08:32, Noel Grandin wrote:
> So the problem here is the dreaded GetOptimalHeights problem, which
> triggers tons of formula work.
Oh - that is rather silly. The 'script type' detection thing looks like
a madness to me - we shouldn't need to calculate the formula to detect
its script type.
Breaking UpdateScriptType -> GetString
might be good; but I think we can do better.
I suspect that we should annotate shared formulae in mode detail - we
spend some time scanning them anyway for various other conditions on
load and elsewhere - to determine if the root formula can return a
string or not.
if we have SIN(), SUM(), AVERAGE() or some simple arithmetic operators
at the bottom [ we can scan the RPN backwards for the root node ] -
there are really only ~10 formulae that are used in anger in most
spreadsheets - we can be sure that the result will be either numeric, or
an #ERR123 type thing.
In either case - it will not have some complex script type. It strikes
me that adding this intelligence to:
bool operator() (size_t nRow, const ScFormulaCell* p)
// With a formula cell, it's considered an edit text cell when
// the result is multi-line or it has more than one script types.
SvtScriptType nScriptType =
mrColumn.GetRangeScriptType(miAttrPos, nRow, nRow, miCellPos);
Would give us what we want =) although perhaps in the RangeScriptType
method it woudl be better.
How does that sound ? =)
michael.meeks at collabora.com <><, GM Collabora Productivity
Hangout: mejmeeks at gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1087566 bytes
Desc: not available
More information about the LibreOffice