Bug 46165 - getDataArray fails in LO 3.4.4, 3.4.5, 3.5.0
Summary: getDataArray fails in LO 3.4.4, 3.4.5, 3.5.0
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
3.5.0 release
Hardware: x86 (IA32) Windows (All)
: medium major
Assignee: Noel Power
Whiteboard: (target:3.5.1)
Keywords: regression
Depends on:
Blocks: mab3.5
  Show dependency treegraph
Reported: 2012-02-16 05:33 UTC by Roman Polach
Modified: 2012-08-22 05:55 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

C# source code (5.67 KB, application/zip)
2012-02-16 05:33 UTC, Roman Polach
compiled .NET2 code (6.00 KB, application/octet-stream)
2012-02-16 05:33 UTC, Roman Polach

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Polach 2012-02-16 05:33:15 UTC
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

Attaching Lo344dataread.exe and complete C# source zip.
Comment 1 Roman Polach 2012-02-16 05:33:53 UTC
Created attachment 57153 [details]
compiled .NET2 code
Comment 2 Markus Mohrhard 2012-02-16 10:04:10 UTC
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.
Comment 3 Markus Mohrhard 2012-02-16 16:25:26 UTC
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.
Comment 5 Roman Polach 2012-02-17 01:01:11 UTC
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...
Comment 6 Roman Polach 2012-02-17 01:05:07 UTC
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"
Comment 7 Roman Polach 2012-02-17 01:10:35 UTC
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
but I do not understand the change at all so I cannot say if
this can be related with the problem or not...
Comment 8 Markus Mohrhard 2012-02-17 01:15:01 UTC
@Noel: It is not a calc issue, do you have an idea?
Comment 9 Noel Power 2012-02-23 02:52:21 UTC
(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
Comment 10 Noel Power 2012-02-23 04:24:34 UTC
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
Comment 12 Roman Polach 2012-02-24 09:03:40 UTC
Is there any windows installer of the build with fix
that can I test? (will be some rc available?)
Comment 13 Noel Power 2012-02-24 09:28:55 UTC
(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...
Comment 14 Noel Power 2012-02-24 09:30:42 UTC
(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

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
Comment 15 Roman Polach 2012-02-25 14:17:37 UTC
seems like 3.5.1 will be working again :)
Comment 16 Rainer Bielefeld Retired 2012-08-22 05:55:42 UTC
Target due to comment 15