Hi Noel,
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:
class FindEditCellsHandler
bool operator() (size_t nRow, const ScFormulaCell* p)
{
// With a formula cell, it's considered an edit text cell when
either
// the result is multi-line or it has more than one script types.
SvtScriptType nScriptType =
mrColumn.GetRangeScriptType(miAttrPos, nRow, nRow, miCellPos);
if (IsAmbiguousScriptNonZero(nScriptType))
return true;
return const_cast<ScFormulaCell*>(p)->IsMultilineResult();
}
Would give us what we want =) although perhaps in the RangeScriptType
method it woudl be better.
How does that sound ? =)
ATB,
Michael.
--
michael.meeks@collabora.com <><, GM Collabora Productivity
Hangout: mejmeeks@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
Attachment:
flame1.png
Description: PNG image
