Win11: reserve space in the system tray for the taskbar window

[mackid1993]

Reserving taskbar space so icons stop covering the readout

The problem

I run TrafficMonitor docked in the Windows 11 taskbar and my taskbar is usually full.
Once it fills up, the task buttons expand all the way over to the notification area and
end up sitting underneath the readout. You can't read the numbers and you can't click
the buttons that are stuck under it.

There are already offset options in the settings, but those are a fixed number of pixels
you have to keep retuning by hand, and they don't help at all once the bar is actually
full. The buttons just take the space anyway.

What I tried first, and why it didn't work

My first idea was placeholder task buttons. Register hidden windows with their own
AppUserModelIDs so Windows draws blank buttons where I want the readout to go. That does not
work. As soon as the taskbar is full Windows takes the newest buttons and demotes them into
the overflow flyout. I created four and got zero visible buttons and zero space back.

Second idea was shrinking the XAML island the taskbar draws itself into. That reserved the
space, but it dragged the whole notification area left along with it, so the clock and all
the tray icons moved too. That was worse than what I started with.

What actually works

The Windows 11 taskbar is a two column layout. The task button strip is one column, the
notification area is the other, and the right edge of the strip is the left edge of the
tray. If you make the tray wider, the strip repacks itself to stay clear of it. It never
pushes into the tray. That's the whole trick.

So instead of fighting the button strip, I add a few completely transparent placeholder
icons to the notification area with Shell_NotifyIcon. The tray gets wider, the buttons
move over on their own, and the readout sits in the gap that opens up. Nothing overlaps,
because Windows is doing the layout itself. I'm not overriding anything.

To find out where those placeholders actually landed I use UI Automation on a background
thread. It has to be a background thread, because those cross process calls pump the
message queue and would reenter the UI thread if you did it inline. A WinEvent hook wakes
that thread when the taskbar layout changes, so the window follows along right away.

How much space it reserves comes from the window's own measured width, so it scales with
however many items you have configured. It isn't hardcoded for four.

The part I got wrong twice, and what it taught me

New tray icons don't show up in the tray. Windows files them into the overflow flyout, where
they take up no width at all and reserve nothing. To be useful, each placeholder has to be
marked always visible. That's the same value behind Settings, Personalization, Taskbar,
"Other system tray icons", so it isn't a private hack, but it does mean this feature writes
to the registry. I tried hard to avoid that and it simply cannot be done.

The subtler part took me most of a night to understand. Explorer keeps its tray settings in
memory and treats the registry as a write back copy. If you delete one of those keys from
outside Explorer, the two go out of sync: Explorer still recognizes the icon's identity but
never writes its key again, so that placeholder can never be shown, ever, until Explorer
restarts. My first version deleted its keys on exit to be tidy, which meant run one worked,
exit wiped the keys, and run two was dead on arrival. It looked like a random intermittent
bug for hours.

So now the keys are deliberately left alone. They're a fixed set reused every run, so they
can't pile up. They're only removed when you actually switch the feature off, and if you
switch it back on it rotates to a fresh block of GUIDs, because the batch you just purged is
poisoned by that same desync.

The other things that took real time

Tray icons can be dragged around by the user. If you drop one of your icons into the middle
of my placeholder block, the readout would sit right on top of it. So the query looks at
every button in the taskbar, not just my own, and if anything foreign ends up inside the
reserved region the readout hides until you move it away. An overlap has to survive two
samples before it counts, because opening the overflow chevron makes the tray shuffle for a
frame and that was enough to make the window blink.

The taskbar's own right click menu makes UI Automation report an empty taskbar. Not a smaller
one, an empty one. Treating that literally meant the readout vanished whenever you right
clicked the taskbar. A completely empty result is now treated as a blackout and the previous
one is kept.

On startup the window stays hidden for the second or two the region takes to build, instead
of appearing at its normal spot and then jumping. And there's a deadline, so if the region
never comes together it falls back to ordinary placement rather than hiding forever or
parking itself on top of the task buttons.

What it deliberately doesn't do

No injecting anything into Explorer. No Windhawk style hooks into the shell. It's
Shell_NotifyIcon, UI Automation, one registry value that a Settings toggle already writes,
and an out of context WinEvent hook.

Vertical taskbars aren't supported. That tray is a grid several icons wide, so making it
wider frees up no horizontal space at all and the placeholders accomplish nothing. The
checkbox greys out when your taskbar is on the left or right edge, and it says why.

What I'd want a reviewer to push on

While the feature is on, the placeholders show up as entries in that Settings tray icon list.
That's unavoidable: each reserved slot is a real tray icon and Windows lists every tray icon.
If someone toggles one of them off, the reservation quietly gets smaller.

There's no timeout on shutdown when it waits for the UI Automation thread, so a wedged
Explorer could stall the app on exit.

Two copies installed in different folders would fight over the same placeholder identities.

And the honest one: the app can't tell when it's reserving nothing. If the shell stops
persisting those keys for a reason I haven't seen, it will add icons, report success, and
silently do nothing. The GUID rotation covers the case I actually hit, but that's a class of
problem rather than a single bug.

Why I think it's worth having

It's off by default, so nobody gets surprised by it. If you turn it on, the placeholders are
invisible, and they're removed again when you turn it off.

For anyone who keeps a full taskbar, this is the difference between the readout being usable
and being buried. It fixes it the way the shell already wants to lay things out rather than
fighting it, which is why it holds up when the taskbar changes size, when icons come and go,
and across an Explorer restart.

It has been tested on one machine. It should go in as opt in and be treated as beta until
other people have run it.

[mackid1993]

I also built binaries for testing: https://github.com/mackid1993/TrafficMonitor/releases/tag/v1.86-reserve-taskbar-space

[wiggins-kong]

Thank you so much! You’ve resolved the issue that has been troubling me for years.

[mackid1993]

I'm glad this helped someone. That made my day!

Hopefully the maintainer will consider merging this one day! It's a nice little workaround for Windows 11.

[mackid1993]

Fixed an issue with dpi changes such as when docking a laptop