Created attachment 57152 [details] C# source code Calling method getDataArray fails in LibreOffice 3.4.4, 3.4.5, 3.5.0 but succeeds in LibreOffice 3.3.3, 3.4.1, 3.4.2, 3.4.3. I am using this C# code: --------------------------- Type tServiceManager = Type.GetTypeFromProgID("com.sun.star.ServiceManager", true); object servicemanager = System.Activator.CreateInstance(tServiceManager); object desktop = servicemanager.GetType().InvokeMember("createinstance", BindingFlags.InvokeMethod, null, servicemanager, new object[] { "com.sun.star.frame.Desktop" }); object doc = desktop.GetType().InvokeMember("getCurrentComponent", BindingFlags.InvokeMethod, null, desktop, new object[] { }); object sheets = doc.GetType().InvokeMember("getSheets", BindingFlags.InvokeMethod, null, doc, new object[] { }); object sheet = sheets.GetType().InvokeMember("getByIndex", BindingFlags.InvokeMethod, null, sheets, new object[] { 0 }); object crange = sheet.GetType().InvokeMember("getCellRangeByPosition", BindingFlags.InvokeMethod, null, sheet, new object[] { 0, 0, 1, 1 }); object cursor = sheet.GetType().InvokeMember("createCursorByRange", BindingFlags.InvokeMethod, null, sheet, new object[] { crange }); object data = cursor.GetType().InvokeMember("getDataArray", BindingFlags.InvokeMethod, null, cursor, new object[] { }); --------------------------- The last call ("getDataArray") fails in 3.4.4 and newer. Steps to reproduce: 1) Open LibreOffice Calc; new workbook is created 2) Write something in cells of first sheet or leave it empty - it does not matter 3) Leave this workbook open in Calc - but it does not matter if it is saved or not 4) Run the C# code (or attached Lo344dataread.exe) - it tries to read cells (0;0)..(1;1) od first sheet of active workbook 5) See the result: 3.4.4 and newer raises exception; 3.4.3 and older succeeds Attaching Lo344dataread.exe and complete C# source zip.
Created attachment 57153 [details] compiled .NET2 code
I think I will take this one. If you are regullarly using interfaces you might be interested in adding some test cases to prevent future problem with these interfaces. I will add a test case for this.
I wrote a test and I can't reproduce your problem. Can you give me some more details about the exception? Just two things I noticed is that getCellRangeByPosition and createCursorByRange should create both an object derived from ScCellRangeObj which implements getDataArray and that the method should return something like Object[][] but I have no idea about the C# language bindings.
Find the test code at: http://cgit.freedesktop.org/libreoffice/core/commit/?id=7b91c6d1c0686b06de4d2e87b02df10aa9afbf4c http://cgit.freedesktop.org/libreoffice/core/commit/?id=4e1e72dc346e732ff5693e5428e39710ca3b78a5
Hi, returned object of this method in C# can be accessed as: ------------------------------------ object[] V = CalcCOM.GetDataArray(cursor); if (V != null) for (int i = 0; i < V.Length; i++) { object[] VV = (object[])V[i]; if (VV != null) for (int j = 0; j < VV.Length; j++) // ...here use VV[j] } ------------------------------------- It is not exactly object[][], but it IS array of array of object ;) This code example works correctly in 3.4.3 or older...
The exception is type + [System.Runtime.InteropServices.InvalidOleVariantTypeException] {"Udaná variantní hodnota OLE je neplatná."} ...translated from czech - this is something like "OLE variant value is invalid"
can you reproduce problem with my C# code? Maybe the problem is with COM type of returned result of method? When I walked on changes between 3.4.3 and 3.4.4 I found http://cgit.freedesktop.org/libreoffice/components/commit/?h=libreoffice-3-4&id=ab802aee181ca6df397ca53e461d5f53808cef9d but I do not understand the change at all so I cannot say if this can be related with the problem or not...
@Noel: It is not a calc issue, do you have an idea?
(In reply to comment #8) > @Noel: It is not a calc issue, do you have an idea? it looks like the fix mentioned above is not complete perhaps. I am going to look at it now
ok, looks like the patch didn't fix things as expected, actually I think it just hid some underlying brokeness that was already there. apparently there is a fix from one of the old cws(s). I just tested a revert of my previous patch and new patch from cws j1166 and all appears good. I am going to add this issue to 3-5 most annoying
fixed on master http://cgit.freedesktop.org/libreoffice/core/commit/?id=985ad082a56cd4bc47cd230e11f1cd771e08f9de http://cgit.freedesktop.org/libreoffice/core/commit/?id=a6ff118c4fdb3af7702c463d995df38742da3464 and 3.5 branches http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=39d26132445c158b4035b689e8939c8e7fb2d4ee http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=84a70824e2acbb50728540b4944c4243b6bd8e21
Is there any windows installer of the build with fix that can I test? (will be some rc available?)
(In reply to comment #12) > Is there any windows installer of the build with fix > that can I test? (will be some rc available?) I tested your example ( and the other attached in the associated bugs mentioned in bug #38441 ) in my dev build of 3.5 ( with patches ) this patch will be included in the upcomming 3.5.1-rc1 release output of your exe against my 3.5 build $ ./Lo344dataread-fdo46165.exe You must have some testing workbook with at least 1 sheet open in Calc! Please press a key to close...
(In reply to comment #13) > (In reply to comment #12) > > $ ./Lo344dataread-fdo46165.exe > You must have some testing workbook with at least 1 sheet open in Calc! > > Please press a key to close... damn that was the first output before I opened a calc doc ./Lo344dataread-fdo46165.exe Everything is OK. I guess you have 3.4.3 or older! Please press a key to close... is what I got with a valid doc
seems like 3.5.1 will be working again :)
Target due to comment 15