Am 05.08.2011 18:15, schrieb Mathias Bauer:
On 05.08.2011 17:21, Armin Le Grand wrote:
Hi Mathias,
Am 05.08.2011 16:25, schrieb Mathias Bauer:
On 05.08.2011 13:33, Armin Le Grand wrote:
[1] Do the not too difficult step of making binfilter independent from
the rest by statically linking, keep it on the current version. Use the
resulting binary module for future versions.
As long as binfilter runs in the same process, you can't link it
statically against vcl.
Yes, right. Thanks for the hint. Thus, the remaining missing stuff has
to be stripped and added in the binfilter way. Worth a try... When will
we have code...?
Adding a copy of vcl to binfilter won't help as you can't have two
instances of the vcl Application class (including its pseudo-static
data).
...whereby the binfilter version would be in the binfilter namespace.
Maybe there is a creative way to have a vcl Application class in the
binfilter namespace.
The only way to solve the problem would be reimplementing the vcl
based part of binfilter so that is only uses a stable API to vcl code.
I had more in mind to implement the still needed parts. Should be
(hopefully) not too much, painting and other stuff is completely
removed, thus the static data should be not needed in most cases or
being replacable. The second depends on a try I guess. We will never be
able to guess all needed stuff by discussing.
This could be achieved by using UNO APIs where possible and defining the
remaining used C++ APIs as "stable". "stable API" means: defining a time
period where they are guaranteed to remain compatible so that binfilter
does not need an update even if the office version is changed.
Too dangerous, I would not try that.
Of course
that would be quite some work to do as binfilter surely uses a lot of
vcl code here and there.
Hopefully not :-)
Regards,
Mathias
Regards,
Armin
--
ALG
