https://bugs.documentfoundation.org/show_bug.cgi?id=127633
--- Comment #16 from Eike Rathke <er...@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 the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
