Using OO as an OLE Server
Posted: Tue Mar 04, 2008 6:11 pm
Dear friends!
This post is based on another thread called "OO contra MS Word as OLE Servers, OLE Server problems" in witch "TerryE" provided some useful stepstones and kindly asked me to take the issue here.
As far as I can tell - after some more experimenting - Writer and Calc serves as a pretty good OLE servers on the condition that the object is a native OO-object (when it/Windows can identify itself with the OLEClassName in the object).
My problems start to arise when I try to manipulate MSO (Microsoft Office) objects. Whether creating a new empty OLE Object or creating one from a file, if MSO is not installed on the system, Windows creates an OLE 1.0 Package. These Packages are no good at all since Windows will put the packaged files in a temporary folder and then open whatever software is associated via the shell. The result is that the "connection" back to the original document source (the OLE Container) is lost and thus also any changes made by the user. Another problem is already stored/created document - when an existing OLE Object is of the "Word.Document.X" class windows will throw an "Class not registered" at such an early phase that it seems impossible for me to pitch in and "hack" the classname.
In an organisation that is moving from MSO to OO where all operations are filebased I assume that you can start uninstalling MSO successively since OO takes care of compatibility when users depend on file associations. Many of our users depend on documents in OLE Containers and because of this the only viable scenario seems to be to install OO on *all* machines, uninstall MSO on *all* machines and then convert the entire base of documents stored in this manner from .doc to .odt, .xls to ... and so on (though that would happen inside a program on a machine with both office suites). This strikes me as impossible.
The solution could be
1. Be able to fool windows OLE handling that "Word." and "Excel." OLE Classes should really be managed by OO. TerryE writes about this suggesting that I might be able to "clone the registry declarations for Word.Document.*". That sounds nice and I did some trials in a sandbox to no avail. I know how to import/export from regedit but this strikes me as an approach where one would need some more tools and knowledge.
2. Be able to "pinch in" and reroute whatever is going to happen before the objects DoVerb methos is called. The reason I'm mumbling about this is that in my trials, the document TerryE sent me (with one odt-based object and one doc-based object) works good enough from OO itself. When I double click the .doc object Write opens the object in read-only mode. If I could get my application to to that it would be good enough!
In the same "senario" my application today passes on Windows "Class not registered" exception. It looks like I can get the ClassID (CLSID) but when asking for the classname I get the same exception. If I could identify a MDO document at this point "all" I would need is an example of how to open an OO program, handling it a stream (the OLE Object) and making it display the document as read-only.
The most beautiful solution would of course be to have OO kick in for all MSO objects and treat them as it treats .doc files meaning that depending on some settings in OO put them back into the OLE Container with OLEClassName untouched. To clarigy; to have Writer opened in full OLE 2.0 mode (No filename in the title area and "Close and return to.." and "Update..." in the Archive menu).
I probably wrote too much, and apologize. Hope I'm being clear enough, though.
Regards and lots of thanks,
/Dany
This post is based on another thread called "OO contra MS Word as OLE Servers, OLE Server problems" in witch "TerryE" provided some useful stepstones and kindly asked me to take the issue here.
As far as I can tell - after some more experimenting - Writer and Calc serves as a pretty good OLE servers on the condition that the object is a native OO-object (when it/Windows can identify itself with the OLEClassName in the object).
My problems start to arise when I try to manipulate MSO (Microsoft Office) objects. Whether creating a new empty OLE Object or creating one from a file, if MSO is not installed on the system, Windows creates an OLE 1.0 Package. These Packages are no good at all since Windows will put the packaged files in a temporary folder and then open whatever software is associated via the shell. The result is that the "connection" back to the original document source (the OLE Container) is lost and thus also any changes made by the user. Another problem is already stored/created document - when an existing OLE Object is of the "Word.Document.X" class windows will throw an "Class not registered" at such an early phase that it seems impossible for me to pitch in and "hack" the classname.
In an organisation that is moving from MSO to OO where all operations are filebased I assume that you can start uninstalling MSO successively since OO takes care of compatibility when users depend on file associations. Many of our users depend on documents in OLE Containers and because of this the only viable scenario seems to be to install OO on *all* machines, uninstall MSO on *all* machines and then convert the entire base of documents stored in this manner from .doc to .odt, .xls to ... and so on (though that would happen inside a program on a machine with both office suites). This strikes me as impossible.
The solution could be
1. Be able to fool windows OLE handling that "Word." and "Excel." OLE Classes should really be managed by OO. TerryE writes about this suggesting that I might be able to "clone the registry declarations for Word.Document.*". That sounds nice and I did some trials in a sandbox to no avail. I know how to import/export from regedit but this strikes me as an approach where one would need some more tools and knowledge.
2. Be able to "pinch in" and reroute whatever is going to happen before the objects DoVerb methos is called. The reason I'm mumbling about this is that in my trials, the document TerryE sent me (with one odt-based object and one doc-based object) works good enough from OO itself. When I double click the .doc object Write opens the object in read-only mode. If I could get my application to to that it would be good enough!
In the same "senario" my application today passes on Windows "Class not registered" exception. It looks like I can get the ClassID (CLSID) but when asking for the classname I get the same exception. If I could identify a MDO document at this point "all" I would need is an example of how to open an OO program, handling it a stream (the OLE Object) and making it display the document as read-only.
The most beautiful solution would of course be to have OO kick in for all MSO objects and treat them as it treats .doc files meaning that depending on some settings in OO put them back into the OLE Container with OLEClassName untouched. To clarigy; to have Writer opened in full OLE 2.0 mode (No filename in the title area and "Close and return to.." and "Update..." in the Archive menu).
I probably wrote too much, and apologize. Hope I'm being clear enough, though.
Regards and lots of thanks,
/Dany