Created attachment 194759 [details] Zip of two files, extension and sample file This sample extension implements one formula =INCREMENTBYONE(x), simple increment of the number x by one. Ty reproduce: 1. Install 7.3.7 version of the LibreOffice 2. Install the extension 3. Open the attached "sample.xlsx" file Expected Result: A1 -> 2 Actual Result: A1 -> 2 4. Install any other version ( I tried 7.4.7 and 24.2 ) of the LibreOffice 5. Install the extension 6. Open the attached "sample.xlsx" file Expected Result: A1 -> 2 Actual Result: A1 -> #NAME? Attached is sample.xlsx, which was created by MS Excel.
I bibisected the change with linux-64-7.4 to ad15930e60b1e175d127022fd99fe71f140cbd88 Resolves: tdf#142293 Implement the temporariness of GetOpCodeMap() The title of bug 142293 is "Spreadsheet functions implemented as AddIn may get saved with their programmatic name to OOXML Excel .xlsx instead of the function name". So this makes me think what you see is not a bug in itself, but you can fix it by recreating the xlsx or adjusting your extension. Can you check it?
This bug and the bug 142293 are not related in any way.
(In reply to Emil from comment #2) > This bug and the bug 142293 are not related in any way. Yes they are because the behaviour changed at the commit I referenced.
(In reply to Buovjaga from comment #1) > I bibisected the change with linux-64-7.4 to > ad15930e60b1e175d127022fd99fe71f140cbd88 So that is a backport commit, and also a combination of five commits. This is why bisection in post-branch-off commits is usually not helpful. Could you please bisect in linux-64-7.5 (I assume it was the master then)? Thanks!
(In reply to Mike Kaganski from comment #4) > (In reply to Buovjaga from comment #1) > > I bibisected the change with linux-64-7.4 to > > ad15930e60b1e175d127022fd99fe71f140cbd88 > > So that is a backport commit, and also a combination of five commits. This > is why bisection in post-branch-off commits is usually not helpful. > > Could you please bisect in linux-64-7.5 (I assume it was the master then)? > Thanks! Good point. Checking those commits directly, the exact change is 5aaa0cda74de4170972b7988d8fca16a560b8500 Resolves: tdf#142293 Implement the temporariness of GetOpCodeMap()
(In reply to Emil from comment #0) > Attached is sample.xlsx, which was created by MS Excel. In fact, it was created by Openpyxl; and opening it in MS Excel warns that "We found a problem with some content in 'sample.xlsx'. Do you want us to try to recover as much as we can?". Not really relevant to the problem, though.
Dear Mike, This excel file can be opened my MS Excel without any errors, please see the attached recording. https://d.pr/v/MwheZw Also, it is not really matter if the excel was created by MS excel or any other excel lib. The problem is Libreoffice allows to create custom functions which should be stored in the way it can be readable by any other excel processor. Libreoffice did it correctly until the version 7.3.7. Later versions store the function with the preamble, wich can't be read correctly by another excel processors which capable to process the same custom function. I just made an example with the simple function to reproduce the bug, but some of the functions i implemented already supported by excel ( like XLOOKUP ) and so, but need to be added to Libreoffice support.
So indeed, that change is relevant. The add-in registers function 'COM.XEVALAI.XEVAL.OXT.INCREMENTBYONE', but prior to the change, it handled undecorated plain 'INCREMENTBYONE'. Now it only handles the fully qualified name, as intended. So what should be the change in the add-in, to handle unqualified name? Eike, could you advise? Thank you!
(In reply to Emil from comment #7) Please avoid unneeded posts. My comment 6 mentioned a fact, and noted that it wasn't really relevant for the problem. Your comment 7 only created noise. Thanks.
Reading sample.xlsx I do not get a #NAME? error with any version (tried 25.2.0.0.alpha0+, 7.4.7.2.0+ and 24.2.6.1.0+) neither with the Archive.zip's sample.xlsx nor the sample.xlsx of xevalai.oxt. They both have COM.XEVALAI.XEVAL.OXT.INCREMENTBYONE(1) stored. Replacing that with INCREMENTBYONE(1) in xl/worksheets/sheet1.xml though yields #NAME? error. Saving (a working INCREMENTBYONE(1)) to .xlsx however it uses the full programmatic name. I can't even install the extension successfully in 7.3.7 or any earlier I tried (might be on my self-built side), so can't say if it really stored INCREMENTBYONE(1) instead of the full programmatic name. What we maybe could do is if a (English) CompatibilityName was defined (which may even be locale-dependent, thanks to Excel's weirdos) in the .xcu, i.e. INCREMENTBYONE, to store that and also read it. However, that could not be read by older LibreOffice versions that could read the full programatic name, so isn't ideal either. YMMV.. In any case we probably could recognize such CompatibilityName when reading from .xlsx as well (that mechanism originally was for .xls BIFF). (CompatibilityName in addin.xcu would be to add <prop oor:name="CompatibilityName"><value xml:lang="en">INCREMENTBYONE</value></prop> for example after the oor:name="Category" property).
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d65ccee2917baadbc1ebf85e61107cfdfcc159cf Related: tdf#161599 ChildAccess::asValue() must return Reference<XInterface> It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Building with the new commit, when I tried to install the extension, I got an error window with std::bad_alloc, context com.sun.star.uno.XInterface Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d65ccee2917baadbc1ebf85e61107cfdfcc159cf CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/61e11389f2bebf605fbebfc58ef4e345941bf907 Related: tdf#161599 ChildAccess::asValue() must return Reference<XInterface> It will be available in 24.8.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Buovjaga from comment #12) > Building with the new commit, when I tried to install the extension, I got > an error window with std::bad_alloc, context com.sun.star.uno.XInterface I don't get that. Anyone else? What's the backtrace indicating it's coming from?
Btw, I doubt that a file created by Excel ever would had written INCREMENTBYONE because function names not defined by OOXML get a _xlfn. prefix, so that should had been _xlfn.INCREMENTBYONE instead. For Excel Add-In functions it might even be a different one, not sure at the moment (Mike? on Cc). (In reply to Emil from comment #7) > This excel file can be opened my MS Excel without any errors, please see the > attached recording. https://d.pr/v/MwheZw That shows a =@INCREMENTBYONE(1) formula (note the leading @) and equally a #NAME? error. > Also, it is not really matter if the excel was created by MS excel or any > other excel lib. I doubt that. As said, Excel would had added some prefix. > The problem is Libreoffice allows to create custom > functions which should be stored in the way it can be readable by any other > excel processor. Libreoffice did it correctly until the version 7.3.7. Unfortunately you did not provide a file actually stored by LO 7.3.7 so we could take a look. Or even a file saved by Excel. > I just made an example with the simple function to reproduce the bug, but > some of the functions i implemented already supported by excel ( like > XLOOKUP ) and so, but need to be added to Libreoffice support. XLOOKUP and others are implemented as of LO 24.8, see https://wiki.documentfoundation.org/ReleaseNotes/24.8#Calc
(In reply to Eike Rathke from comment #15) > Btw, I doubt that a file created by Excel ever would had written > INCREMENTBYONE because function names not defined by OOXML get a _xlfn. > prefix, so that should had been _xlfn.INCREMENTBYONE instead. For Excel > Add-In functions it might even be a different one, not sure at the moment > (Mike? on Cc). My Excel doesn't have INCREMENTBYONE function, so indeed the function in the attachment 194759 [details] is shown as a #NAME? error (and this time, I didn't get the warning I mentioned in comment 6 - possibly that was something about corruption of the file when I extracted it? Doesn't matter, because that was obviously my local problem). Re-saving the same file in Excel keeps the bare "<f ca="1">INCREMENTBYONE(1)</f>". Creating such a file in Excel from scratch gives the function name lowercase: "<f ca="1">incrementbyone(1)</f>". I don't know what will happen when using an Excel extension defining a function, though.
(In reply to Eike Rathke from comment #14) > (In reply to Buovjaga from comment #12) > > Building with the new commit, when I tried to install the extension, I got > > an error window with std::bad_alloc, context com.sun.star.uno.XInterface > I don't get that. Anyone else? > What's the backtrace indicating it's coming from? I got that message earlier with gtk3. With kf6, I saw a window in the task bar with the title "Warning", but I could not focus it to the front. Now I ran make clean and built again and gtk3 and gen work fine while kf6 still bugs out. Backtrace after hitting Ctrl-C in gdb is this, not sure if very useful: #0 0x000076cba909fa19 in ?? () from /usr/lib/libc.so.6 #1 0x000076cba90a2479 in pthread_cond_wait () from /usr/lib/libc.so.6 #2 0x000076cba8cd6cf1 in __gthread_cond_wait (__cond=<optimized out>, __mutex=<optimized out>) at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/gthr-default.h:878 #3 std::__condvar::wait (this=<optimized out>, __m=...) at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/std_mutex.h:171 #4 std::condition_variable::wait (this=<optimized out>, __lock=...) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/condition_variable.cc:41 #5 0x000076cb945ca79e in std::condition_variable::wait<(anonymous namespace)::QtYieldMutex::doAcquire(unsigned int)::$_0>(std::unique_lock<std::mutex>&, (anonymous namespace)::QtYieldMutex::doAcquire(unsigned int)::$_0) ( this=0x5e3eff1e9f38, __lock=..., __p=...) at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/14.2.1/../../../../include/c++/14.2.1/condition_variable:105 #6 0x000076cb945ca594 in (anonymous namespace)::QtYieldMutex::doAcquire (this=0x5e3eff1e9ee0, nLockCount=2) at vcl/qt6/../qt5/QtInstance.cxx:172 #7 0x000076cb9f2ac752 in comphelper::SolarMutex::acquire (this=0x5e3eff1e9ee0, nLockCount=2) at include/comphelper/solarmutex.hxx:86 #8 0x000076cb9fe21b37 in SalInstance::AcquireYieldMutex (this=0x5e3eff1ec380, nCount=2) at /home/user/libreoffice/vcl/source/app/salvtables.cxx:146 #9 0x000076cb9fee9494 in Application::AcquireSolarMutex (nCount=2) at /home/user/libreoffice/vcl/source/app/svapp.cxx:508 #10 0x000076cb945cdd18 in SolarMutexReleaser::~SolarMutexReleaser (this=0x7ffdd73b566c) at include/vcl/svapp.hxx:1425 #11 0x000076cb945c41d3 in QtInstance::ImplYield (this=0x5e3eff1ec370, bWait=true, bHandleAllCurrentEvents=false) at vcl/qt6/../qt5/QtInstance.cxx:458 #12 0x000076cb945c7485 in QtInstance::DoYield (this=0x5e3eff1ec370, bWait=true, bHandleAllCurrentEvents=false) at vcl/qt6/../qt5/QtInstance.cxx:465 #13 0x000076cb9fee853c in ImplYield (i_bWait=true, i_bAllEvents=false) at /home/user/libreoffice/vcl/source/app/svapp.cxx:385 #14 0x000076cb9fee7e3b in Application::Yield () at /home/user/libreoffice/vcl/source/app/svapp.cxx:473 #15 0x000076cb9fee7bd2 in Application::Execute () at /home/user/libreoffice/vcl/source/app/svapp.cxx:360 #16 0x000076cba93d92f0 in desktop::Desktop::Main (this=0x7ffdd73b7138) at /home/user/libreoffice/desktop/source/app/app.cxx:1691 #17 0x000076cb9ff0ac8c in ImplSVMain () at /home/user/libreoffice/vcl/source/app/svmain.cxx:228 #18 0x000076cb9ff0cb99 in SVMain () at /home/user/libreoffice/vcl/source/app/svmain.cxx:260 #19 0x000076cba944e35c in soffice_main () at /home/user/libreoffice/desktop/source/app/sofficemain.cxx:121 #20 0x00005e3eec6a59fd in sal_main () at /home/user/libreoffice/desktop/source/app/main.c:51 #21 0x00005e3eec6a59d7 in main (argc=2, argv=0x7ffdd73b7358) at /home/user/libreoffice/desktop/source/app/main.c:49
(In reply to Buovjaga from comment #17) > Backtrace after hitting Ctrl-C in gdb is this, not sure if very useful: Not really, that just shows the main thread waiting for some other thread, not the actual bad_alloc. The gdb command to obtain backtraces from all threads would be thread apply all bt or better, from your build's instdir/program/ run ./soffice --backtrace that should write a gdbtrace.log you can attach.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5755b5515b8e97b638f2fb1f7553130760f12e94 Related: tdf#161599 pre-initialize ScCompiler ODFF and OOXML final OpCodeMap It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Mike Kaganski from comment #16) > I don't know what will happen when using an Excel extension defining a > function, though. This is all confusing. The attached Add-In apparently was meant as an example but the original problem was about the XLOOKUP function implemented as Add-In, and that when saved to .xlsx should definitely be _xlfn.XLOOKUP instead of plain XLOOKUP. Calc is not prepared to save such from an arbitrary Add-In, not even with a compatibiblity name. I think I can implement it as a general measure, but of course that will be superfluous for the XLOOKUP Add-In because XLOOKUP is now an internal function.
(In reply to Buovjaga from comment #17) > (In reply to Eike Rathke from comment #14) > > (In reply to Buovjaga from comment #12) > > > Building with the new commit, when I tried to install the extension, I got > > > an error window with std::bad_alloc, context com.sun.star.uno.XInterface > > I don't get that. Anyone else? > > What's the backtrace indicating it's coming from? > > I got that message earlier with gtk3. With kf6, I saw a window in the task > bar with the title "Warning", but I could not focus it to the front. > > Now I ran make clean and built again and gtk3 and gen work fine while kf6 > still bugs out. Reported as bug 162696, nothing to do with this issue.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6159c597b5e20db2cee919b116bb7a0b663ca9d7 Related: tdf#161599 Do not skip first of fallbacks of CompatibilityName locale It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/59d2745d4ab0bb44d474bab56d3f06a8e1dfb788 Related: tdf#161599 Accept Add-In CompatibilityName when reading OOXML It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/044980edc41544dd5973d5aa57f134d4bfe6d0e7 Resolves: tdf#161599 Write Add-In CompatibilityName (if any) to OOXML It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
With these changes it is possible to read and write a compatibility name that is defined in the extension's .xcu file. The defined name must be identical to what Excel (!) writes when writing out the function name. For the example here this likely would be <prop oor:name="CompatibilityName"><value xml:lang="en-US">_xlfn.INCREMENTBYONE</value></prop> Note the "_xlfn." prefix (similar to the _xlfn.XLOOKUP mentioned earlier). xml:lang can be "en-US" (preferred) or "en". In case neither is present, the first CompatibilityName with any other language tag is taken (this indeterministic behaviour is a legacy of existing implementation and kept for congruency), so always define a "en-US" or "en" CompatibilityName if there is any other for whatever reason. If no CompatibilityName is defined, the fully qualified function name is written, as before.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/1700d33d8b4ce721a774b8fa894c42375acd6db9 Related: tdf#161599 Do not skip first of fallbacks of CompatibilityName locale It will be available in 24.8.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/4b0ff8ae2a8b9d3945cd0f23535c7ef354a9b3d4 Related: tdf#161599 Accept Add-In CompatibilityName when reading OOXML It will be available in 24.8.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/5a9f5931134a4062f90860f1dc76717d81a8d6b2 Resolves: tdf#161599 Write Add-In CompatibilityName (if any) to OOXML It will be available in 24.8.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/d7de73fa57c3a96fa8caf030f231e64a59616c2a Related: tdf#161599 pre-initialize ScCompiler ODFF and OOXML final OpCodeMap It will be available in 24.8.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.