Description: After selecting an array of cells and invoking Find & Replace with [Ctrl]+H and the find and replacement "text" is committed for [Replace All] then the resulting pop-up "Search Results" pane can no longer be moved to a preferred location. Previously, it was possible to relocate it to permit its close button to appear on top of the close button for the originating "Find & Replace" pane - thereby obviating any requirement to scroll around the screen to close all redundant panes. "click click" Workaraound: Relocate the "Find and replace" pane to wherever the "Search Results" pane decides to rear its ugly head. Non-Urgent but something went wrong somewhere because I believe all other pop-up panes retain their mobility Steps to Reproduce: Create an array of random information Select the array and combine [Ctrl]+H Make any random replace you desire Select Replace All Move the resulting Search results pane to any random location and accept the change Close the pane Repeat all the above steps and observe that your mobility is seriously impaired. Actual Results: Search results pane appears at its own preferred location Expected Results: Do as I say - or die in the effort to satisfy my unreasonable demands Reproducible: Always User Profile Reset: No Additional Info: Version: 7.4.7.2 (x64) / LibreOffice Community Build ID: 723314e595e8007d3cf785c16538505a1c878ca5 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: sv-SE (en_GB); UI: en-GB Calc: threaded
Created attachment 188157 [details] Screen grab showing the affected panes
Not reproducible Version: 7.5.4.2 (X86_64) / LibreOffice Community Build ID: 36ccfdc35048b057fd9854c757a8b67ec53977b6 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
(In reply to m.a.riosv from comment #2) > Not reproducible > Version: 7.5.4.2 (X86_64) / LibreOffice Community > Build ID: 36ccfdc35048b057fd9854c757a8b67ec53977b6 > CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: > win > Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Different Machine, brand new installation of Version: 7.5.4.2 (X86_64) / LibreOffice Community Build ID: 36ccfdc35048b057fd9854c757a8b67ec53977b6 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_SE); UI: en-US Calc: threaded Still produces the error. I note you're using build 22621 - is that something that's only available to support staff. Also, you have a higher thread count 16 v 4 Did you try to relocate just the pop-up pane that confirms the amendments whilst it was active and then close everything before invoking a fresh Ctrl+H?
This is win11 even the system report to LIBO as win10, and threads' number I think doesn't matter. Maybe I'm not able to follow right your steps, but I can't reproduce the issue.
(In reply to m.a.riosv from comment #4) > This is win11 even the system report to LIBO as win10, and threads' number I > think doesn't matter. > > Maybe I'm not able to follow right your steps, but I can't reproduce the > issue. Perhaps it's more Windows related as I've also noticed that files no longer open in their closed location but appear to have the "offset" occurring with the windows "cascade" opening. Maybe best to abandon the report as it's effectively a cosmetic effect distracting from functional issues.
Possible something involving windows, what you can try is updating the graphics card driver, directly from the vendor, no only from windows update. Lets it opened for a while, maybe someone it's able to reproduce.
(In reply to m.a.riosv from comment #6) > Possible something involving windows, what you can try is updating the > graphics card driver, directly from the vendor, no only from windows update. > > Lets it opened for a while, maybe someone it's able to reproduce. Sorry, I think I misled you. I didn't mean windows cascade was malfunctioning for general file opening I meant that LO files, when opened, no longer appear in the original position but seem to be offset as though they were "cascading" and that the inability to relocate the Ctrl+H results window may have commenced at around the same time as I noticed that anomaly.
Don't worry, but better let it opened, maybe someone else it's able to reproduce.ce.
I can actually reproduce the dialog position not remembered on Linux too, since many versions ago. Using Ubuntu 20.04 with GNOME 3.36.8 and: Version: 7.5.4.2 (X86_64) / LibreOffice Community Build ID: 36ccfdc35048b057fd9854c757a8b67ec53977b6 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: fr-FR (en_AU.UTF-8); UI: en-US Calc: threaded Colin, can you report which LO version was remembering the dialog position as expected? Depending on if it's a Windows-specific regression or not, we could mark as duplicate of bug 117717.
(In reply to Stéphane Guillou (stragu) from comment #9) > > Colin, can you report which LO version was remembering the dialog position > as expected? > Sorry, I believe the anomaly would only have been within the previous two updates but honestly can't remember
(In reply to Stéphane Guillou (stragu) from comment #9) > Colin, can you report which LO version was remembering the dialog position > as expected? Is this bug 156122 about remembering the position of the search results window? Or is it about not being able to move the window? (In reply to Colin from comment #0) > Repeat all the above steps and observe that your mobility is seriously > impaired. > > > Actual Results: > Search results pane appears at its own preferred location FWIW, on MS Windows I can move the resulting window every time, tested on several versions.
(In reply to ady from comment #11) > (In reply to Stéphane Guillou (stragu) from comment #9) > > Colin, can you report which LO version was remembering the dialog position > > as expected? > > Is this bug 156122 about remembering the position of the search results > window? Or is it about not being able to move the window? > It's a duality. It remembers its own preferred location of the search results window and ignores the new location when I move it to a new position. It always appears where it wants to be - not where I tell it to remain.
(In reply to Colin from comment #12) > It always appears where it wants to be - not where I tell it to remain. Then what do you mean with "mobility is seriously impaired"? Quoting your comment 0: "can no longer be moved to a preferred location". For me, this report is not clear. I tested your STR from comment 0 in several versions, attempting to _move_ the search results window (performing the steps twice in each version) according to your STR. But now you say that you _are_ able to move the window (without problem), and that the problem is that the location is not where you left it after the prior search/replace run. This is nowhere in your comment 0. If you meant that you were emphasizing the "preferred location", the wording was far from clear. FWIW, the position of the search results window is not remembered from the prior run; it is placed centered on the screen. If it were to be remembered, I would suggest it should be limited to the session, not further.
(In reply to ady from comment #13) > (In reply to Colin from comment #12) > > It always appears where it wants to be - not where I tell it to remain. > > > FWIW, the position of the search results window is not remembered from the > prior run; it is placed centered on the screen. If it were to be remembered, > I would suggest it should be limited to the session, not further. That seems to be the issue in a nutshell - it used to stay where I put it in the previous session. I spent years with it remaining where I set it so that I didn't have to chase my tail around two monitors trying to find where it decided to hide itself. MOBILITY: The ability to move around at will Seriously impaired mobility: Somebody stole my zimmer frame
(In reply to Colin from comment #14) > That seems to be the issue in a nutshell In a nutshell: * the STR from comment 0 are not representative of the problem * moving the search/replace result window is not a problem * the current subject/title of this bug 156122 ("CALC Find & Replace - CtrlH - Search results pane can no longer be moved to a preferred location") is not representative of the problem * most of the comments of this bug 156122 until now are not relevant FWIW, I wasn't able to find a LO version that would remember the position of the search results window on MS Windows. Setting this as duplicate for bug 117717. *** This bug has been marked as a duplicate of bug 117717 ***
(In reply to ady from comment #15) > (In reply to Colin from comment #14) > > That seems to be the issue in a nutshell > > In a nutshell: > * the STR from comment 0 are not representative of the problem > * moving the search/replace result window is not a problem > * the current subject/title of this bug 156122 ("CALC Find & Replace - CtrlH > - Search results pane can no longer be moved to a preferred location") is > not representative of the problem > * most of the comments of this bug 156122 until now are not relevant > > FWIW, I wasn't able to find a LO version that would remember the position of > the search results window on MS Windows. > > Setting this as duplicate for bug 117717. > > *** This bug has been marked as a duplicate of bug 117717 *** In a Coconutshell........... There, Fixed it for ya xxx