Apache OpenOffice (AOO) Bugzilla – Issue 117010
oo 3.3 oleautobridge.uno.dll is buggy
Last modified: 2017-05-20 10:31:55 UTC
steps to reproduce: - open attached "textfield_demo.odt" - press button - msgbox will show textfields -> oo basic is ok - edit "file:///E:/textfield_demo.odt" in attached "textfield_demo.vbs" to your needs and save - open "textfield_demo.vbs" - vba macro will now fail with an error message german: Die Variable verwendet einen Automatisierungstyp, der von VBScript nicht unterstützt wird. -> it was ok in oo 3.2 btw: if you use "oleautobridge.uno.dll" from OO 3.2 it will work ;-)
Created attachment 75870 [details] textfield_demo.odt
Created attachment 75871 [details] textfield_demo.vbs
setting keywork "regression"
ab->jl: related to oleautobridge.dll, please have a look
.
I checked this with OOO330m19 and OOO330m20. In both cases the macro contained in textfield_demo.vbs executed successfully. That is, the document was loaded and the message box showed up two times displaying the text com.sun.star.text.TextField.DocInfo.CreateDateTime Clicking on the button did not execute the macro in the document. Opening the script in the document and executing it showed a message that it will not be executed for security reasons. I set the macro security to low beforehand. Maybe this is another problem or it works by design. @AB: Can you answer this? @Brinzing: I cannot confirm the described problem.
adding AB to CC.
> That is, the document was loaded >and the message box showed up two times displaying the text this is strange, i just did the following: - installed OO 3.2 inside a clean Win XP 32 SP3 VM result: "textfield_demo_2.vbs" will work as expected - reset VM, installed OO 3.3 result: "textfield_demo_2.vbs" will not work - see attached "error_message.gif" - copied "oleautobridge.uno.dll" from OO 3.2 into OO 3.3 program folder result: "textfield_demo_2.vbs" will work now... > Clicking on the button did not execute the macro in the document. try with new attached "textfield_demo_2.vbs", loading with "MacroExecutionMode = 4" will fix this problem...
Created attachment 76005 [details] E:\textfield_demo_2.vbs
Created attachment 76006 [details] error_message
@eberlein: i know you can confirm this issue too ;-)
Yes, can confirm.
*** Issue 117523 has been marked as a duplicate of this issue. ***
Created attachment 76880 [details] OpenOffice_LibreOffice_oleautobridge_bug.7z This project fail in 3.3.0, 3.4beta1, LibOO too It only works on 3.2.1 and below
I have posted my find in a LibOO ticket here : https://bugs.freedesktop.org/show_bug.cgi?id=38441 (Bug 38441 - OLE: broken SAFEARRAY VType (oleautobridge.uno.dll) In short, the project I have posted "OpenOffice_LibreOffice_oleautobridge_bug.7z" is failing to run on OOo 3.3.0, OOo 3.4beta1, LibOO 3.4.3 It only works on OOo 3.2.1 and below LibOO confirmed the issue and I hope you will patch it because I'm afraid to see still failing on your OOo 3.4.* branch, how to resize columns from outside OOo/LibOO then if you don't dare patching this more seriously.
I don't understand why this report has status RESOLVED FIXED. I fully confirm what is said by various users : the OLE bridge is not usable at all. Here is a simpler example in VBScript. It opens a new Writer document, displays a simple message, then tries to get the array of available services names and display the first one. It's OK with OOo 3.2.1 and older, including OOo 1.1.x. It bugs with OOo 3.3 and its derivatives. On a Windows system, just double-click next attachment. Dim OpenOffice, Desktop Dim myDoc, supportedServices Set OpenOffice = CreateObject("com.sun.star.ServiceManager") Set Desktop = OpenOffice.createInstance("com.sun.star.frame.Desktop") Set myDoc = Desktop.loadComponentFromURL("private:factory/swriter", "_blank", 0, Array() ) MsgBox "Look ..." supportedServices = myDoc.SupportedServiceNames MsgBox "First service = " & supportedServices(0) myDoc.close(True)
Created attachment 76896 [details] VBScript showing the bug. Double-click to run it on a Windows OS..
@bmarcelly: the fix for this is apparently in CWS jl166. this CWS was apparently not ready in time for the beta, but it has 3.4 target. unfortunately it turned out that this CWS breaks the smoketest, so unless somebody (not me) does some work on it it won't be in the OOo 3.4 release. but over at LO there is now an independent fix for this, see: https://bugs.freedesktop.org/show_bug.cgi?id=38441
setting from "resolved" to "unconfirmed", cause this bug is still present in aoo3.4m1 revision 1226179 (http://people.apache.org/~arielch/packages/) btw: https://issues.apache.org/ooo/show_bug.cgi?id=118503 seems to be a dup of this issue
Thanks to Michael Stahl hint, the fix for this issue is found in cws jl166: http://hg.services.openoffice.org/cws/jl166/rev/00bf0ef35ffa Fixing the issue introduced by http://hg.services.openoffice.org/cws/jl166/rev/27974ced5167 The patch can be applied safely, independently from all the other cws changes. Tested with the attached VB scripts, they all work.
*** Issue 118503 has been marked as a duplicate of this issue. ***
Created attachment 77111 [details] cws jl166 patch: #i117010# default conversion of sequences is now again SAFEARRAY of VARIANTs cws jl166 patch: #i117010# default conversion of sequences is now again SAFEARRAY of VARIANTs author Joachim Lingner <jl@openoffice.org> Tue Mar 15 14:24:01 2011 +0100 (10 months ago) changeset 275627 00bf0ef35ffa parent 275626 0b716817fec5 child 275628 795ebf68a524
Fixed in revision 1229372 If someone is interested in testing, you can try this build: http://people.apache.org/~arielch/packages/win/OOo_3.4.0_Win_x86_install_en-US.exe Note that it is not a Developer Snapshot, so it will override any default installation.
*** Issue 118032 has been marked as a duplicate of this issue. ***
Apache OpenOffice 3.4 has been released. Could someone please verify this issue is solved in the current release? You can download Apache OpenOffice from http://www.openoffice.org/download Thanks in advice.
Sure I'm setting up some virtual machine environnement, if I have enough time I will post my result tommorrow on VB6 and VB.NET or if I can't this will be next monday/tuesday because we are not working thursday to monday The last time I checked 3.4.0 it was the release of 23042012, it was still buggy but I had just checked in .NET with the method of linking cli_basetypes, cli_cppuhelper, cli_oootypes, cli_ure, cli_uretypes dll libraries If you need more hints, it had failed on a simple OpenFile procedure Private Shared Sub OpenFileInternal(ByVal file As String, Optional ByVal hide As Boolean = False) Dim localContext As XComponentContext = Bootstrap.bootstrap() Dim multiServiceFactory As XMultiServiceFactory = localContext.getServiceManager() Dim componentLoader As XComponentLoader = CType(multiServiceFactory.createInstance("com.sun.star.frame.Desktop"), XComponentLoader) Dim xComp As XComponent = componentLoader.loadComponentFromURL(PathConverter(file), "_blank", 0, New PropertyValue() {New PropertyValue("Hidden", -1, New Any(hide), PropertyState.DIRECT_VALUE)}) End Sub This was working without parameters, but with the Hidden parameter it was complaining Invalid cast, 3.3.0 clis the same, the only working cli have found for the moment was 3.2.1 But now 3.4.0 release is out I will let you know if it persists
The VBScript provided on 2011-10-17 (attachment 76896 [details]) works for me on Apache OpenOffice 3.4, on Windows XP SP3. Other users have reported COM Automation works now: http://www.oooforum.org/forum/viewtopic.phtml?t=159142&highlight= http://user.services.openoffice.org/en/forum/viewtopic.php?f=44&t=38253#p234374
it's fixed - my external delphi components works too
I confirm it is fixed in the 3.4.0 release, my OLE automation works again.
NOT FIXED, I have done one full day of extensive tests and my results : it's not fixed and not stable at all Test environnement : -------------------- Vmware virtual machine with fresh XP SP3 Install up to date The virtual machine as 3 snapshots made just after the installation of OpenOffice 3.2.1, 3.3.0 and 3.4.0 (all releases) Code used to test : ------------------- A simple OpenFile() method posted in comment #28 TEST RESULTS: ------------- cli 3.2.1 + ooo 3.2.1 = OK cli 3.2.1 + ooo 3.3.0 = OK cli 3.2.1 + ooo 3.4.0 = OK cli 3.3.0 + ooo 3.3.0 = OK cli 3.3.0 + ooo 3.2.1 = FAILURE cli 3.3.0 + ooo 3.4.0 = OK cli 3.4.0 + ooo 3.2.1 = FAILURE cli 3.4.0 + ooo 3.3.0 = FAILURE cli 3.4.0 + ooo 3.4.0 = OK CONCLUSION: ----------- the cli version 3.2.1 are still the most stable to redistribute because they work with the 3 actual latest releases of OpenOffice to me cli 3.4.0 is just fixed for OpenOffice 3.4.0, but that's not enough , I would like cli to be cli 3.4.0 + ooo 3.2.1 = OK cli 3.4.0 + ooo 3.3.0 = OK cli 3.4.0 + ooo 3.4.0 = OK -- It's still buggy
Do you plan to fix the backward compatibility of 3.4.0 clis in futur versions of OOo ?