Created attachment 159451 [details] Calc extension that does not work in LibreOffice I have a Calc extension that contains a simple StarBasic macro. The purpose is to export an opened spreadsheet file to a tab-separated text file in UTF-8 with no text delimiter and assign a name to the exported TSV file equal to the name of the original file except for the name extension (if the name extension is a common spreadsheet file name extension such as .ods/.xls/.xlsx, it is replaced with .txt, otherwise .txt is added to the file name). When installed, the Calc extension creates (in Calc only) a custom toolbar with one button and a custom item under the File menu (namely, “Export to OmegaT Glossary”). The Calc extension installs and operates as described above in Apache OpenOffice 4.2.0 (for the sake of clarity: it is a development build from 2016), but not in LibreOffice, including LO 6.4.2 (tested also with earlier 6.4.0, 6.3.4 and other versions, mainly under Windows 7). An attempt to install produces an error message that I cannot interpret (see below). At ask.libreoffice.org, I have been advised to report the issue here, which I do. Steps to reproduce: 1. Download the attached extension file. 2. Try to install it. An error message should appear as follows: (com.sun.star.deployment.DeploymentException) { { Message = "An error occurred while enabling: ExportToGlossary", Context = (com.sun.star.uno.XInterface) ©50038c8 }, Cause = (any) { (com.sun.star.lang.IllegalArgumentException) { { { Message = "", Context = (com.sun.star.uno.XInterface) @0 }}, ArgumentPosition = (short) 0 }}} 3. Close LibreOffice, restart. 4. Open the Extension Manager. 5. The Calc extension appears in the list, but inactive. 6. Click on Enable. An error message should appear as follows: (com.sun.star.lang.IllegalArgumentException) { { { Message = "", Context = (com.sun.star.uno.XInterface) @0 }}, ArgumentPosition = (short) 0 ) Afterwards, the extension does not become active, however, can be uninstalled.
On pc Debian x86-64 with master sources updated today, I could reproduce partly this, I mean during installation, I noticed this log: warn:configmgr:716560:716631:configmgr/source/xcuparser.cxx:159: bad set node <prop> member in "file:///home/julien/lo/libreoffice/instdir/program/../program/../user/extensions/shared/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/lut7k01p.tmp/Addons.xcu" warn:configmgr:716560:716631:configmgr/source/xcuparser.cxx:904: ignoring modify of unknown set member node "ToolBarItems" in "file:///home/julien/lo/libreoffice/instdir/program/../program/../user/extensions/shared/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/lut7k01p.tmp/Addons.xcu" Idem when I relaunch LO. The extension doesn't seem disabled in extension manager.
I can not reproduce with LO 6.3.5 on Windows 10: Version: 6.3.5.2 (x64) Build ID: dd0751754f11728f69b42ee2af66670068624673 CPU threads: 2; OS: Windows 10.0; UI render: default; VCL: win; Locale: zh-CN (zh_CN); UI-Language: en-US Calc: threaded The extension installs (for the current user only) without any error message. After restarting LO, the extenstion appears active in the manager, and the File -> Export to OmegaT Glossary menu item exists. Didn't see any toolbar button, though.
By default, there's no new icon in Calc but the entry appears in menu File. I fixed the errors I had on console by removing from Addons.xcu these: <prop oor:name="Title"> <value>ExportToGlossary toolbar</value> </prop> and <node oor:name="ToolBarItems"> </node> I kept the content of this last one. It allows to display the icon on Calc. Now what does this extension do? Indeed when clicking on the icon or selecting the entry, I see nothing. Would you have some minimal example process to test?
I gave a new try, I saw that it was generating a csv file with tab as field delimiter, no string delimiter and txt extension. I must recognize I don't see the interest of this extension since when you save as csv, you've got the equivalent (except you must rename extension). Indeed, you got: - character set (utf-8 by default) - field delimiter - string delimiter + other things Also, where did you download the extension? I didn't find it on Google. Could you uninstall the extension + rename your LO directory profile (see https://wiki.documentfoundation.org/UserProfile) and install again? Indeed, I don't know how you got this error.
I can't speak for where the reporter found the macro, but I searched for the macro code online and found references to it in these pages: https://forum.openoffice.org/en/forum/viewtopic.php?f=20&t=79147 https://ask.libreoffice.org/en/question/156320/how-can-i-save-my-document-as-a-csv-and-maintain-all-languages-in-the-exported-document/ https://www.proz.com/forum/general_technical_issues/325540-text_editor_with_unicode_support_looking_for_recommendations.html#2730044 (The last link points to the author of the extension, I believe, based on the pkg-description.txt information)
First, thank you everybody for your input. I tried Julien Nabet’s suggestion, but it looks like I can’t understand/implement it. Resetting the user profile partially helped. Indeed, I can see a menu item now, but no toolbar, which would be great. I’m the author of the extension. I created the underlying macro in 2015 for use in conjunction with OmegaT [1], a computer-assisted translation tool [2] (inter alia, OmegaT is mentioned in the TDF wiki as a tool for LibreOffice localization [3]) Then, tab-separated text in UTF-8 was the only option for glossaries that OmegaT could read and still remains the default option for glossaries that can be amended from within the program. On the other hand, translators often receive glossaries in spreadsheet files (mainly Excel XLS[X]) requiring export. Exporting to a CSV file may seem to be very easy to the people here (programmers), but in practice many translators reported (and still report) problems that appear to be caused by omitting something in the export options dialog (such as setting nothing for the text delimiter; there is no such option in the drop-down list, and the user has to manually empty the respective field, which is not evident). Thus, the idea behind the macro is to provide a simple tool that can be used by non-experienced users, i. e. with all the required export options hardcoded. So, if anyone reports a problem with glossary export, I can say: “Grab the extension and just click on the button with that nice icon.” (Maybe the icon is not that nice, but I’m not an artist anyway.) I tried to pack my macro in an extension. I’m not a programmer and could not find something like “Idiot’s guide to packaging extensions”, thus, studied existing extensions and used Basic Addon Builder [4] as an auxiliary tool. I tested the produced extension (submitted here) to work fine in Apache OpenOffice and published it in the OmegaT mail group at Yahoo! [5] However, I could not get it install and run under LibreOffice (it was a fresh install then). At that time, however, LibreOffice office was too buggy to use anyway, and I gave up. I raised this issue here because: - it is 2020 now, LibreOffice gained wide adoption and I would be happy to see my extension work in LibreOffice as designed, with a button and a menu item; - the extension, as mentioned in the initial report, works absolutely fine in Apache OpenOffice, installs and uninstalls _without any need to reset the user profile_. Since both Apache OpenOffice and LibreOffice descend from OpenOffice.org, I thought that the failure of the extension might indicate that something requires a fix in LibreOffice; - I was advised by someone more experienced to report the issue [6]. Once again, thank you all for the help. If anyone can give a pointer on how to enable a custom toolbar, I will be grateful. [1] https://omegat.org/ [2] https://en.wikipedia.org/wiki/Computer-assisted_translation [3] https://wiki.documentfoundation.org/Documentation/Development/UsingOmegaT [4] https://extensions.openoffice.org/project/BasicAddonBuilder [5] the list moved to SourceForge.net, the respective thread can be found archived here: https://sourceforge.net/p/omegat/mailman/message/36847659/ [6] https://ask.libreoffice.org/en/question/237500/writer-print-current-page/ (see comments)
Created attachment 159529 [details] New version of extension Here are the changes I made: Remove the whole block <prop oor:name="Title"> <value>ExportToGlossary toolbar</value> </prop> + remove this block (but let the content) <node oor:name="m001"> </node> I also changed version to put 1.0.2 I let you test on LO and Apache OpenOffice
You are great, Julien. The new version works as designed in LibreOffice. In Apache OpenOffice, however, an error message appears: (com.sun.star.uno.RuntimeException) { { Message = "Invalid operation on group node in file///C:/Users/user/AppData/Roaming/OpenOffice/4/user/uno_packages/cache/registry/com.star.comp.deployment.configuration.PackageRegistryBackend/sv8mwm5.tmp/Addons.xcu", Context = (com.sun.star.uno.XInterface) @0 }} Has an incompatibility been introduced between LO and AOO? Anyway, the problem is solved for LibreOffice, and for Apache OpenOffice the previous version can be used. Thank you very much!
Just for the record, I sent an email on LO dev mailing list: http://document-foundation-mail-archive.969070.n3.nabble.com/Questions-about-XCU-parsing-tdf-132005-tt4277151.html
(In reply to Julien Nabet from comment #7) > + remove this block (but let the content) > <node oor:name="m001"> > </node> Better remove the outer <node oor:name="ToolBarItems"> level than the inner <node oor:name="m001" oor:op="replace"> one, so that the set element is named "m001" rather than "ToolBarItems" and, more importantly, uses oor:op="replace" (which adds the element if no element of the given name exists yet) rather than the default oor:op="merge" (which ignores the given data if no element of the given name exists, issuing a "warn:configmgr:*:*:configmgr/source/xcuparser.cxx:904: ignoring modify of unknown set member node "ToolBarItems" in "file:///~/.config/libreoffice/4/user/uno_packages/cache/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/*.tmp/Addons.xcu""). (In reply to DKG from comment #8) > In Apache OpenOffice, however, an error message appears: > > (com.sun.star.uno.RuntimeException) { { Message = "Invalid operation on > group node in > file///C:/Users/user/AppData/Roaming/OpenOffice/4/user/uno_packages/cache/ > registry/com.star.comp.deployment.configuration.PackageRegistryBackend/ > sv8mwm5.tmp/Addons.xcu", Context = (com.sun.star.uno.XInterface) @0 }} > > Has an incompatibility been introduced between LO and AOO? Anyway, the > problem is solved for LibreOffice, and for Apache OpenOffice the previous > version can be used. AOO has changed officecfg/registry/schema/org/openoffice/Office/Addons.xcs incompatibly with <https://github.com/apache/openoffice/commit/bb0b5665bb7e780d37216c70970870c193b44173> "i121577 - Allow setting toolbar name in Addons.xcu", which is why you can either have an Addons.xcu adding an "ExportToGlossary.OfficeToolBar" in your extension that works for LO and old OOo or one that works for AOO. (We erroneously picked up that incompatible change from AOO into LO too, but quickly reverted it again with <https://git.libreoffice.org/core/+/189bb791d248273758bd2b42e0ec216937fa22d9%5E!> "fdo#66691: Revert fix for i#121577 Allow setting toolbar name in Addons.xcu".)
(In reply to Stephan Bergmann from comment #10) > (In reply to Julien Nabet from comment #7) > > + remove this block (but let the content) > > <node oor:name="m001"> > > </node> > > Better remove the outer > > <node oor:name="ToolBarItems"> > > level than the inner > > <node oor:name="m001" oor:op="replace"> > > one, so that the set element is named "m001" rather than "ToolBarItems" and, > more importantly, uses oor:op="replace" (which adds the element if no > element of the given name exists yet) rather than the default oor:op="merge" > (which ignores the given data if no element of the given name exists, > issuing a "warn:configmgr:*:*:configmgr/source/xcuparser.cxx:904: ignoring > modify of unknown set member node "ToolBarItems" in > "file:///~/.config/libreoffice/4/user/uno_packages/cache/registry/com.sun. > star.comp.deployment.configuration.PackageRegistryBackend/*.tmp/Addons. > xcu""). Indeed! I forgot to tell I had added oor:op="replace" for "ToolBarItems". (I prefered keeping "ToolBarItems" compared to "m001" because first one had some meaning). > > (In reply to DKG from comment #8) >> ... > > AOO has changed officecfg/registry/schema/org/openoffice/Office/Addons.xcs > incompatibly with > <https://github.com/apache/openoffice/commit/ > bb0b5665bb7e780d37216c70970870c193b44173> "i121577 - Allow setting toolbar > name in Addons.xcu", which is why you can either have an Addons.xcu adding > an "ExportToGlossary.OfficeToolBar" in your extension that works for LO and > old OOo or one that works for AOO. (We erroneously picked up that > incompatible change from AOO into LO too, but quickly reverted it again with > <https://git.libreoffice.org/core/+/ > 189bb791d248273758bd2b42e0ec216937fa22d9%5E!> "fdo#66691: Revert fix for > i#121577 Allow setting toolbar name in Addons.xcu".) Thank you for the very detailed explanation! If I well understand, should we put NOTABUG here?
(In reply to Julien Nabet from comment #11) > If I well understand, should we put NOTABUG here? Let's do it as there were no new comments