Description: Previously, Libre Office macros always stopped at the following step: dispatcher.executeDispatch(document, ".uno:InsertSheetFromFile", "", 0, Array()) Unfortunately, this is no longer the case in version 24.8.7.2. Subsequent steps simply continue to be processed, essentially ending up in the wrong worksheet. I installed the old version 24.2.6.2, which still works. What could be the cause? Actual Results: macro does not stop Expected Results: Macro stops until dialog is processed Reproducible: Always User Profile Reset: Yes Additional Info: macro does not stop
Created attachment 200977 [details] Testfile with macro... Macro test: Import file into a new worksheet. Copy contents to clipboard, delete worksheet and paste from clipboard.
Why would a macro stop, when it's not requested to? If it used to stop there, it was a bug; and based on your observations, it's fixed now. If you need the macto to stop, just write it to stop.
Thank you for the quick reply. Perhaps the translator misinterpreted my translation. In version 24.2.6.2, macro processing paused until all dialog boxes had been processed. This is not the case in 24.8.7.2. I've attached the file "Untitled 1.ods". You can use it to test the behavior.
Repro using Version: 25.2.4.1 (X86_64) / LibreOffice Community Build ID: 09303ce8b49f86f106fccd32b1324662053027cc CPU threads: 24; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-GB Calc: CL threaded
cc: Noel Grandin <noel.grandin@collabora.co.uk> Hello guido.kuesters@unitybox.de , I have bibisected your bug, it first appears in 24.8, I checked 24.2 and it works through Master. bibisect-win64-24.8 commit e27c11381554557460042bc534a09a28c221801e (HEAD) Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Mon Feb 5 11:41:49 2024 -0800 source 5d993a39c60d9184ddc3dbdaa9854ec1ecc99464 source 5d993a39c60d9184ddc3dbdaa9854ec1ecc99464 instdir/program/scfiltlo.dll | Bin 4847616 -> 4847616 bytes instdir/program/sclo.dll | Bin 17321984 -> 17323520 bytes instdir/program/scuilo.dll | Bin 929280 -> 930816 bytes instdir/program/setup.ini | 2 +- instdir/program/vbaobjlo.dll | Bin 1745408 -> 1745408 bytes instdir/program/version.ini | 2 +- 6 files changed, 2 insertions(+), 2 deletions(-)
Strictly speaking, this is not a bug. The previous behavior was incorrect. As explained in the documentation of the XDispatch::dispatch() method [1], which is what eventually gets run when XDispatchHelper::executeDispatch is called: > By default, and absent any arguments, "SynchronMode" is considered FALSE and > the execution is performed asynchronously (i.e. dispatch() returns immediately, > and the action is performed in the background). But when set to TRUE, dispatch() > processes the request synchronously". So the change that Noel has implemented can be seen as an *improvement* and making the default processing to comply with the specification. But the following code, which should be the actual subject of this bug, also calls MessageBox immediately, and doesn't wait for the .uno:InsertSheetFromFile to finish: Sub testSyncDispatch document = ThisComponent.CurrentController.Frame dispatcher = createUnoService("com.sun.star.frame.DispatchHelper") Dim sync(0) As New com.sun.star.beans.PropertyValue sync(0).Name = "SynchronMode" sync(0).Value = true dispatcher.executeDispatch(document, ".uno:InsertSheetFromFile", "", 0, sync()) MsgBox "Done" end sub So it should be worded something like "dispatch doesn't honor SynchronMode". [1] https://api.libreoffice.org/docs/idl/ref/interfacecom_1_1sun_1_1star_1_1frame_1_1XDispatch.html#a42beb1ea2ddae35c076b6e65867025ea
(In reply to Mike Kaganski from comment #6) > Strictly speaking, this is not a bug. The previous behavior was incorrect. > ... > So the change that Noel has implemented can be seen as an *improvement* and > making the default processing to comply with the specification. Sorry, I was wrong; DispatchHelper::executeDispatch is implemented to always call an internal executeDispatch with SyncronFlag set to true; and that itself adds SynchronMode to the arguments. Even though this seems to not be documented, XDispatchHelper::executeDispatch must always execute synchronously.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b80c7b05d0dcb080c7182c9f8610f06e1124d3bb tdf#166751: introduce sfx2::ExecDialogPerRequestAndDispose It will be available in 25.8.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.