Apache OpenOffice Community Forum

This is my first post here, so please tell me if I'm in breach of the rules, apologies in advance! One of my clients wants to move 60 users from MS Office, MSO, to OO. I think this is a correct strategy and very interesting! This post does not concern "in application" questions, though. Please don't interpret my questions as an issue as to make OLE work within OO. I hope that what I write below is clear enough.

Background

There is a Database Client Software written for Windows 2000/XP/Vista that stores documents as OLE objects. The outline of what happens in this "document handling scheme" is that a file (often a temporary one) is picked up by the Windows software and put into a temporary OLE Container. The Container then streams the OLE Object to the database.

When a user wants to view a document there is a tiny piece of MS Office automation that marks the retrieved document as read only with DoVerb(ovShow). If the user wants to edit the document the "row" in the database containing the BLOB is locked and the OLE Container is called with DoVerb(ovPrimary).

This works nicely with MS Office, PDF (Adobe Acrobat and/or Reader, only in read-only mode) and some other OLE Server capable software.

Problem(s)

1. On a Windows machine where MS Office was never installed, the OLE Container raises an exception "Class not registered". This is because an OLE Object actually does not have a filename, but an application class "tag".

2. When MS Word is the OLE Server, if the user moves to another record the OLE Container is streamed back to the database (if in edit mode) and the Container is destroyed. Just before this OleSave is called and both Word and Excel takes care to save the changes. With OO even if we successfully stored the document, OO does not seem to react to the calls made to the OLE Container.

Questions

1. Is it be possible, as is when working from the filesystem, to let OO "kick in" or "take over" the class registration from Word, so that stored .doc-objects can be viewed and edited in OO instead of MS? I have fiddled with the setting in Load/Save to no avail.

2. Why does Write not display a "Update" option in the Archive menu like other OLE Servers when editing a document that is opened from an OLE Container? And why does it not react to the OleSave call (Win API)?

More information

Tests have been made with OpenOffice 2.3.0 Novell Edition.

A document saved/created on a machine win Office installed:
- Can be safely and fully managed by Word
- Will raise an exception on a machine without MSO with OO installed.

A document saved/created on a machine with OO installed:
- Can be opened and read with Word if installed, but will be stored and readas a temporary DOC-file and thus not safe to edit
- Can be opened and read with OO Write if installed, but will be stored and read as a temporary DOC-file and thus not safe to edit

The OLE Container is based on the VCL wrapper for Windows API, CodeGear Delphi for Win32 2007.

When the applications report engine creates an RTF document it seems to be correctly opened and streamed to the database via the OLE Container on an machine with OO alone, but it might be Write or Windows managing that alone.

Any information will be highly appreciated as a total re-write of the document handling functionality will render the saving the client intends to make void. The client is an NGO working with subsidiary projects, a non-profit organisation, that is.

Regards,

/Dany

Dany, this is a well thought out and presented topic that fits well within the scope of this forum. Unfortunately your topic falls into the "rather complex" category, so the answers may not be what you want. Also, OOo does support OLE within a Microsoft environment as can be seen from my attached DOC example, which is a simple document that embeds to OLE objects: a Word document and an OOo one. You can open this in both Word and in OOo, and if you use the latter to save it as an ODT file then this can be used to get a better insight as to how OLE encapsulation works in files. If you open the ODT file with WinZip or any equivalent ZIP utility (the easiest way to do this is by temporarily renaming the file to a .ZIP extension), then you will see that in ODF (unlike MS CBFF) the two OLE objects are just embedded files within the container, and the content.xml refers to them both in the same way.

At its simplest OLE encapsulation at a file level is simply a mechanism for embedding a byte-stream which itself forms a document of some type. Most of the OLE smarts relates to the use of standard APIs so that one OLE application can embed other types of OLE documents and that the user can seamlessly switch from one application context to the other with both applications sharing the GUI. An OLE descriptor is associated with each encapsulated OLE document. In the case of Word documents this is Word.Document which itself points to the default version (Word.Document.8 in the case of MSO 2003); and in the case of an 00o text document soffice.StarWriterDocument).

Now OOo will happily open a Word document, and if you take the above ZIP file and open Object 2 with OOo you will see that it opens the Word Document stream happily. All of the mappings for the OLE objects Word.Document* embedded in the registry. I suspect that you might be able to clone the registry declarations for Word.Document* pointing these that OOo for registration on machines which don't have MSO installed. This sort of trial set up needs to be done on a sandpit PC. I have MSO installed on my XP machines as well as OOo, so I don’t want to try out as I don't want to mess up my installation. However this is a botch at best, and therefore should only be attempted as a matter of last course.

There is even a Tools->Options setting whereby it convert any embedded MSO OLE objects and open then in OOo but only if you don’t already have the MSO OLE providers registered (which is again something that I can’t try out easily, because I have MSO installed).

The challenge that you have is that your current OLE embedding architecture is highly MS specific and uses complex MS APIs and stacks that they really don’t ant to make it easy to unroll. (See MS Compound Binary File Format).

Batch conversion using COM to relevant MSO COM Application doing a SaveAs to a filestream is easy, and migrating to a database which uses RAW stream BLOBs for encoding DOCs etc. would probably be the easiest migration path, and involve the least code integration. Any move away from OLE encapsulation to RAW stream BLOB storage would also require “wrapping” for the legacy MSO integration.

Ideally what you want to use some JiT extract utility which can extract the raw DOC streams from the There are a number of Open Source utilities to do this such as Jakarta. From what you say, you seemed to imply that you have the source code for this application. They should make life a lot simpler.

Picking up some of your specific points: for reasons discussed about you only want to consider two runtime scenarios:

• The client has MSO installed and uses MSO as the document editing vehicle.
• The client has OOo installed and uses OOo as the document editing vehicle. MSO is not installed.

Do not try to get an OOo option installed where MSO is installed or is no longer installed and the registry is not properly cleaned out.

Not sure about your “update” issue. This works fine for me in embedded mode.

The other place to try posting is in the developers mailing list. What I believe I am saying is that you are probably going to end up going down your “black scenario” of a total re-write of the document handling functionality. Sorry that I can’t be of more help.

Terry, thanks a lot for your answer.

I have tried the document in a "sandbox" and I get similar behaviour - the other way around. The odt document can be edited safely - that is the File menu displays an "Close and Return to --" and "Update --" instead of the customary filebased choices (this is my ultimate goal). For the doc object the behaviour is similar to how OOo behaves on all documents in the host machine where both applications are installed.

What I also noticed is the if i drag&drop or stream a doc or odt or rtf file to the container I'm discussing OOo/Windows/whoever creates a package ala OLE 1.0. I think this is the explanation to why I at first took for granted that OOo does not support acting as a server in Windows. Such a package will get extracted to a temporary directory and the the file will be opened through the shell. That is very not-good since the connection back to the original container is lost. As you claim, this does not seem to be the whole truth.

I have now to dig into the question of why OOs Write behaves differently than with the object in my legacy container. It seems both to have to do with how the object is placed (inserted, created) and how it is opened.

Regards,

/Dany