Description: I reported a bug: https://bugs.documentfoundation.org/show_bug.cgi?id=149157 Almost exactly a year ago I confirmed that bug fixed in this comment: https://bugs.documentfoundation.org/show_bug.cgi?id=149157#c8 I am currently finding a number of spreadsheets from the CDS Tax Breakdown Service that are producing an error: BASIC runtime error. '380' Incorrect property value. As a test, I grabbed the spreadsheet I attached to that old bug report and it now also produces the '380' error. Steps: 1. Get the Harvest spreadsheet from Bug 149157 linked above (or from CDS) 2. Open it with 'soffice CDSP-BRWLCN_T3_R16_TY2020_2020_07_27_11_38_36.xls' on the command line. 3. Click any non-selected cell Observe the error dialog. 100% reproducible. At the time I confirmed 149157 as fixed, the speadsheet was not producing this error, so I believe this is a regression between the LibreOffice version Version: 7.3.3.2 / LibreOffice Community from the old bug, and Version: 25.2.5.2 (X86_64) / LibreOffice Community Build ID: 520(Build:2) CPU threads: 16; OS: Linux 6.14; UI render: default; VCL: gtk3 Locale: en-US (C.UTF-8); UI: en-US Ubuntu package version: 4:25.2.5~rc2-0ubuntu0.24.04.1~lo1 Calc: threaded from right now. NOTE: I am waiting for the PPA ( https://ppa.launchpadcontent.net/libreoffice/ppa/ubuntu ) to be updated with 25.8.x, so am stuck on 25.2.5.2. Steps to Reproduce: See the description Actual Results: BASIC error dialog shows with "Error 380" Expected Results: No error dialog Reproducible: Always User Profile Reset: No Additional Info: See description
No this is not a regression. Unfortunately, it seems that the confirmation in bug 149157 comment 8 didn't involve actually testing that code works - only that opening the file doesn't immediately fires a compilation error. Because already in 7.4.0, clicking any cell gives the same error, caused by evaluation on COUNTA in the complex condition pointed to in the error. The problematic code is in ScFunctionAccess::callFunction, where sheet::XSheetCellRanges or container::XEnumerationAccess variant is not checked / handled, while the object passed there is ScCellRangesObj. It is reproducible already in OOo 3.2.0. The following code shows it: Option VBASupport 1 Sub TestRanges if Application.CountA(Range("D19:Q23,D25:Q39")) > 0 then MsgBox "?" End Sub
Created attachment 202569 [details] A test ODS with a failing macro
(In reply to Mike Kaganski from comment #1) > Unfortunately, it seems that the confirmation > in bug 149157 comment 8 didn't involve actually testing that code works - > only that opening the file doesn't immediately fires a compilation error. This is true, since the bug I reported was the failure-on-open. I tested and confirmed the fix for that. These are spreadsheets that Canadian dividend-/distribution-paying companies are required to file. I am not involved at all in the coding, I am merely a consumer. In general, I am not mucking around with the spreadsheet at all. I think just now I accidentally clicked on a cell. When I looked up the old bug my memory of it was "sheet worked" so I thought this was a regression. I'll fix the title if I can. > The following code shows it: > > Option VBASupport 1 > > Sub TestRanges > if Application.CountA(Range("D19:Q23,D25:Q39")) > 0 then MsgBox "?" > End Sub I'll leave this open then; sounds like a legit issue as long as LO is still doing "if it works in Excel it should work in Calc".
I should mention. I am a consumer of these spreadsheets but occasionally do need to navigate around to see some cells that may be off-screen. Particularly the "Notes" cell at the bottom of the sheet. So I still would like to see this fixed, even if most of the time I can get away with "open the sheet, don't touch anything, close the sheet".