Since I have upgraded tot LO version 5.1.2.2 my delphi code is showing a "class EOleSysError" error on the line: CreateOleObject('com.sun.star.ServiceManager'); The code has been functioning correctly up until this release.
Can you share the code? Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the code.
Created attachment 125411 [details] Code example Written in delphi 2009.
Created attachment 125412 [details] Writer demo script This script hails from the libreoffice website (http://api.libreoffice.org/examples/examples.html#OLE_examples) This script fails with an identical error, while working flawlessly on Openoffice 3.3.0
Winfried: Michael Stahl noted on IRC that you reported a similar issue on the dev mailing list. Maybe you can confirm.
I have just tested the current LO v5.1.3.2 x86, which works correctly! Yet the 64 bit version LO 5.1.3.2 x64 does not. It seems to be something to do with the 32/64 bit difference. Maby it's a compatability problem with an external DLL? (The OLE DLL)
Created attachment 125413 [details] Windows vbscript demonstrating the problem I confirm the problem. The attached Windows vbscript does run without problem on Windows 7-32 and Windows7-64 with LO version 5.0.6 installed, but does produce and error when run on Windows7-64 with LO version 5.1.3.2 installed. I don't have a machine with Windows7-32 and LO 5.1.3.2 to test.
Winfried, have you installed the 32-bit version of LO 5.1 or the 64-bit version? If it's the 64-bit version, does it work for you if you install the 32-bit version of LO 5.1 instead?
(In reply to Michael Stahl from comment #7) > Winfried, have you installed the 32-bit version of LO 5.1 or the 64-bit > version? If it's the 64-bit version, does it work for you if you install > the 32-bit version of LO 5.1 instead? Oops, I should have mentioned that. On the Windows-32 we use LO-32 and on the Windows-64 we use LO-64 bit (a script takes care of that). I will install a 32-bit version of LO5.1 on a Windows-64 machine, test and report the result.
On a Windows-64 machine, with LO 5.1.3.2-32bit installed, the vbscript in attachment #125413 [details] works fine.
okay, so it looks like this never worked in 64-bit LO. i've got no idea how this is supposed to work however... there are a bunch of registry entries added that mention "com.sun.star.ServiceManager" here: scp2/source/ooo/registryitem_ooo.scp however there is no .dll listed in that file, only soffice.exe. there is a "oleautobridge.uno.dll" built in extensions/, not sure if that is involved here? or does this use the "ActiveX" component, also built in extensions/ ? there are 2 different builds of that, for 32-bit and 64-bit... except if you build a 64-bit LO, then we ship only the 64-bit ActiveX dll...
To clarify my findings: LO \ Win 32 64 5.0-32 OK OK 5.0-64 N/A OK 5.1-32 ? OK 5.1-64 N/A FAIL (I did not test LO 5.1 32 bit with Windows 32 bit.) So the LO 64 bit version of 5.0 does work, it's 5.1 where the problem starts.
okay i think i figured out how this *should* work... https://www.openoffice.org/udk/common/man/spec/ole_bridge.html udkapi/com/sun/star/bridge/oleautomation/ApplicationRegistration.idl desktop/source/app/app.cxx, Desktop::Main() calls Desktop::OpenClients_Impl(), creates the service "com.sun.star.bridge.OleApplicationRegistration" this loads the "oleautobridgelo.dll" and creates a OleServer_Impl object. OleServer_Impl::OleServer_Impl calls provideInstance(m_smgr, OID_ServiceManager) and that OneInstanceOleWrapper_Impl::registerClass() and that calls CoRegisterClassObject(OID_ServiceManager, ... CLSCTX_INPROC_SERVER | CLSCTX_LOCAL_SERVER) OID_SerivceManager = {82154420-0FBF-11d4-8313-005004526AB4} ... not that anything there should differ between 32 and 64 bit. there are at least 2 commits in extensions/source/ole that fix 64-bit pointer truncations to 32-bit but one of them is missing in 5.1 branch and both are missing in 5.0 branch so no idea how 5.0 ever worked...
Hello, The following code : Sub TestServiceManager Set objServiceManager = CreateObject("com.sun.star.ServiceManager") Set objCoreReflection= objServiceManager.createInstance("com.sun.star.reflection.CoreReflection") Set objDesktop= objServiceManager.createInstance("com.sun.star.frame.Desktop") Dim args() Set objDocument= objDesktop.loadComponentFromURL("private:factory/swriter", "_blank", 0, args) End Sub runs with LO Win 5.1.1.3 64 bits but not with LO Win 5.1.3.2 64 bits. It seems the bug comes between this versions. All is ok with LO Win 32 bits.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c11e60f11f34b12bf73a08a96634202a8d3aef0c tdf#99643 OLE automation bridge: fix 64-bit pointer conversions It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
it breaks when retrieving the UNO service manager via OneInstanceOleWrapper_Impl::CreateInstance() okay so technically this commit "broke" it commit 120586bb305f7bd763753a3f5a8d60e25ad3db8f Author: David Ostrovsky <david@ostrovsky.org> AuthorDate: Sat Feb 20 16:47:26 2016 +0100 Commit: Michael Stahl <mstahl@redhat.com> CommitDate: Mon Feb 29 13:05:33 2016 +0100 Ole: Fix WaE specifically this change: @@ -488,7 +488,7 @@ Any SAL_CALL InterfaceOleWrapper_Impl::createBridge(const Any& modelDepObject, pVar->pdispVal= static_cast<IDispatch*>( this); AddRef(); - retAny<<= reinterpret_cast< sal_uInt32 >( pVar); + retAny<<= reinterpret_cast< sal_uIntPtr >( pVar); } } } because the caller of that function stupidly hard-codes an expected return type of TypeClass_UNSIGNED_LONG, which is sal_uInt32, but on a 64-bit platform sal_uIntPtr of course corresponds to TypeClass_UNSIGNED_HYPER. of course the pVar is not at all guaranteed to have its thrown-away upper bits all 0 in a 64-bit build, so if this worked in 5.0 it is purely by luck. fixed on master, by adapting the caller to expect hyper instead, plus fixing up several other callers and implementations of createBridge(). actually i checked again and *both* of the 64-bit pointer fixes mentioned in comment #12 are already in 5.1, so nothing more to backport.
(In reply to Michael Stahl from comment #15) > fixed on master, by adapting the caller to expect hyper instead, plus fixing > up several other callers and implementations of createBridge(). > > actually i checked again and *both* of the 64-bit pointer fixes mentioned in > comment #12 are already in 5.1, so nothing more to backport. Thanks for picking this up and for explaining the cause. Shouldn't the fix be backported to 5.2 and 5.1? As I understand it, createBridge may produce an error with all 64-bit versions from 5.1.2 up to 5.3.0.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=31f45d4c1709645ac42ff0ff7d068f681f37f675&h=libreoffice-5-1 tdf#99643 OLE automation bridge: fix 64-bit pointer conversions It will be available in 5.1.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=46960352458bde1ec9e1f2307a674de9fc3bb08d&h=libreoffice-5-2 tdf#99643 OLE automation bridge: fix 64-bit pointer conversions It will be available in 5.2.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 100661 has been marked as a duplicate of this bug. ***
When testing with Libreoffice LibreOffice_5.3.0_Win_x64 the problem unfortunately is still present.
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
Dear gobber, This bug has been in RESOLVED FIXED status for more than 6 months. If the issue is still reproducible with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/, please report a new issue in https://bugs.documentfoundation.org/enter_bug.cgi providing, if needed, the steps and documents to reproduce it. Thanks for your understanding and collaboration. Closing as RESOLVED FIXED