Hi,

I'm using the feature that saves the windows after being idle for a period, and then I use a shortcut to restore the windows afterwards. I have a three monitor setup.

This kind of works, but randomly the window positions will be switched around - most windows on the center monitor (main) will restore to the left monitor, while one of the windows from the left monitor will be restored to the center monitor. The windows on the right monitor usually behaves.

Any advice on how I can debug this to make it work or provide information for an update? I'm running 8.1 (since I was hoping that the changes to the dock handling would fix this), but the same issue has been there since 8.0.

If I use my shortcut again, the windows will be restored back to the same position (the wrong one) as when I did it the first time.

I've attached the views from the Monitor Configuration. I've discovered that the windows on monitor 1 has moved to monitor 2, and the window on monitor 2 has moved to monitor 1 while the monitors has been asleep.

After restoring, the window now on monitor 1 (which was on monitor 2 before sleep), moves back to monitor 2, but all the windows that were moved to monitor 2 (and was originally on monitor 1), stays on monitor 2. They're minimized/restored as they were, but their location is now on the wrong monitor.

Does DF keep a more detailed log that can be helpful to determine what's actually happening behind the scenes?

Manually saving and restoring seems to work, yes.

So could it be that the idle timeout is reset after the monitors are put into sleep? (which might change the location of the mouse pointer, if any of the monitors' device disappears?)

I've never used automatic restoring, since it's only the screens that go to sleep - that's always been bound to a keyboard shortcut (and I can't bind automatic restoring without locking the desktop, iirc?).

I've noticed that the Spotify-window I keep on my left screen sometimes isn't moved back, even if it was manually saved - and is kept on the middle screen instead (and sometimes after the screens wake back up, it's put somewhere off all three screens, requiring me to minimize and open it again for it to show up again).

The current theory is that the coordinate systems change around after the monitors wake up.

Neither seems to have any effect - things worked as they should in both cases. Baffled.

Is there a debug log mode that I can configure and then examine the logs after it happens again?

The log is attached. When the screens woke up this morning, restoring windows positions did almost nothing.

But after waking up, Windows had moved the taskbar to the left screen (#2), while still having the mid screen (#1) as "make this my primary screen". To get the taskbar to move I had to set #2 as the primary screen, click apply and then set #1 as the primary screen again (this is in Windows' UI, so this isn't a DisplayFusion issue - but maybe it's a symptom of something?)

Anyways, I guess that may be the last few lines in the log file since I didn't copy the file away before I did that.

There is no trigger used - I only use a keyboard shortcut for restoring (as there is no trigger available for "waking up" - just for unlocking).

Attached is a log file where the windows that were on monitor #1 (mid) no longer restores to monitor #1, but remains on monitor #2 (left), while the contents that were on monitor #2 (left), remains on monitor #1 (mid).

I.e. wrong monitors.

Yup! Maybe there's a different application waking up the computer after a certain time, before idling and it going back to sleep again?

No, it's configured globally. I haven't used monitor profiles. Do you have any good ideas on how to debug this further?

The event doesn't seem to be triggered - at least not in any meaningful way. Same result as earlier. Log is attached.

That seems to work better, but there's still been at least one time where it confused monitor 1 and monitor 2 and restored the windows to the wrong monitor (and since the monitors have different resolutions, that fubared the windows sizes).

Using restore on monitor profile change did however cause an endless loop with a game (Overwatch) trying to go fullscreen (probably because of a refresh rate / resolution change), where DF would try to restore window positions, which would exit fullscreen, but windows would fullscreen it again, retriggering the restore window positions .. and so it went on until I killed OW and disabled the monitor profile change trigger.

Thanks! Please keep me posted about any further updates on this functionality and I'll be glad to test it out.