Hi Felix,
So after the changes that we have discussed on IRC meeting are ready,
the next step would be to let the start_office() method return
uno::Reference< lang::XMultiServiceFactory > that represents the service
manager of the office ( can be retrieved from XComponentContext object
using XComponentContext::getServiceManager() method ).
The service manager should be provided to the dispatchMsg() method. It
will be used there as an argument to New_Instance() method, this method
creates a new SoPluginInstance object. The old implementation connects
always from the SoPluginInstance::Connect method, from my point of view
it makes more sense that the instance gets the service manager in
constructor, since the service manager is retrieved on connection. As
Result the Connect method should be removed from the SoPluginInstance class.
The questions, suggestions are welcome.
Best regards,
Mikhail.
Mikhail Voitenko wrote:
Hi Felix,
Zhang Xiaofei wrote:
Hi Mikhail,
Thank you so much for asking, after our last meeting I find there are
still a couple of questions.
- In the bootstrap() example in cppuhelper there is the piece of code
starting from calling of cppuhelper_detail_findSofficePath() and ends
with a conditional calling of Bootstrap::set(), from what I can see
all the local defined variables involved here are not referred in the
following, so could I assume the bootstrap setting has already been
made and can take effect via some implicit mechanism?
This source code sets the correct value to the "path" variable ( that is
used for the office startup in osl_executeProcess() ), and sets
URE_BOOTSTRAP environment variable.
The documentation in sal/inc/rtl/bootstrap.h looks quited detailed,
even though I'm still confused. What is more, is this a necessary part
when it comes to our reimplementation?
It looks not to be necessary in our case to set URE_BOOTSTRAP variable.
But the path to the executable is necessary for osl_executeProcess()
call ( actually it is already retrieved even in current plugin
implementation ).
- As I can remember, you have mentioned on different platforms there
could be different implementations, in the example however, I can see
all are done by simply passing the arguments to osl_executeProcess() -
no fork(), no execl(), no windows pipe functions, maybe the work has
been done in sal module and we need not do that any more?
Yes, you are right, using of osl_executeProcess() will minimize the
difference between the implementations comparing to the current
situation. But it will not remove the difference completely, for
example, the way to look for the program directory is still different on
Windows and Unix.
Best regards,
Mikhail.
Thanks and Best Regards,
Felix.
Mikhail Voitenko
Hi Felix,
How is it going with the office startup reimplementation? Does the
approach we have discussed on IRC meeting work?
If there are any questions please do not hesitate to ask.
Best regards,
Mikhail.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
