Tobias Himstedt wrote: > >> oleClientSite = new OleClientSite(oleFrame, SWT.NONE, > >>"opendocument.WriterDocument.1"); > > > > > > That pretty much looks like OLE stuff. > > Yes, internalay this oleClient.save method results in a JNI which in > turn calls a OleSave function (where ever that comes from).
OleSave is a Windows API call that can be used to retrieve the stored content of an embedded OLE object. >> The appearance of the filter dialog (as mentioned in your first mail) >> seems to tell us that the file misses a proper MediaType. Is there a >> manifest.xml with the correct type added? > > No this is missing too. OK, that explains why you get the dialog. It should load in OOo1.1 and later developer builds of OOo2.0 though if you select the correct filter. >> To my knowledge the file stream OO stores into the OLE storage is a >> complete OOo document, so it's a miracle to me how something can get >> lost. Maybe SWT manipulates the file?! > > Unlikly as SWT does not know any internals of the embedded document and > why should it just pick out the manifest.xml? I puzzled about this. If OOo documents are embedded as OLE servers they store themselves as OLE storage that contains a stream named "package_stream" and contains the whole zip file as usual. So an OleSave should give you the OLE storage (that does not look like a zip file, so it's not what you obviously got). Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
