Description: Same symptoms as in https://bugs.documentfoundation.org/show_bug.cgi?id=99584 except the test case here works in 7.6.3.0, whereas bug 99584 was about similar-looking problems present all the way back to 4.2 . I'm opening a separate bug because this seems to be a regression since 7.6.3.0 and before 24.2 (but is also present in 24.8 alpha). Maybe a bisect could be useful? This demo spreadsheet uses macros to populate cells and also conditional formats, which might (or not) be related to the current symptoms. Steps to Reproduce: 1. Open the attached Tdemo.ods (please enable macros) 2. On the _PROTO sheet, click the red "Test" button (this runs a macro which creates a new sheet "MSFT" and populates it with data) 3. In the MSFT sheet: Set magnification to 100% if needed 4. Resize columns for Optimal Width with 0.00 additional space (Select all columns; put cursor in a column header; rightclick->Optimal Width..., set the Add to 0.00, click OK) Actual Results: Some cells display ###. Note especially column E where the values shown as "###" are all constants, not numbers -- however E4, which is horizontally spanned and does not overflow, was set by a macro (details below). Expected Results: All data should fit in the optimized column widths Reproducible: Always User Profile Reset: No Additional Info: The horizontally-spanned cell E4 contains the string "TESTDATA sheet" which was put there in Basic macro code by executing NewSheet.getCellRangeByName("SourcePathCell").String = "TESTDATA sheet" (where SourcePathCell is a Named Range equivalent to $E$4 -- which can be seen via Sheet->Named Ranges and Expressions->Manage) ----- NOT REPRO in 7.6.3.0.0 REPRO in 24.2 and master: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 3b73071f7a7fcf80547da81e5effe4ed6018bbb4 CPU threads: 12; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 192850 [details] Tdemo.ods -- spreadsheet showing the problem
Macro fails for me in line: 262: OptionExpDt = Left(Expiry,3) & " " & Mid(Expiry,4,2) & ", 20" & Mid(Expiry,7,2) Error: Inadmissible value or data type. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5234ef71c7459506236d4d0dfe7beb5f00d8cc41 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
>Macro fails for me in line: 262 ... Hmm. Miguel, I'm wondering what might be different about your system or profile? You are using Windows, so I tried 24.2.0 (the official release build) on a Windows 10 machine but did not get any errors, and the bug reproduced as before. I also tried "safe mode" on Linux i.e. with a new profile, and still repro as before, with no macro errors. Strange.
(In reply to m_a_riosv from comment #2) > Macro fails for me in line: > 262: Same for me, "data type mismatch". Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5234ef71c7459506236d4d0dfe7beb5f00d8cc41 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 24.2.1.1 (X86_64) / LibreOffice Community Build ID: 359ef544e625d2ffbfced462ab37bd593ca85fa7 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded MSFT sheet is still created, but only one row of data in the table. Using Optimal Width + 0 does not give me the ### issue. Can you test again and maybe provide a new version of the file?
Is it possible we are running different versions of Java? I assume LO comes with it's own internal Java interpreter; however I have several other Java interpreters installed to support other applications, so if LO were to accidentally use one of those, then behavior might be different. Just an idea (shot in the dark).
[Automated Action] NeedInfo-To-Unconfirmed
Same error for me. It surely can not be due to Java versions. Please investigate the issue. Arch Linux 64-bit Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d8c694b5d64b05da8c515e4ffe23c4bcc2376b0f CPU threads: 8; OS: Linux 6.9; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 10 July 2024
No "Inadmissible value or data type" error if the locale is set to "en-US" (locale indicated by the Reporter).
(In reply to nutka from comment #8) > No "Inadmissible value or data type" error if the locale is set to "en-US" > (locale indicated by the Reporter). Thanks. So is this some commas vs. semicolons as separators issue? Can we get a version of the file that works in all locales?
@m_a_riosv @Stéphane Guillou @ Buovjaga -- Yes, it is a locale issue and making the macros locale-aware would be too difficult. However it is very easy to override your default locale for one command with an environment variable. LC_ALL is the "super override" variable (see 'man 7 locale') and LC_ALL=C worked for me: LC_ALL=C /path/to/soffice Tdemo.ods (I tested this in a VM configured with en_GB.UTF-8 as the default locale; the demo gets the error you reported by default, but works with the LC_ALL=C override.) Thanks for your patience! -Jim
(In reply to Jim Avera from comment #10) > @m_a_riosv @Stéphane Guillou @ Buovjaga -- Yes, it is a locale issue and > making the macros locale-aware would be too difficult. > > However it is very easy to override your default locale for one command with > an environment variable. LC_ALL is the "super override" variable > (see 'man 7 locale') and LC_ALL=C worked for me: > > LC_ALL=C /path/to/soffice Tdemo.ods Reproduced with the sample file and this environment variable value. Only cell C8 displays "###" at 100%, but changing the zoom level to 110% shows "###" in many columns (C, D, I, J, K, O, Q, V) and range E7:H7. Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-US (C); UI: en-US The issue of contents not fitting when changing the zoom level has always been a problem (I can reproduce that in OOo 3.3), but running again "optimal width" at the new zoom level should again make everything fit. This is not the case anymore, and it indeed started in 24.2 (I can't reproduce in 7.6.7.2).
Created attachment 195304 [details] minimal sample ODS No need for macro or specific locale setting in this minimal reproducer. Make the width of column A optimal with 0 extra width, observe that cell A1 displays "###". Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ccc3996cfcbebe14e9d5f3511906cfc64ddf3452 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US
Just like for bug , started at: commit 4b743de97fc133623e46827869c4ea3eb845ad47 author Khaled Hosny Mon Jul 17 12:38:41 2023 +0300 committer خالد حسني Sun Jul 23 06:01:56 2023 +0200 tdf#156234: Don’t round glyph coordinates when doing subpixel positioning Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154292 Checked with linux-64-24.2 bibisect repo, with both sample docs. Marking as duplicate. *** This bug has been marked as a duplicate of bug 160921 ***