[Libreoffice-ux-advise] [Bug 127633] Relative Cells

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Wed Oct 2 21:05:16 UTC 2019


https://bugs.documentfoundation.org/show_bug.cgi?id=127633

--- Comment #16 from Eike Rathke <erack at redhat.com> ---
(In reply to Rick C. Hodgin from comment #14)
> 3)  A post-processing step on UI presentation, where the actual formula for
> the cell is processed to reference !!native cells (like !!A1 for the real
> A1), and to take anything in the visible range and PRESENT IT as a relative
> name.
You mean you want to re-parse the formula string generated from tokens and
present it differently? Sounds error-prone to me.

> 4)  A pre-processing step on the syntax parser for formula input, that does
> the reverse of 3), making the relative values be real values.
Same here, pre-processing a string to produce another string is an error-prone
overhead.

> 5)  A new flag in the saved ods file indicating if the sheet's in relative
> view or not.
I'd not save/load that to/from file. It would be utterly confusing to a user
loading such document if not familiar with the feature/syntax.

> This could be implemented as a visible-at-the-UI-level change only, with
> post- and pre- processing code injected in 3) and 4) as indicated.
You'd have to re-implement a lexicalizer just to handle the cell reference
bits. But maybe I'm missing something in your idea.

Anyway, if that's the approach to go then probably post-processing should take
place in sc/source/ui/view/tabvwsha.cxx ScTabViewShell::UpdateInputHandler()
line 669 where rCell.mpFormula->GetFormula(aString) is called. The
pre-processing probably in sc/source/ui/view/viewfunc.cxx
ScViewFunc::EnterData() that detects a formula entry and
ScViewFunc::EnterMatrix().

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Libreoffice-ux-advise mailing list