Hello,

I have been running DisplayFusion for many years now, and it is still one of the first
things I install on any new machine. It has quietly solved multi-monitor problems for me
across more versions of Windows than I can count, and it remains one of my favorite pieces
of software. I am sending this one in because I would like it to stay that good, not
because I am unhappy with it.

I have a reproducible issue on DisplayFusion 12.1.1.0 (Windows 11 24H2, build 26100) where
applications that cache monitor work areas at startup end up with stale values on the
monitors that have DisplayFusion taskbars.

Setup: three monitors, all at 100% scaling. Windows taskbar on the primary, moved to the
top by Start11. DisplayFusion taskbars on the two secondary monitors, also at the top,
48px tall. "Show taskbar on all displays" is off in Windows, so DisplayFusion supplies both
secondary taskbars.

DisplayFusion reserves the work area correctly. GetMonitorInfo reports rcWork.top = 48 on
all three monitors. The problem is timing plus notification. DisplayFusion.exe launches
from the HKCU Run key and starts roughly 28 seconds after Explorer on my machine. Anything
that reads work areas before that point gets the full monitor rect and is apparently never
told to re-read.

In my case that is PowerToys FancyZones 0.100.2, which starts about 24 seconds before
DisplayFusion and snapshots work areas at startup. Its zone grid on both DisplayFusion
monitors ends up anchored 48px too high, so any window snapped to a top zone lands
underneath the taskbar until it is manually resized.

Measured live, with FancyZones still running:
Monitor OS work area (GetMonitorInfo) FancyZones cached
DISPLAY1 (0,4-(3840,2160) (0,4-(3840,2160) correct, no DF taskbar
DISPLAY2 (-1080,4-(0,1920) (-1080,0)-(0,1920) 48px too high
DISPLAY3 (3840,4-(7680,2160) (3840,0)-(7680,2160) 48px too high
I read the FancyZones column by calling GetWindowRect on its FancyZones_ZonesOverlay
windows, since it sizes one per work area, so those rects are effectively its cache. That
should let you reproduce the measurement without taking my word for it.

FancyZones logged no work-area or display-change event at any point after its startup
snapshot, even though DisplayFusion applied the reservation about 22 seconds later.
Broadcasting WM_SETTINGCHANGE with wParam = SPI_SETWORKAREA to HWND_BROADCAST fixes it
immediately. FancyZones logs "WorkArea size changed" and rebuilds all three work areas
correctly. A genuine display change (resolution change, or monitor sleep and wake) also
fixes it, which is consistent with the reservation itself being right and only the
notification being absent.

This does not look specific to FancyZones. Any application that reads work areas once at
startup would be affected the same way, and DisplayFusion's launch timing makes that a
fairly likely race. I realize suppressing the broadcast may well be deliberate, since
firing it during startup could cause other apps to rearrange windows, so I understand if
the timing is more delicate than it looks from the outside.

Would it be possible for DisplayFusion to broadcast WM_SETTINGCHANGE with SPI_SETWORKAREA
(or call SystemParametersInfo with SPIF_SENDCHANGE) once it has finished applying its
taskbar work area reservations?

Happy to test a build or gather more detail if that would help.

Thanks for building something this good and for keeping it that way as long as you have.