Cannot assign macro on Windows11 LO v7.4.2.3 x64 but can on Windows8.1 LO v4. once macro assigned on Windows8.1 system sheet Tools menu with macro functions on either system.
Function appears to add but when closed the sheet undergoes recovery every time and the attempted change is lost. No such fail on Windows8.1 and have used that system and function several years w/o issue.
Correction, function working on Windows8.1 LO version 6.1.0.3 x64 and not v 4.0. Bug on LO v7.4.2.3 x64 remains. Have since removed LO 7.4 from Windows11 and installed v 6.1.0.3 x64 in its place and the function works normally as it did on Windows8.1 so bug is in LO between these two versions..would like to upgrade to most current version of LO that does not have this bug.. advise?
Behavior very similar to bug 121822. If macro not assigned to Tools Menu, macro can run from Run Macro and executes properly. If Assign is attempted sheet crashes on close and recovery loses the Assign attempt but macro is still available via "Run Macro"
Could you please provide: - A precise series of steps to reproduce the issue - If possible, an example document that makes it easier to reproduce the issue - The information copied from "Help > About LibreOffice" Thank you!
Thanks for the response. Steps taken: Open libreoffice sheetX.ods Go to Tools menu Go to Macros Go to Organize Macros Go to LibreOffice Basic Open sheetX.ods choice Open Standard Select/open Module3 Select TestA macro in Module3 Select Assign from right side menu (Lo then presents Customize menu) Right side: Select Target .. Tools Go to left side and select Category .. Macros Open sheetX.ods choice from macro list Select Module3, select TestA macro Use "Add Item" arrow (right pointing toward Function section) TestA macro appears in Tools list. Move TestA down in Tools list to appropiate position. Click OK option at bottom. (** see note at end re behavior change using v7 at this point **) Then Close. For version 6 this returns to the open spreadsheet (sheetX.ods) The Tools menu now displays TestA option and that option now executes the macro TestA when selected. Spreadsheet can be closed normally and subsequently reopened with the TestA macro option still in Tools menu and functional. (** at the point marked above by the note, when using v7 the sheet automatically aborts .. closes ? .. and the attempt to reopen results in "Recovery" option menu. Recovery results successfully but the Tools option list is back to "before the Assign attempt", the macro is still available in the module 3 and can be run using Tools/Macros/Run Macro function. **) The Assign process is the fail. Works as described for V6, fails as described is using V7. I have fallen back to V6 to use this function. An aside is when the sheetX is modified using v6 and LO is upgraded to v7 the Tools list contains the macro assigned using v6 and can be run normally from the Tools menu. So the fail is in v7 Assign process code. All attempts in this example are run on current Windows 11 home system, version 22H2.
[Automated Action] NeedInfo-To-Unconfirmed
Did you forget to attach sheetX.ods? If so, you can use the "Add an attachment" button above. Or are you not sharing it because of sensitive data?
SheetX and TaskA are ficticous generics easily created from blank LO. The bug was found using confidential data that cannot be shared. There is sparce to no "help" for this function in LO Help function. Might be a good work item for someone to generate some helpful text.
I could not reproduce the issue with: Version: 7.4.3.2 (x64) / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded nor: Version: 7.4.3.2 / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: de-DE (en_AU.UTF-8); UI: en-US Calc: threaded Do you know that you can access the Customize menu directly from "Tools > Customize"? Do you also have the same issue when adding the macro to the menu using "Tools > Customize directly"? Please also try: - Installing version 7.4.3, and see if issue persists - See if you still see the issue in Safe Mode (Help > Restart in Safe Mode)
Yes aware Customize can be accessed via Tools/Customize. Same code and error is at close though. Would note running Win 11 not 10 so may be difference there. Have tried Safe mode with this system with same result. Might take a while but I will try 7.4.3 to see if I can reproduce via any of the three paths mentioned including Safe mode. Will report results. Thanks
Created attachment 183987 [details] sample macro assignment test sheet Have installed LO v7.4.3 and run macro assignment test using the sample sheet provided. Assignment now works with this version of LO on Windows 11 2H22. Thanks.
Created attachment 183989 [details] FAILING CALC ODS FILE Reopened: Assign function worked on LO v7 using simple sample file but still fails on v7.4.3 using more complex sheet attached. Data removed from pages but macro function ccan be tested. 1. Go to Assign Function > menu Tools/Customize 2. Find "Target" Tools-EXECUTE submenu 3. Select Categories Macros/TRYTHISONE/Module2/TEST (not TestA) 4. Insert to Submenu EXECUTE 5. Select "OK" System fails and forces recovery. Macro not Assigned. All the Tools User-macros and Submenu EXECUTE have been added with LO v6 since not possible using v7. Bug still persists. Have reinstalled v6. Will remain on V6 until bug is resolved.
Thank you! Reproduced as in comment 12 (although going directly to Tools > Customize) with: Version: 7.4.3.2 / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: de-DE (en_AU.UTF-8); UI: en-US Calc: threaded Pressing OK to add the macro to the menu hangs LibreOffice. Regression, as it does not happen with: Version: 7.3.7.2 / LibreOffice Community Build ID: e114eadc50a9ff8d8c8a0567d6da8f454beeb84f CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Not specific to the Tool menu, I can reproduce with others e.g. File. Bisected to: db884ee9f4a730c81d95afbd83283fa786c26b05 is the first bad commit commit db884ee9f4a730c81d95afbd83283fa786c26b05 Author: Jenkins Build User <tdf@pollux.tdf> Date: Fri Mar 25 08:28:04 2022 +0100 source 6e135909d398a08105e2df4cae834e73f253b440 instdir/program/libfwklo.so | Bin 5393512 -> 5393512 bytes instdir/program/setuprc | 2 +- instdir/program/versionrc | 2 +- 3 files changed, 2 insertions(+), 2 deletions(-) Which points to: commit 6e135909d398a08105e2df4cae834e73f253b440 author Stephan Bergmann <sbergman@redhat.com> Thu Mar 24 13:52:44 2022 +0100 committer Stephan Bergmann <sbergman@redhat.com> Fri Mar 25 08:21:14 2022 +0100 tree 51bcfd722ca5f18947b0e707150206e6d38b072d parent 9fd5446c6f3281789ed21847f25cf56ce84dd395 tdf#147668: Destroy still needs to do its work when called from disposing Which was itself a fix for a regression introduced by: commit d4257daba1155ebccbfebea99bad0e4152ca9b08 author Noel Grandin <noelgrandin@gmail.com> Fri Dec 24 20:58:28 2021 +0200 committer Noel Grandin <noel.grandin@collabora.co.uk> Sat Dec 25 19:34:05 2021 +0100 tree de234db817ce25b7196bde62339d9b76da24dd7e parent 98dbe250d7d5e3ebe626e8c8650e7fdccd399869 use comphelper::WeakComponentImplHelper in MenuBarManager Stephan and Noel, could you please have a look? Thanks!
(In reply to Stéphane Guillou (stragu) from comment #14) > Bisected to: > db884ee9f4a730c81d95afbd83283fa786c26b05 is the first bad commit > commit db884ee9f4a730c81d95afbd83283fa786c26b05 > Author: Jenkins Build User <tdf@pollux.tdf> > Date: Fri Mar 25 08:28:04 2022 +0100 > > source 6e135909d398a08105e2df4cae834e73f253b440 To avoid guesswork, please always state which repo was used for bibisecting.
fix at https://gerrit.libreoffice.org/c/core/+/143671
Thanks. Re comment 15, Please note comment 12 identifies specific failing version as 7.4.3. Re comment 16 "fix" ?? Is this a coding fix suggestion for LO internal? Is this fixed in v7.4.3 ?? for the user?
(In reply to wzpdisp from comment #17) > Re comment 15, Please note comment 12 identifies specific failing > version as 7.4.3. Still, it avoids any unnecessary guesswork if you state the repo that has been used.
Sorry, My bad. I thought it obvious since I followed the suggested v7.4.3 D/L from https://www.libreoffice.org/download/download-libreoffice/ presuming that was sufficient designation (latest public build of the code). To be clear is v7.3.7.2 the latest version where this Assign function will work properly?
(In reply to wzpdisp from comment #19) > Sorry, My bad. (Just to make it clear, my request in comment 15 had been directed at the author of comment 14.)
Sorry, names are similar and I was asleep at the switch. Thanks for the help.
Stephane, thanks for the help. Have moved to v7.3.7.2 and can confirm that version works.
Fix merged as commit 80ef2a46f4ac2ac6f3b14561a195262156fe4b85 for trunk (upcoming 7.5.x series) and as commit 3883454e64d8723d27d357f5fa3c213df59773ca for 7.4.4
(In reply to Stephan Bergmann from comment #15) > To avoid guesswork, please always state which repo was used for bibisecting. Thanks Stephan, will do from now on. It was the Linux 7.4 repo. Thanks Noel for the fix, and Adolfo for the heads up. I can verify the fix in: Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: da3dd48eaf9086f8ab28d6a6655f9a638e51433a CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded wzpdisp: yes, feel free to use 7.3.7 for now, as that branch did not have the bug you described. Moving forward, you can upgrade to the fixed versions 7.4.4 or 7.5.0 when they are released. Cheers