timurborn

They may be hidden, but still accessible. You can try to activate one via Taskbar and then press ALT-Space to enter their system menu. If they are not marked as maximized by the system then you can press M (move) and then press any cursor key once. After that the window will appear at your mouse-cursor position and move with the mouse-cursor until you press ENTER. Have a look at all the keyboard shortcuts in the system menu and try different things. Of course that's no solutio

I got an offer for Fences 6 rebate today, but don't see the appeal paying for 6 while 3 is still working and the main issue (high CPU load for desktop/fences mouseover) isn't solved by 6. Good luck, though.

For on/off movement on Fences CPU load spikes shortly the very moment the mouse moves on to a Fence of off a Fence. This could either be from empty desktop to Fence, or from Fence to Fence. In order to produce the pseudo-constant high load I demonstrate in the screenshot you have to keep moving the mouse-pointer on/off the Fences, aka move the mouse in circles. For movement over the empty desktop the load happens for as long as you move the mouse and then drops back down. On t

Completely different PC, different CPU, chipset, GPU, software and Windows 10 instead of 11. Moving mouse on/off Fences: Moving mouse over empty desktop:

I am back to v1 for the time being.

W11 Coming from Groupy v1, just upgraded to Groupy v2. Several things I noticed: 1. CPU load of GroupyCtrl increases whenever the mouse is moved, even more so when the mouse uses a higher polling rate (kike 1 kHz). This also happens when the "hover over title bar" option is disabled and no Groupy group is currently on-screen. Mouse moving: <img src="h

That's the official stance for declaring it EOL, yes. It always worked and works under Windows 11, having the same quirks as it had on W10. The only problem is the Explorer.exe overload (that was fixed at some point and then likely unfixed with a later Windows update). But this also happens with version 6 (as discussed in the respective thread).

The CPU never gets to 100% neither inside nor outside the sandbox. Instead it runs 1 thread/core (out of 32) up to 100% plus some extra load. 100/32 = 3.125% = 1 core fully loaded (at 100% for that one core) Keep in mind that this load is shared between two virtual cores as Windows keeps shifting the thread back and forth. *Inside* Sandbox, moving mouse on/off Fence area: <img src="https://cdn.stardock.us/forums/67/10/6710664/a920f69d-6b73-467f-ab1f-69684c62039

In the sandbox it doesn't happen from mouse-pointer movement over the empty desktop, but it happens from moving the mouse on and off from a fence.

Hello Basj, thanks for the quick reply. I followed the Purge instructions and installed the latest Fences 6 trial downloaded today. Same result when moving the mouse-pointer over the (empty) desktop! Fences enabled: Fences disabled:

I just tried Fences 6 and it produces the same high (1 CPU core fully loaded) Explorer.exe workload for mouse movement over the empty desktop that Fences 3 did for some time now.

Some late feedback: Fences 3.13, 3.16 and 3.17 still cause full Explorer.exe load here when the mouse-pointer is moved over the empty desktop. In the past 3.13 did not do that here, so either something about Explorer has changed or Fences retains some broken settings even when being uninstalled with the option to remove settings.

Thanks for the quick answer. I already used the registry key, but it seems like I kept it at 0 instead of 1. So let's wait a few days to see how it works now. [e classic]:congrat:[/e]

Hello. Trying to deactivate the update notification didn't work. So either I would really like to know if the Explorer CPU load bug will be fixed or how to disable the notification!? Thanks and regards.

Are there any plans to fix the high Explorer load introduced by the latest version? I can live with staying on an older version, but it would be nice to know whether disabling update notifications is in order!?

Since v3.1.6 causes high Explorer.exe load I returned to 3.1.3 via Steam's "Beta" opt-in. The Explorer load does not happen with Fences 3.1.6 disabled, but there is another noteworthy *temporary* workaround. Right-click on the empty desktop to open the context-menu. This will stop the high Explorer load for some time, but it will eventually come back.

It's been over 20 days since the autogrouping problems with v1.44 were first reported. Are there any updates yet?

https://forums.stardock.com/502031/get;3791559 https://forums.stardock.com/502031/get;3791599

Are fixes for auto-grouping in the making? Still staying on v1.43 here.

I will stay with v1.43 until this is fixed. Much less of a hassle compared to the workaround. But thanks for the suggestion.

[quote who="sdRohan" reply="18" id="3791568"]You have to close the Groupy UI and reopen for that to refresh.[/quote] Did not make a difference as far as I remember. v1.44 did not populate this list when I try to add PDFXEdit.exe. And even if it is still populated from a previous v1.43 installation or by manually editing the Registry it still did not group the windows automatically. v1.43 populates the list as expected (Groupy UI needs to be reopened to see the change) and also

Downgraded to v1.43 via Steam installation, automatic grouping works again. I will just keep away from the update until this is fixed. Thanks and regards.