Created attachment 114398 [details] Simple VBA Macro to trigger Range().Borders().Weight() regression Steps to reproduce 1. Open Attached file VBARegression.xls. This file has been created with MS Office 2007 2. Activate Macros if asked to. 3. Click on the button Expected result : Borders must be re-drawn Result on LibreOffice 4.1.4.2 (Windows) : Ok Result on LibreOffice 4.2.0.1 (Windows) : Ok Result on LibreOffice 4.3.0.1 (Windows) : "Erreur d'exécution BASIC. '1' . Type: com.sun.star.uno.RuntimeException Message: Method failed." Code to blame for the error: ".Borders(xlEdgeBottom).Weight = 2" Result on LibreOffice 4.3.6.2 (Windows) : Same error. Result on LibreOffice 4.4.1.2 (Linux) : Same error Additionnal info : The macro behaves as expected if the border is not initialy drawn :(see file VBARegression_NoBorder.xls).
Created attachment 114400 [details] Same VBA code, but no border initialy drawn
I can confirm with LO 4.4.1.2, win7 Works OK in excel 2010. Error message in LO, when borders are deleted macro works.
git bisect log # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327 # bad: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e git bisect bad 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02 # good: [51b63dca7427db64929ae1885d7cf1cc7eb0ba28] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10 git bisect good 51b63dca7427db64929ae1885d7cf1cc7eb0ba28 # bad: [d65a58c31c8da044ef66ae4517fa2fe74cec0019] source-hash-2e053cf5ea4d93a2e1845e795a9c7fe1e08c84af git bisect bad d65a58c31c8da044ef66ae4517fa2fe74cec0019 # bad: [79e02001f27d33b3b478324ab6fba5683413b4d9] source-hash-b6c016da23d309b4ac7d154bc33a22397974ed73 git bisect bad 79e02001f27d33b3b478324ab6fba5683413b4d9 # good: [183a576d94de9a9439d580c8b81f335ab57cdbdc] source-hash-a599f5b4b51848e3b397d471c9d12b373caadcef git bisect good 183a576d94de9a9439d580c8b81f335ab57cdbdc # bad: [a67b874d60de1f1a44bef57a53a7b8a84db0ba58] source-hash-19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7 git bisect bad a67b874d60de1f1a44bef57a53a7b8a84db0ba58 # good: [7fd8bdb3b18f50ea0adbc0a5e611f6a844b23189] source-hash-a1ac2538e9b287444500618ab4d2f0f06c25cf34 git bisect good 7fd8bdb3b18f50ea0adbc0a5e611f6a844b23189 # first bad commit: [a67b874d60de1f1a44bef57a53a7b8a84db0ba58] source-hash-19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7 http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=a1ac2538e9b287444500618ab4d2f0f06c25cf34..19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7
Raal: the range you got is quite weird (since it's ok in 4.1.4.2 and 4.2.0.1.
(In reply to Julien Nabet from comment #4) > Raal: the range you got is quite weird (since it's ok in 4.1.4.2 and 4.2.0.1. Macro works in LO 4.1.5, doesn't work in 4.2.8 (tested on portable ver. on windows). My bibisect show 2012-11-13 / don't know where to find appropriate version / reverting tag bibisected. @Camille: Would now be nice to get a bibisect of the bug - https://wiki.documentfoundation.org/QA/HowToBibisect Please could you do it? If you need help - feel free to jump into the QA Chat: http://webchat.freenode.net/?channels=libreoffice-qa
@raal : never done it before, but I'll try.
(In reply to camille.moulin from comment #6) > @raal : never done it before, but I'll try. don't hesitate to ask at qa communication channels (https://wiki.documentfoundation.org/QA) or me directly
Created attachment 114441 [details] git bisect log output from bibisect-43all.tar.xz
Here is the output of git bisect log (also attached as file). Please let me know if I did'nt do it properly or if you need additionnal info. # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327 # good: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e git bisect good 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02 # bad: [8ad82bc1416a07501651e8d96fe268e47d3931d3] source-hash-13821254f88d2c5488fba9fe6393dcf4ae810db4 git bisect bad 8ad82bc1416a07501651e8d96fe268e47d3931d3 # bad: [238338bc4111eb82429ea47384d4012bcd7cdc3e] source-hash-b6ba04639b9922f6717f79ac4be215e09691d7a9 git bisect bad 238338bc4111eb82429ea47384d4012bcd7cdc3e # good: [89dc8a802d1625e0efd88ba0fb720b22be87f3f0] source-hash-da03bb1ee6a69d2f4fef4c3ca0adc0ba9588bd19 git bisect good 89dc8a802d1625e0efd88ba0fb720b22be87f3f0 # bad: [4d8d18a8c871d6803af99b706f780eb6e65c7a5d] source-hash-d4779887636fa9ab5b477f3436bcd3728a3e30ba git bisect bad 4d8d18a8c871d6803af99b706f780eb6e65c7a5d # good: [4e6ca16994d8627b4d31fe2399391ab82f06ba12] source-hash-68c3dfc3119a50ee9c9c6d65f4c656637152bbad git bisect good 4e6ca16994d8627b4d31fe2399391ab82f06ba12 # bad: [1c8ce1b905c9fd78415d666f7f0d9b39bd99a431] source-hash-eceecd4a3806f64c2e8fb0a3bcdcc43e1384779f git bisect bad 1c8ce1b905c9fd78415d666f7f0d9b39bd99a431
Oops, looks like I had forgotten one step. I did one more git bisect and got 5a52acff89c712acbd4be6896748c76a010cb507 is the first bad commit commit 5a52acff89c712acbd4be6896748c76a010cb507 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Wed Oct 16 14:01:44 2013 +0000 source-hash-07352f07ce40ef40e9b73fd05aa4f9c5eac38290 commit 07352f07ce40ef40e9b73fd05aa4f9c5eac38290 Author: Jack Leigh <leighman@gmx.se> AuthorDate: Tue Mar 5 16:19:58 2013 +0000 Commit: Michael Meeks <michael.meeks@suse.com> CommitDate: Tue Mar 12 15:35:34 2013 +0000 liblibo: move to C++ interface. Change-Id: Ie14a9446abd9524604feddf811d5373a26a30cbd :100644 100644 1bd86430233d1c4a124a71c5ae2eeba5e6cb8c56 7124957e08dd70b06e7fdb5e7dec0330a3a55bcd M autogen.log :100644 100644 b705dc1dceec16c40ec9aa1cfc22497c7bf59be8 7440de2ae3594ee3806e3855eb716bb4435ddb6b M ccache.log :100644 100644 49f986c8a78217b76e7a11195e4d686e49d73be4 a35421773c9f3b54fd3d3d687fa9fe7ab525e9c2 M commitmsg :100644 100644 038c6da92770a07e32d43ac3c4ac44a190ef1e10 1534c341abf32606f5798893082e21abddd1233e M dev-install.log :100644 100644 42fa6993f3e8dfe3c9c4dee81b2d9dbbc9c57957 5c669da4e6f8357a8e47eff4c731a65183dcc576 M make.log :040000 040000 e62bf99593bfa573f70e250f6f1d1198e8e812a5 c69e681c86cd2bed701ae94ac119221a9f9e4c78 M opt
Camille, thanks!
This seems to have been broken by the below commit. commit d06f4577b52df5f390809850f26663e2e62d0ff1 Author: Noel Power <noel.power@novell.com> Date: Mon Mar 11 11:28:18 2013 +0000 bnc#805071 fix object assigment problems when default members present Change-Id: I6f7dfd369a36aff06f15b9a3affadb9d19787a9c
Adding Cc: to nopower@novell.com @Noel - sorry to pounce on you, but I noticed you had dropped by and were submitting some patches. I remembered I hadn't forwarded this one to you previously Thanks!
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170929
on my environment, aBorderLine.OuterLineWidth has the value 26, accorinding to SAL_INFO I added, but I'm not sure from what the value is produced. https://opengrok.libreoffice.org/xref/core/sc/source/ui/vba/vbaborders.cxx?r=4dfce6d2#214
just a guess https://opengrok.libreoffice.org/xref/core/sc/source/ui/view/tabvwsha.cxx?r=22c484b5#500 0.75[pt] * 1/72[inch/pt] * 2.54[cm/inch] = 0.0264 cm what if 1.00 * 1/72 * 2.54 = 0.0352 cm https://opengrok.libreoffice.org/xref/core/sc/source/ui/vba/vbaborders.cxx?r=4dfce6d2#47
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/357b36c7797ca7ac249714e5ddca1f04e0228c0e tdf#90278 - Set the vba border to the default border It will be available in 7.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.
Thx to @himajin100000@gmail.com for pinning the problem down!
Andreas Heinisch committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/3958431dffc5f588de7d96e3356ea301bd03f2a6 tdf#90278 - Set the vba border to the default border It will be available in 7.1.4. 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.
If we use the attachments in this bug report, we do not see errors, however we have to note that we wil see erros when we run macro if the width of the initially drawn border manually set by Format Cells dialog in Calc is not within the enum values, for example, 1.00pt.
Should we reopen the bug and check for a solution of any border weight? Should we try to match a given border as close as possible to the different enum values? Or is it even a problem with the compiler, since setting a weight does not need to call getWeight in https://opengrok.libreoffice.org/xref/core/sc/source/ui/vba/vbaborders.cxx?r=4dfce6d2#209.
Reopened because of comment 21.
very difficult decision, indeed. for now, as a workaround, I could propose an improvement in Exception message, and add notes on documentation for this design.
What dou you think about the following approach? https://gerrit.libreoffice.org/c/core/+/115150
Some observation: If you set any border in Calc and save the document to 97-2003 Excel, then only borders supported by excel are saved. Unfortunately, I don't know any code pointer of the export to the latter format. Maybe we can adapt the same functionality within the macro.