unexpected behavior following F9

[johnhoh1]

not sure if this is a bug or just normal behavior. I'm running xyplorer 28.10.0500 64 bit, win11 25H2 (26200.7623), screen scaling 125%. When I press F9 to bring up the configuration menu in my xyplorer maximized window, three things happen in rapid succession, taking perhaps 1-2 seconds. First the window will resize to something about 20% smaller, it also will flash "not responding" on the title bar, and then the configuration menu appears and the main window goes back to normal. Anyone know what causes this? Thanks.

[admin]

No such problems here with the same setup.

Is this new?

[johnhoh1]

xyplorer has been this way since i got it a month or two ago. I just ran procmon to see what's happening around the f9 press, and saw so many displayfusion entries that i exited that program and tried again. Now the delay still happens but its about 1/3 of what it was. Then I re-started displayfusion and within compatibility settings selected disable application hooks for XYplorer, and the delay stays faster than before, however I lose the button that tells displayfusion to move xyplorer to the next monitor, something I use a lot, so i will not keep it unhooked for now and just live with the longer delay as its a very minor issue, was just curious. btw xyplorer shell integration is disabled (it used to be enabled though). If I get the time I'll run an WPR trace to see what comes up. I also disabled all non-MS shell extensions using shellexview but that did not impact the delay. For what its worth here is a snippet of what grok had to say... "What's Still Causing the Brief Hang/Flicker....
The core remaining pattern is the Drive\shell\FolderExtensions enumeration:

RegEnumKey on HKCR\Drive\shell\FolderExtensions → SUCCESS (lists subkeys).
Then repeated RegOpenKey / RegQueryValue / RegCloseKey on specific CLSID GUIDs like {fbeb8a05-beee-4442-804e-409dc6451e59}.
Most return NAME NOT FOUND or NO MORE ENTRIES.
Ends with DriveMask value read (SUCCESS, 255 = all drives?).
This is XYplorer (or Windows on its behalf) enumerating registered shell extensions for drives/folders (custom context menus, icons, behaviors). Failed lookups are harmless but the loop adds cumulative delay on the main UI thread → brief "not responding" + window state glitch (unmaximize flicker) when F9 dialog initializes."

[admin]

Hm, that doesn't ring a bell. By the way, do you have a valid license?

[johnhoh1]

yes i do have a paid license. When I'm not running displayfusion the delay is much quicker, but still present. In win11 settings if I set up my (vertically mounted) monitors as duplicate displays so one xyplorer instance is cloned on each monitor, hitting f9 causes the config menu to simply appear instantly like one would expect, appearing right on top of the xyplorer window. But when the monitors are set to extended mode, the sequence plays out differently depending on which monitor xyplorer is located.
If xyp is on the top monitor, hitting f9 causes a very brief appearance of the config help menu also on the top monitor before it switches and then appears on the bottom monitor. And if xyplorer is running on the bottom monitor and I hit f9, the config menu again appears briefly on the top monitor before it switches and appears on the bottom monitor. So in each case the config menu seems to try to locate itself on the top monitor but gets kicked to the bottom. Seems like its conflicted about where to locate the config help menu. I run with 125% scaling on each monitor but changing the scaling does not change the behavior, nor does changing the primary monitor.

[admin]

Okay, that's an unusual edge case that I haven't heard about yet. However, I can give the same answer that I provided in another thread: In general, XY64 has various window-related problems (size and X/Y/Z position) originating from tB. These issues will be resolved in the near future.