Hi Daniel,
On Wed, 2008-12-10 at 09:30 +0100, Daniel Rentz wrote:
Kohei Yoshida schrieb:
Hi Eike,
On Tue, 2008-12-09 at 20:41 +0100, Eike Rathke wrote:
If there isn't any,
wouldn't it be natural to share the filter's name mapping with VBA?
Absolutely, and that's what I envisioned too.
What we seem to disagree is where to keep the shared filter name mapping
instance. For me, it seemed natural to keep it with ScCompiler, the
same way we keep the various address convention code within that class,
and have it shared by xls import/export filters and VBA parser.
But you prefer the opcode mapping outside the core, in oox. That would
work fine for the filters (once the export filter moves to oox). But
once VBA gets into the mix, it becomes a little ugly since the VBA code
is still in sc.
It may not be enough to add a mapping in the sc core. In oox there is
some postprocessing code executed for each formula which takes care of
e.g. missing/unsupported function parameters, add-in/external function
handling etc. Would it be an option that the oox module offers the xl
formula parser as a special UNO service that implements the
com.sun.star.sheet.XFormulaParser interface? So it would be possible for
any module to instanciate and use such a parser.
Let's say we agree to keep the opcode mapping outside the core (after
all, it's already done). But the problem, at least in the short-term,
is to
1) refactor VBA to use the FormulaParser API instead of using ScCompiler
directly (like it does now).
2) move the xls opcode mapping out of oox to a place where it can be
accessed both from oox and sc.
I want to keep all filter related stuff in one module, so I think my
idea using a service may be a bit better ;-)
That's definitely a strong option to consider. Thanks for your
suggestion. :-)
Anyway, for whatever we decide to do to make all this work would
definitely take a non-trivial amount of time and effort, so for now,
I'll just take out the change I've made (the change that started this
whole thread), to keep the xls opcode out of sc.
We'll then come back to this at a later time (probably post-3.1) to
solve it to make everyone happy.
Kohei
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
