Win 11, strange position of a dialog box sent by SHFileOperationW

[d7_2_laz]

No, no Lazarus (4.6) issue here. But i'm not sure if it's possible to solve, with Lazarus means, the following strange phaenomen i found when coming from Windows 10 and trying some apps on Windows 11.

Scenario: a file Manager invoking a "Paste" command via context menu on the listview on the right side. So the current mouse position is on the right side of the app, above the listview.
For the paste of file(s), at the end the API 'SHFileOperationW' is called, as exposed in shellapi.pas.

Code: Pascal  [Select][+][-]

1. Function SHFileOperationW(lpFileOp:LPSHFILEOPSTRUCTW ):Longint;external shell32 name 'SHFileOperationW';

In Windows 10, an error box triggered by SHFileOperationW resp. a dialog box asking for a decision, usually was rendered near the mouse pos. Here: somewhere on the listview, at least as far there's sufficient space.

In Windows 11: see yourself (attached image). The dialog (meaning something like 'file already exists, what do you want to do?') mostly is presented on the left side without any obvious reason. Btw, saw this with other file Managers too. A web research didn't point out really helpful stuff explaining the changed behaviour.

Not severe of course. But a bit annoying though - and i'd be interested if others encountered such similar too. And if it's possible to preserve the old behaviour with reasonable means.

[zeljko]

MS Wayland ?

[d7_2_laz]

In how far Wayland zeljko ? 
MS Windows 11 ...    For me plenty of curiosities btw and to find workarounds  ... eg. some might have noticed that in some favourite file managers, from their context menu, sub menu "New", the possibility to create "New text documents"  had been removed. Nice and helpful, this kind of interface reimplementation .... 

[d7_2_laz]

Just for info i show the same principle happening on another file manager (FreeCommanderXE), where i simply assume that it's
using the same or similar API call. Note: cursor pos when doing the "Paste" is above the _listview_.

The dialog box' window pos could be somehow changed programmatically?


PS: if a *moderator* should read this: would you be so kind as to move this topic beyond "Operating Systems" > "Windows"?
I didn't store it beyond "Widows" simply by mistake and cannot change this.

[Martin_fr]

Two monitors with different DPI / PPI settings? I haven't seen that exact effect, but Windows 10 has had some glitches for that. Maybe 11 has some too.

Otherwise, was there a prior popup of similar type, and the position is related to that prior popup? That is actually a very far fetched idea. That is something I have (at least in the past) observed with tons of apps when the user used the smiley IME with them. So this is likely not the case here.

Otherwise: mouse position at the time of issuing the command vs getting the popup? Again just a random idea. No particular reason ....


I also notice that in the image it is above the top left corner of the listview. Is that always the case. Then maybe it wants to be relative to a selection in the listview, but the function to get the selection is not implemented (maybe custom drawn, so windows does not know).

It also the edge of the form, so maybe there is a WM_message sent to the form, and that is not answered....

[Bart]

MS Wayland ?

LOL

Bart

[d7_2_laz]

@Martin_fr, many thanks for replying!

I hadn't focused explicitely onto the topic DPI / high-DPI / PPI (on old host vs. new host) yet, an area where i'm not so familiar yet; my todo.
But, as my first suspicion had been (somehow depend), 'scaling', i had set for test the scaling from 125% (actual value) to 100 %, without noticeable impact.

As i previously had read some web threads about the dual monitor theory (but, actually i've only the laptop's internal monitor available, screen res. 1920 x 1080; scaling 125 as well as a possible impact of 'remembered previous display configurations' combined with an advice to change,  i'd tried, within the Display settings, "Multiple Displays" > "Remember window locations based on monitor connection":
i did uncheck this -> no effect.
If i set, testwise, the screen res to 1280 x 1024 (that was the old monitor's setting, afair) -> no difference.

The SHFileOperationW-driven popup had been in Win10 the same as in Win11, afair. At least they appear to look mostly identical in Win 10 and 11 to my memory.
Besides: i'm aware that meanwhile MS had leaving SHFileOperationW paradigm; but that should not influence the window pos of the previous API-call.

"Mouse position at the time of issuing the command vs getting the popup": for me: in Win 10 somehow bound together - at least the popup stayed within the listview where the click on "Paste" triggered the command. If enough space available of course. In Win 11 completely separated: it looks like the popup does appear, whenever possible, on a same left side position, whereever the app's form and it's listview had been moved to. So, if i move the form more to the right side of the screen (with still having enough space for the popup!), the popup will emigrate out of the form (and the listview anyway), insisting on it's old used position on the left.
The second screenshot does show this separation between form and popup. Very strange and counter-intuitive.
I appears as if behind the scenes some different rules had been applied to let the popup appear on a fixed place, separated to the mouse pos.

About WM_messages not having been responded to / redirected to the form: could be, but hard to answer, as the previous Win10-desktop is no longer available for comparison purposes.

The good news: it's not a Lazarus issue :-)

[d7_2_laz]

Same occurs with DoubleCommander, which is afaik built with Lazarus and is using SHFileOperationW for the context menu's paste coammand too.
In the screenshot i marked with a red circle the position from where i triggered the context menu's paste command.

Everybody can easily reproduce it (or not) trying it ... by using from the portable version from 'Releases' on the right side of the page:  https://github.com/doublecmd/doublecmd

Anybody interested to verify if it behaves the same way on his own Win 11 system?
Copy a file from the left panel to another folder on the right panel, containing a file having the same name.
(Could help: if it behaves differently, this indeed would indicate that's something special in the settings .....)

[LeP]

This is the normal behaviour of SO in WIndows 11, I think.

One can try without install nothing: simply try to copy a file in a system folder and see where the dialog box is proposed.

The comportment is the same like you observed.

P.S.: some time ago, when you moved the dialog box, Windows remembered this and suggested the new position (relative to the mouse position) in the next actions. Now it seems this no longer happens.

[d7_2_laz]

Big thanks for your attention LeP!
But it think: not, because for my impression in MS Explorer itself the popup does not appear decoupled from the mouse pos (resp. the point of calling the Paste), but it appears to stay more or less close to it.

My scenario as screenshot (no system folder here, ok) - the red circle marks the cursor pos for opening the menu and triggering Paste here ...
I'd feel it as just as expected, but different to the other apps.

[LeP]

For me this is....

EDIT:

Another try ... other position...

[d7_2_laz]

Again thanks LeP for the possibility to speak about!

What i think: the essential point is that the popup mostly tries to stay more or less within the control mainly affected: the listview.
So i'd see basically no problem in your screenshots.

Assume you're working with two panels (treeview left, file listview right; resp. two listviews [doublecommander]), i'd guess when triggering an action on the right panel and seeing the questioning popup appearing on the left panel, that would be felt as not what one would intuitively expect.

MS Explorer behavious stays ok, and nearly all of the other file managers go lost here and have few chances to react .....