Description: In a macro: 1. Several cells are selected as a group. 2. The contents of the cells are then cleared. 3. The SaveAs command is then issued prompting the SaveAs dialog popup. As of a recent update, items 2 & 3 execute in reversed order. Steps to Reproduce: 1.Run the macro in the provided .ods file. 2. 3. Actual Results: 1. Several cells are selected as a group. 2. The SaveAs command is then issued prompting the SaveAs dialog popup. 3. The contents of the cells are then cleared. Expected Results: 1. Several cells are selected as a group. 2. The contents of the cells are then cleared. 3. The SaveAs command is then issued prompting the SaveAs dialog popup. Reproducible: Always User Profile Reset: No Additional Info: 1. Several cells are selected as a group. 2. The contents of the cells are then cleared. 3. The SaveAs command is then issued prompting the SaveAs dialog popup.
Created attachment 176782 [details] ODS File with a macro that easily demonstrates the bug This ODS file attachment easily demonstrates the bug.
(Unexpected behavior occurs in this version) Version: 7.2.4.1 (x64) / LibreOffice Community Build ID: 27d75539669ac387bb498e35313b970b7fe9c4f9 CPU threads: 4; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded (Expected behavior occurs in this version) Version: 7.1.8.1 (x64) / LibreOffice Community Build ID: e1f30c802c3269a1d052614453f260e49458c82c CPU threads: 8; OS: Windows 10.0 Build 22000; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
This will likely be obvious, but I will mention it anyway. In the testcase file, run the macro by simply clicking the big blue "Clear All" button.
Just wanted to add here that the macro commands do fully and properly execute, but that the DISPLAY of those operations appears out-of-sequence. This was not the case in earlier LO versions (e.g. 7.1.8) So this is mostly a visual problem, but a potentially confusing one.
Hello, when I click Clear all button, the save as dialog appears - when I move the dialog, I can see that range C2:C7 is deleted. As you mentioned in comment 4, DISPLAY of those operations appears out-of-sequence, but it's too quick to see it. Maybe some Wait command would help? Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 2f4f4cbeb8e50081d607b86b0475b93971c40ab8 CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Jumbo
Thanks for this feedback raal, I'm seeing a slightly different bevavior in v7.2.5 (Windows 11). Moving the saveas dialog has no effect, and the cells remain filled. The cells are only cleared after I click save or cancel on the saveas dialog. Additionally, I tried your suggestion of adding a wait to the macro (we think alike). With a 500ms delay before the saveas request, everything sequences as expected. So that is a workaround, but I would need to edit numerous files to implement. My main reason for the original post is the concern that the change in behavior from previous versions might have additional ramifications. Best Regards, DB Version: 7.2.5.2 (x64) / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 4; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Following up: I have done further testing by adding a delay (100ms in this case) to a similar macro in files that were impacted by this issue (6 altogether). Delaying the request a little for the saveas dialog has mitigated the problem. However, it does seem like a difference in behavior from previous LO versions that should be of interest from a QA perspective. It leaves me wondering if other macro / scripted commands might have similar issues with timing. Version: 7.2.5.2 (x64) / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 4; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
(In reply to Daniel Baran from comment #7) > It leaves me wondering if other > macro / scripted commands might have similar issues with timing. I bibisected the bug to commit 1c1226709c6be39c5462f5e6e1262ca630b30b34 which is my change "tdf#106282 Change Windows File Dialog to run on the main thread". In that change the timing of when the Windows File Dialog opens is improved so that it happens sooner on the main thread. The issue described is probably only related to Windows File Dialogs and may have something to do with the threading interactions. Someone more familiar with how macros work may be able to describe why this is happening, but the output behavior still works as expected so this may just be UI-specific (i.e. maybe change the title of the bug).
I'm not quite understanding: "In that change the timing of when the Windows File Dialog opens is improved so that it happens sooner on the main thread." The original concern was that the File Dialog was opening too soon. That is, before the other macro-invoked delete operation could run. When I put in a 100ms delay for the SaveAs everything appeared as expected. So I slowed the SaveAs dialog call to make a correction. That said, I don't object to changing the title if you have any suggestions.
(In reply to Daniel Baran from comment #9) > I'm not quite understanding: > > "In that change the timing of when the Windows File Dialog opens is > improved so that it happens sooner on the main thread." > > The original concern was that the File Dialog was opening too soon. > That is, before the other macro-invoked delete operation could run. > When I put in a 100ms delay for the SaveAs everything appeared as expected. > So I slowed the SaveAs dialog call to make a correction. > > That said, I don't object to changing the title if you have any suggestions. Yes I'm just saying that the original concern is due to the change that I linked. I'm just trying to explain the behavior; your workaround seems to be still valid. I updated the title. Someone may be able to fix this and then your workaround wouldn't be needed.
Mike, can you explain this?
I am unsure what the problem is here. Is the resulting file missing some updates? Or is it just annoying unupdated view that worries you?
(In reply to Daniel Baran from comment #4) I see now that the visual problem is considered confusing.
(In reply to Matt K from comment #10) The dialog now blocks the main thread (that runs the main message loop), using its own system message loop, and so the own events don't get executed (at least until some system event comes that is dispatched to something that would call Application::Yield()). You may see that e.g. if you run the macro, and then in the unrefreshed view and the dialog on screen, you attempt to open another LO document, that document will open, and the view will refresh. I believe you need to check how can we tailor the dialog to use or own code calling Application::Yield() periodically.
(In reply to Mike Kaganski from comment #13) > (In reply to Daniel Baran from comment #4) > > I see now that the visual problem is considered confusing. Yes, that was it. Not a big problem, and I was able to address it in my macro. I just thought it might be meaningful since the behavior changed from a previous program release though the macro hadn't changed.
Mike, should this be confirmed?
Yes, the failure to process application events while in the dialog is problematic. Potentially more problematic for documents open in parallel. I can't provide a possible scenario, but it looks less than ideal. Possibly having a timer, which would run during the dialog open, and its events would explicitly process the queue...