STR --- (1 ) Ensure that you have macro recording enabled (Tools > Options > Advanced > "Optional Features" > "Enable macro recording (may be limited)". Restart LibreOffice if this is a change. ( 2) Start writer. Program presents Writer window "Untitled 1" ( 3) Start macro recording (Tools > Macros > "Record Macro"). Observe floating window "Record Macro". ( 4) In Writer window "Untitled 1", click in the document area and type "asdf". ( 5) In floating window "Record Macro" click <Stop Recording>". Program presents dialog "LibreOfficeDev Basic Macros". ( 6) In pane "Save Macro In", click "Untitled 1" ( 7) In "Macro Name", type "alpha" and click <Save>. Program closes dialog "LibreOfficeDev Basic Macros" and presents dialog "New Module" with Name defaulted to "Module1". ( 8) in dialog "New Module" click <OK>. Program closes dialog and returns focus to Writer window "Untitled 1". ( 9) Take menu options Tools > Macros > "Organize Macros" > "LibreOfficeDev Basic...". Program presents dialog "LibreOfficeDev Basic Macros". (10) In pane "Macro From", expand "Untitled 1" > Standard > Module1 and click on Module1. Observed : In pane "Existing Macros In: Modle1" is macro name Main. Expected : In pane "Existing Macros In: Modle1" is macro name alpha. The macro name Main is selected. (11) Click <Edit>. Observe line 17 ... args1(0).Value = "asdf" ... showing that this is indeed the macro you just recorded. I made these observations against daily dbgutil bibisect repository version 2015012024 executing in debian-stretch; and I saw the same thing in bibisect repository 43all version oldest and in a recent daily build executing in Windows Vista.
Repro. Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: a4764cfa80270f973da5861d0ddc28298bf16f4d CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-12-24_22:45:12 Locale: fi-FI (fi_FI)
The offending lines seem to be 309-311 in basctl\Sources\source\baside\basisides1 OUString sModuleCode; if ( aDocument.createModule( aLibName, aModName, false, sModuleCode ) ) pModule = pBasic->FindModule( aModName ); The name of the new macro is not passed as an argument to createModule method. And in createModule, it does not seem to be any support for a "new name". (See the line 658 in basctl In the file basctl\Sources\source\basicide\scriptdocument.cxx)
Repro. If the test is conducted on a new document without module, the name provided by the programmer is not taken into account. I observe the following sequence: the name is provided in the Macro dialog box, the box closes to make way for the box asking to enter a module name (Module1 is proposed). The "ScriptDocument::Impl::create" method into the file bastl\Sources\source\basicide\scriptdocument.cxx (line 658) is invoked (where Where the text "sub Main..." is inserted). If the test is conducted on a document (Writer), which already contains a module, the macro is created with the name specified by the programmer.
By the way, to work around the problem, just create a module before starting recording a first macro in your document.
The source of the problem is a behavior dialogs involved in creating a macro. In the following explanation, I refer to macrodlg.cxx file (in basctl). a) When you click in the field m_pMacroBox (the tree view showing the libraries, modules, macros), the text field m_pMacroNameEdit (the text field where the user enters the name of the macro) is emptied, unless the click is made at a module name. This never happens with a blank Writer file! The behavior m_pMacroNameEdit field is desirable in a context where macros already exist in the Writer file. b) m_pMacroNameEdit field is also cleared (ie set to "") when the user tries to save his macro in an existing unit file and then the dialog "Module" appears with the default name " Module1 ". The creation of the new module occurs on line 368. To work around the problem (solve it), a backtrace in gdb helped me understand that to move the line of code 'OUString aSubName m_pMacroNameEdit- => GetText ();' (372) before the line of code "if (! PModule) '(366) was sufficient. Why? Because of b) above. It is not normal that the opening of the dialog box "Module" erases the text field of the macro name. I have not yet found the source of the problem, but in the meantime the solution of moving the line of code works! Pierre
Pierre: where is your commit that fixes this? Did you forget to reference this bug in your commit message like "tdf#96717"?
Indeed, the files have not followed. I'll post again.
Adding the following comment in line 366 of macrodlg.cxx tdf#96717. Save macro name before closure of basicmacrodialog.ui. The disappearance of the dialog box comes to the call of NewObjectDialog::NewObjectDialog in moduldl2.cxx (opening of modules/BasicIDE/ui/newlibdialog.ui), resulting of callling to createModImpl below.
(In reply to Pierre Lepage from comment #5) > The source of the problem is a behavior dialogs involved in creating a > macro. In the following explanation, I refer to macrodlg.cxx file (in > basctl). > > a) When you click in the field m_pMacroBox (the tree view showing the > libraries, modules, macros), the text field m_pMacroNameEdit (the text field > where the user enters the name of the macro) is emptied, unless the click is > made at a module name. This never happens with a blank Writer file! The > behavior m_pMacroNameEdit field is desirable in a context where macros > already exist in the Writer file. > > b) m_pMacroNameEdit field is also cleared (ie set to "") when the user tries > to save his macro in an existing unit file and then the dialog "Module" > appears with the default name " Module1 ". The creation of the new module > occurs on line 368. > > To work around the problem (solve it), a backtrace in gdb helped me > understand that to move the line of code 'OUString aSubName > m_pMacroNameEdit- => GetText ();' (372) before the line of code "if (! > PModule) '(366) was sufficient. Why? Because of b) above. It is not normal > that the opening of the dialog box "Module" erases the text field of the > macro name. I have not yet found the source of the problem, but in the > meantime the solution of moving the line of code works! > > Pierre In a), second sentence, read "This, presence of an existing module in the treeview, never happens with a blank writer file!"
By following the code with gdb, the macrodialog.ui modal window closes at runtime of line 966 in \ basctl \ source \ baside \ moduldlg.cxx ScopedVclPtrInstance <NewObjectDialog> aNewDlg (pWin, ObjectMode :: Module, true); This line of code calls for the opening of a new modal window to ask for the name of the future module in the current library. I am not sure if the behavior is the one sought. Are two modal windows allowed in LO, one relative to the other? For now, I will edit the comment as follows (directly in the source file in gerrit): // Retain the desired macro name before the macro dialog box is forced to close // by opening the module name dialog window when no module exists in the current // library.
Pierre Lepage committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0d9a7d03e325d8b7487c08e9448c8a6890821866 tdf#96717: The macro name desired by the user is now took into account. It will be available in 5.4.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.
I see good results on debian-stretch in daily Linux dbgutil bibisect repository version 2016-12-06. I am setting bug status VERIFIED FIXED. Thank you, Pierre.