Hi, >>What I actually wonder about is that python within the office process >>still works, do you move from pyuno.dll to pyuno.pyd or do you create a >>copy ? > > > create a copy . this is not correct, because you may end up with both pyuno.dll and pyuno.pyd loaded into the same process, which will proabably crash sooner or later.
> >>The pythonloader.dll is linked to pyuno.dll via the import lib. >>This should fail, as the pyuno.dll is not there ? This needs to be solved. > > > yes, I think so. > > so when I move from pyuno.dll to pyuno.pyd , there is something worng when I > run "dmake runtest" . yes, the pythonloader.dll is linked to pyuno.dll. The standard windows import lib mechanism looks for pyuno.dll only and will not find a pyuno.pyd. There are 2 ways to solve this. - The build process itself must create a pyuno.pyd instead of a pyuno.dll. The created import lib will then look for a pyuno.pyd. - create a wrapper pyuno.pyd shared library, which has only one method (initpyuno()), the implementation of the method loads pyuno.dll dynamically (using win32 LoadLibrary() function) and calls the initpyuno() function implemented in pyuno.dll. pyuno.pyd thus would just be a proxy for pyuno.dll Maybe the second step is a little easier to implement. There is a special handling already for the unix pyuno shared library (see the PYUNO_MODULE target in the makefile and the pyuno_dlopenwrapper.c source file). Bye, Joerg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
