Re: [Libreoffice] How to call from one component to another (sw->starmath)

On Mon, 2011-08-15 at 17:16 +0200, Lubos Lunak wrote:
> Hello,
>
>  I'm implementing .docx OOXML support for writing math formulas. As this is 
> something that could be used not only by Writer but also by other components, 
> I want to implement the writing of the formula in Starmath. And even if I 
> didn't want, Sm* classes (which implement and store the formulas) are in 
> starmath/ , and sw-starmath do not link against each other.
>
>  So, the question is, how do I call from sw to starmath without linking them 
> together? I checked how the binary .doc filter does it, and it goes via ~10 
> calls deep [1] that call some UNO interfaces and

> store the result in some private stream or whatever.

SvxMSExportOLEObjects::ExportOLEObject seems to have blown out of
control but the first and last branches are the typical ones. If it's a
generic object then copy it's storage under the destination storage
unchanged. If it's one of the special things that have an analogue in
the destination format save it to a temporary storage in another format
and copy that into the destination format instead.

//export to temporary stream "pStream"
::uno::Reference < io::XOutputStream > xOut =
new ::utl::OOutputStreamWrapper( *pStream );
aSeq[0].Value <<= xOut;
xStor->storeToURL( ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "private:stream" )), aSeq ); 

//copy result to destination ole2 storage
SotStorageRef xOLEStor = new SotStorage( pStream, sal_True );
xOLEStor->CopyTo( &rDestStg );

> I already have a pointer to SmModel and SmDocShell (I can get it the same way 
> the .doc code does) and just need to call their method, passing the XML 
> serializer object as an argument, that's it.

Probably matters what the destination format is like ? Is it a
standalone thing and/or exists in a substorage/folder of the parent
format where it doesn't care about what it is inside ? i.e. I'd sort of
expect to basically just add another export filter to starmath for
whatever that format is, add it to SmDocShell::ConvertTo and call that
directly/indirectly. And have a save as... entry for the format if it
makes sense to have it standalone ?

That's not going to work if the destination format needs hooks back into
its surrounding container. Is that the problem ?

C.