<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:media="http://search.yahoo.com/mrss/">
<channel>
<title>DisplayFusion RSS: DisplayFusion taskbars change the monitor work area without notifying other apps</title>
<atom:link href="https://www.displayfusion.com/Discussions/RSS/?TopicID=01a02ac5-ad3c-701a-8629-a7084d487f51" rel="self" type="application/rss+xml" />
<link>https://www.displayfusion.com/Discussions/RSS/?TopicID=01a02ac5-ad3c-701a-8629-a7084d487f51</link>
<description>DisplayFusion RSS: DisplayFusion taskbars change the monitor work area without notifying other apps</description>
<lastBuildDate>Sun, 23 Aug 2026 06:24:17 GMT</lastBuildDate>
<language>en</language>
<sy:updatePeriod>hourly</sy:updatePeriod>
<sy:updateFrequency>1</sy:updateFrequency>
<generator>https://www.displayfusion.com/Discussions/RSS/?TopicID=01a02ac5-ad3c-701a-8629-a7084d487f51</generator>
<item>
<title>DisplayFusion taskbars change the monitor work area without notifying other apps</title>
<link>https://www.displayfusion.com/Discussions/View/displayfusion-taskbars-change-the-monitor-work-area-without-notifying-other-apps/?ID=01a02ac5-ad3c-701a-8629-a7084d487f51</link>
<pubDate>Sat, 22 Aug 2026 18:39:53 GMT</pubDate>
<dc:creator>Binary Fortress Software</dc:creator>
<guid isPermaLink="false">https://www.displayfusion.com/Discussions/View/displayfusion-taskbars-change-the-monitor-work-area-without-notifying-other-apps/?ID=01a02ac5-ad3c-701a-8629-a7084d487f51</guid>
<category>DisplayFusion</category>
<description><![CDATA[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 s...]]></description>
<content:encoded><![CDATA[<div class="CTDiscussions">
Hello,<br/>
<br/>
I have been running DisplayFusion for many years now, and it is still one of the first<br/>
things I install on any new machine. It has quietly solved multi-monitor problems for me<br/>
across more versions of Windows than I can count, and it remains one of my favorite pieces<br/>
of software. I am sending this one in because I would like it to stay that good, not<br/>
because I am unhappy with it.<br/>
<br/>
I have a reproducible issue on DisplayFusion 12.1.1.0 (Windows 11 24H2, build 26100) where<br/>
applications that cache monitor work areas at startup end up with stale values on the<br/>
monitors that have DisplayFusion taskbars.<br/>
<br/>
Setup: three monitors, all at 100% scaling. Windows taskbar on the primary, moved to the<br/>
top by Start11. DisplayFusion taskbars on the two secondary monitors, also at the top,<br/>
48px tall. "Show taskbar on all displays" is off in Windows, so DisplayFusion supplies both<br/>
secondary taskbars.<br/>
<br/>
DisplayFusion reserves the work area correctly. GetMonitorInfo reports rcWork.top = 48 on<br/>
all three monitors. The problem is timing plus notification. DisplayFusion.exe launches<br/>
from the HKCU Run key and starts roughly 28 seconds after Explorer on my machine. Anything<br/>
that reads work areas before that point gets the full monitor rect and is apparently never<br/>
told to re-read.<br/>
<br/>
In my case that is PowerToys FancyZones 0.100.2, which starts about 24 seconds before<br/>
DisplayFusion and snapshots work areas at startup. Its zone grid on both DisplayFusion<br/>
monitors ends up anchored 48px too high, so any window snapped to a top zone lands<br/>
underneath the taskbar until it is manually resized.<br/>
<br/>
Measured live, with FancyZones still running:<br/>
  Monitor    OS work area (GetMonitorInfo)   FancyZones cached<br/>
  DISPLAY1   (0,4<img src="https://www.displayfusion.com/MediaCommon/SVGs/FontAwesome/face-grin-stars.light.svg" alt="8)" style="box-sizing:border-box;position:relative;overflow:hidden;vertical-align:middle !important;width:16px;height:16px;" HelpButtonData="8)" />-(3840,2160)              (0,4<img src="https://www.displayfusion.com/MediaCommon/SVGs/FontAwesome/face-grin-stars.light.svg" alt="8)" style="box-sizing:border-box;position:relative;overflow:hidden;vertical-align:middle !important;width:16px;height:16px;" HelpButtonData="8)" />-(3840,2160)      correct, no DF taskbar<br/>
  DISPLAY2   (-1080,4<img src="https://www.displayfusion.com/MediaCommon/SVGs/FontAwesome/face-grin-stars.light.svg" alt="8)" style="box-sizing:border-box;position:relative;overflow:hidden;vertical-align:middle !important;width:16px;height:16px;" HelpButtonData="8)" />-(0,1920)             (-1080,0)-(0,1920)      48px too high<br/>
  DISPLAY3   (3840,4<img src="https://www.displayfusion.com/MediaCommon/SVGs/FontAwesome/face-grin-stars.light.svg" alt="8)" style="box-sizing:border-box;position:relative;overflow:hidden;vertical-align:middle !important;width:16px;height:16px;" HelpButtonData="8)" />-(7680,2160)           (3840,0)-(7680,2160)    48px too high<br/>
I read the FancyZones column by calling GetWindowRect on its FancyZones_ZonesOverlay<br/>
windows, since it sizes one per work area, so those rects are effectively its cache. That<br/>
should let you reproduce the measurement without taking my word for it.<br/>
<br/>
FancyZones logged no work-area or display-change event at any point after its startup<br/>
snapshot, even though DisplayFusion applied the reservation about 22 seconds later.<br/>
Broadcasting WM_SETTINGCHANGE with wParam = SPI_SETWORKAREA to HWND_BROADCAST fixes it<br/>
immediately. FancyZones logs "WorkArea size changed" and rebuilds all three work areas<br/>
correctly. A genuine display change (resolution change, or monitor sleep and wake) also<br/>
fixes it, which is consistent with the reservation itself being right and only the<br/>
notification being absent.<br/>
<br/>
This does not look specific to FancyZones. Any application that reads work areas once at<br/>
startup would be affected the same way, and DisplayFusion's launch timing makes that a<br/>
fairly likely race. I realize suppressing the broadcast may well be deliberate, since<br/>
firing it during startup could cause other apps to rearrange windows, so I understand if<br/>
the timing is more delicate than it looks from the outside.<br/>
<br/>
Would it be possible for DisplayFusion to broadcast WM_SETTINGCHANGE with SPI_SETWORKAREA<br/>
(or call SystemParametersInfo with SPIF_SENDCHANGE) once it has finished applying its<br/>
taskbar work area reservations?<br/>
<br/>
Happy to test a build or gather more detail if that would help. <br/>
<br/>
Thanks for building something this good and for keeping it that way as long as you have.
</div>
]]></content:encoded>
<media:thumbnail url="https://www.displayfusion.com/Discussions/Download/?ID=01a02ac5-bcb0-708c-9887-e86a9d6d59c4"/>
</item>
</channel>
</rss>