LO: 7.3.3.2 Community (Build d1d0ea68f081ee2800a922cac8f79445e4603348)
OS: OSX 10.15.7
Am having difficulty with data copied and pasted programatically from one Calc doc to another, where one of the source columns contains floats.
Normally I paste as “SV” (strings and values) for an entire range, but have found that with the problem column, unless I paste as “V” (values only), running the QueryEmptyCells method on an object produces an incorrect array of RangeAddress elements.
String and integer data do not seem to be affected; only floats (the column is formatted to two decimals with one leading zero, and the source cells contain either no data, or a number such as 0.13, etc.)
Am thinking it’s something in the source file but don’t see anything “wrong” with the data. The extension says it’s an XLS, but it’s actually in HTML format. Saving that doc as an ODS then re-opening and using the native Libre doc as the source produces the same effect. Examining the file does show the correct float value (“0.13”, etc.) Copying from a cell in the ODS saved version to a text editor shows the same value. Libre opens the “fake” XLS just fine, but I do have to use a two-element com.sun.star.beans.PropertyValue array:
aProps(0).Name = “FilterName”
aProps(0).Value = “HTML (Starcalc)”
aProps(1).Name = “FilterOptions”
aProps(1).Value = “59,34,0,1”
Values for element 1 of the PropertyValue item were gleaned from an ( OO Forum Post. Neither OO or LO docs seem to have much info on how to construct these filters, and wading into the LO source didn’t help much either. If this is the source of the trouble, and there is such a resource out there, please pass it along!)
In any event, am not thinking it’s the data per se, rather how Libre is interpreting it.
If I manually enter integer or string data into any row of the “problem” column, or delete the float value so there is no data in that cell, QueryEmptyCells seems to correctly evaluate the column. Otherwise, it shows shows just one array element, from 1 before the highest row that was pasted (row indices are zero-based) to the max of 1048575, and CMD-Down in that column from row 1 just goes straight to the end of the tab, ignoring any rows with data. (This makes sense, as internally CMD-Down is most likely employing QueryEmptyCells to know where to position the cursor.)
I can also get QueryEmptyCells to work properly by clearing direct formatting for the column, then manually entering float values.
Without manually entering the floats, I can get around the issue by pasting the float columns as just “V”, rather than “SV”, but that means hard-coding which columns to be treated as “V” and which as “SV”.
FWIW, am copying with
myDispatcher.executeDispatch(sourceFrame, “.uno:Copy”, “”, 0, Array())
and pasting with
myDispatcher.executeDispatch(targetFrame, “.uno:InsertContents”, “”, 0, pasteFlags)
where
myDispatcher → an object created by: createUnoService(“com.sun.star.frame.DispatchHelper”)
sourceFrame → the Frame of the source document (a com.sun.star.comp.framework.Frame object)
targetFrame → the Frame of the target document (same type as sourceFrame, just pointing to a different object)
pasteFlags → normally “SV” for Strings and Values, unless I use the workaround for the “float” columns and employ multiple copy’n’paste operations.
I can also tell it’s definitely something in the source data, as CMD-Down acts the same way on it, but since the source “reads” OK, can’t put my finger on why. If I manually copy the float column and paste it as values, things work as expected.
Has anyone else run across this issue, or have any insight on why these float values are being interpreted incorrectly, but String and Integers would not?
Please advise. Thanks!
Carl