Suppose you want to run a macro named "MyMacro" from "Module1" in the "Standard" user library. If you use the "Macro Selector" dialog, you have to go to Tools - Macros - Run macro and then: 1) Click the expand ">" sign in "My Macros" 2) Scroll down until you find the "Standard" library and click the ">" sign again 3) Find the module "Module1" and click ">" again 4) Find the macro "MyMacro", select it and click "Run" (or double-click it) Now suppose you want to run the same macro again and go to the "Macro Selector" dialog. When the dialog opens, all macro containers will be collapsed and you'll have to navigate through all containers, libraries, modules again till you reach the desired macro. I would like to propose an enhancement to the Macro Selector dialog: it should remember the last run module/macro, so that when the user runs a macro and then open the dialog again, the previously run module/macro will be selected by default. The "Macro Organizer" (Tools - Macros - Organize macros - Basic) dialog already has a similar behavior to what I'm proposing. When you run a macro from a certain module, when the dialog is opened again the previously selected module is remembered, which is very handy. However, it does not remember the last run macro, which should be selected by default.
Is this a duplicate of bug 145848? Well, not the beanshell/javascript part but the missing navigator issue - that I don't see.
Created attachment 176748 [details] Video capture showing the problem (In reply to Heiko Tietze from comment #1) > Is this a duplicate of bug 145848? Well, not the beanshell/javascript part > but the missing navigator issue - that I don't see. Bug 145848 is very similar, but it is about a different dialog (Tools - Macros - Organize Macros - Basic). My bug report is about Tools - Macros - Run Macro (which opens the Macro Selector dialog). The main advantage of the "Macro Selector" dialog is that it lets you run Python scripts as well as Basic scripts, hence it is very useful. What I would like to suggest is that the Macro Selector remember the last run macro. See the video I've just attached where I run the same macro twice. Notice that in the second run I have to navigate all containers, libraries, modules again to get to the same macro. Based on bug 145848 I believe remembering the last run/edited macro is the expected behavior, however it is not implemented in the Macro Selector dialog.
(In reply to Rafael Lima from comment #2) > What I would like to suggest is that the Macro Selector remember the last > run macro. I support this request.
Heiko, I would like to give this one a try. However, I have no idea how I should save/restore this information. Do you know any similar patch I could study about this?
(In reply to Rafael Lima from comment #4) > Do you know any similar patch I could study about this? Some places in the code for "LastUsed", for example *LastUsedFilter. Another example might be the tip-of-the-day that stores the last shown tip (and other info) in the registry. See https://gerrit.libreoffice.org/c/core/+/69498
Proposed patch available for review at: https://gerrit.libreoffice.org/c/core/+/142632
Rafael Lima committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/792e41314f321f54b3b2fc4d01c8b62a3b704e9e tdf#145978 Remember last run macro in Macro Selector dialog It will be available in 7.5.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.
Rafael Lima committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bc5856c5c77a7ee18377cd274960950d8943178f Related tdf#145978 Fix workaround in kf5 It will be available in 7.5.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.
Fix verified in: Version: 7.5.0.1 (X86_64) / LibreOffice Community Build ID: 77cd3d7ad4445740a0c6cf977992dafd8ebad8df CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Thanks Rafael!