Description: the BASIC command thiscomponent.currentselection(0).name returns the wrong name of grouped Draw Objects. In Writer: If multiple Draw objects are grouped and this grouped object is given a name (e.g. "linegroup") the above command should return this grouped object name but it returns the name of one of the elements instead e.g "line1". This error occurs in all tested LibreOffice-Versions (4 and 5er)and OpenOffice4 on most Linux systems like Linux Mint, Ubuntu. Both 64bit and 32bit versions. It works correctly on Lubuntu, Windows,OSX. Steps to Reproduce: 1. create 2 draw lines and give each a name. eg."line1" and "line2" 2. group the 2 lines 3. give the grouped object a name e.g. "linegroup" 4. select the object and run the basic program: sub showname msgbox thiscomponent.currentselection(0).name end sub It should show the name of the grouped object: "linegroup" 5. insert and delete texts. Save, try again. At some point the error will occur and it will show the name of one of the elements e.g. "line2" instead of the grouped object ("linegroup") Because it may not appear immediately try it with the attached files: File1: Names_of_grouped_Draw_objects1.odt At first it works, after deleting some text the error will occur. File2: Names_of_grouped_Draw_objects2.odt Here the error always occurs Actual Results: At some point the error will occur and it will show the name of one of the elements e.g. "line2" instead of the grouped object ("linegroup") Expected Results: It always should show the name of the grouped object ("linegroup") Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:56.0) Gecko/20100101 Firefox/56.0
Created attachment 137487 [details] Names_of_grouped_Draw_objects1.odt
Created attachment 137488 [details] Names_of_grouped_Draw_objects2.odt
(In reply to Kai Struck from comment #2) > Created attachment 137488 [details] > Names_of_grouped_Draw_objects2.odt I get the wrong result, if I use the GTK3 VCL plugin. With all other plugins the result is correct. Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha1+ Build ID: 1aba1955f161cc112dab80b6b3e78ec7761616fc CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on November 10th 2017
Thank you for investigating. And finding the bug related to GTK3 VCL plugin. I will try to confirm that (when I found an easy way to change that) This explains why it works on certain systems like Lubuntu,CentOS out of the box and doesn't on Ubuntu,Linux Mint etc. The importance may sure be minor but sadly is the major reason why a huge part of my extension is broken on these systems: https://extensions.libreoffice.org/extensions/chorddiagrams
(In reply to Kai Struck from comment #4) > Thank you for investigating. > And finding the bug related to GTK3 VCL plugin. > I will try to confirm that (when I found an easy way to change that) > This explains why it works on certain systems like Lubuntu,CentOS out of the > box and doesn't on Ubuntu,Linux Mint etc. Sorry for not mentioning: you can use different VCL plugins by launching from the command line SAL_USE_VCLPLUGIN=gtk libreoffice SAL_USE_VCLPLUGIN=gtk3 libreoffice SAL_USE_VCLPLUGIN=kde4 libreoffice SAL_USE_VCLPLUGIN=gen libreoffice We use minor severity usually when there is a workaround (not using gtk3 plugin in this case).
I think this isn't gtk3 specific, but an underlying bug which is easier to run into with gtk3
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=74030e2aebb68218d829724329744e6992d6543b Resolves: tdf#113615 wrong SwXShape from three possibilities returned It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
backport to 5-4 in gerrit
Bug seems to be corrected in todays master~2017-11-17_00.29.00_LibreOfficeDev_6.0.0.0.alpha1_Linux_x86-64_deb.tar.gz on Linux Mint. Congratulations! I tested it with ChordDiagrams Extension that now again allows editing existing Shapegroups. (Wasn't possible before due to bug) (the chord diagrams themselves are not drawn correctly in 6alpha, but this may be because of alpha status(?)) Don't know the meaning of "backport to 5-4 in gerrit" Thought it may say the bug will also be corrected in LO5.4 but in libreoffice-5-4~2017-11-17_09.32.39_LibreOfficeDev_5.4.4.0.0_Linux_x86-64_deb.tar.gz the bug is existent.
(In reply to Kai Struck from comment #9) > (the chord diagrams themselves are not drawn correctly in 6alpha, but this > may be because of alpha status(?)) You can report that as a new bug. > Don't know the meaning of > "backport to 5-4 in gerrit" It means it is submitted to the review tool gerrit: https://gerrit.libreoffice.org/#/c/44730/ It has not been merged yet
Thank you very much for the informations! The other bug of wrong vertical positions of inserted Draw Objects is filed: https://bugs.documentfoundation.org/show_bug.cgi?id=113938
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f2eb40825cf66a0e01bb94171d7b0cbe86daa3f2&h=libreoffice-5-4 Resolves: tdf#113615 wrong SwXShape from three possibilities returned It will be available in 5.4.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Wonderful, thank you! Bug seems to be corrected in libreoffice-5-4~2017-11-23_08.51.06_LibreOfficeDev_5.4.4.0.0_Linux_x86-64_deb.tar.gz on Linux Mint.
I also wrote the same Bugreport for OO: https://bz.apache.org/ooo/show_bug.cgi?id=127604 They are now asking for a License Agreement from the developer of this patch to be able to use it in OO. http://cgit.freedesktop.org/libreoffice/core/commit/?id=74030e2aebb68218d829724329744e6992d6543b
> They are now asking for a License Agreement from the developer of this patch > to be able to use it in OO. > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=74030e2aebb68218d829724329744e6992d6543b Red Hat's commits to libreoffice are provided solely under the typical LibreOffice license combination of LGPLv3+/MPL as per https://lists.freedesktop.org/archives/libreoffice/2012-April/031021.html
They say the license is incompatible with OpenOffice's license so that LO can use OO code but OO can't use LO code. I'm personally not firm into license languages so would it be a problem if a nice person would have an eye on your code and adapt it to OpenOffice? Hope you don't mind the question.
(In reply to Kai Struck from comment #16) > I'm personally not firm into > license languages so would it be a problem if a nice person would have an > eye on your code and adapt it to OpenOffice? If you look at comment 10 in the AOO report you will have your answer: "Is there any way to delete the comments containing links to LO web pages and comments about them? Although I have not followed any of the links, I have no way of proving that and may be influenced by the comments about them. As a result, I do not feel comfortable working on this bug. If the risky comments were deleted, future developers who have not seen them may be able to fix it."
Yes I saw that. And as this situation sounds so ridiculous to me ( someone found a solution but we can't use it and we can't fix the problem because now we know the other solution) I just went here to ask about it here. Ironically I created this situation. Unaware of this license problems I provided as much information I could which now turns out to be a hindrance.