Hide the native Windows 11 Start button custom Start button is enabled

[ge0rdi]

This is replacement of #2547 PR by @YellowNest who did great job with introducing TAP into Open-Shell and made all this possible. Big thanks for that!

---

Windows 11 renders the Start button through XAML, so the older HWND-based hiding logic cannot remove the native glyph. This caused custom Open-Shell buttons to be drawn on top of the Windows Start icon.

The change uses the Windows XAML diagnostics TAP to:

• collapse the native Start glyph
• disable hit testing on the underlying native Start control
• preserve the native control's layout slot
• restore the original XAML properties when replacement is disabled or Open-Shell exits
• respect the All taskbars setting

The replacement button itself is not moved or resized by this code, so Windows remains responsible for centered taskbar layout.

TAP mechanism usage was inspired by TranslucentTB and UWPSpy projects.

Fixes #1631

[YellowNest]

I reviewed the replacement implementation. The simplified structure looks much better.

I noticed one state transition worth correcting in OnVisualTreeChange: when an Icon element is recreated under an existing Start control, glyph is updated but visibilityOverride retains the state of the previous glyph.

If that flag is already true, ApplyState skips setting Visibility on the new glyph.

A one-line reset when assigning the new glyph appears sufficient:

YellowNest@bc0721d

This is based on code-path analysis, not yet a reproduced Windows 11 UI failure.

[ge0rdi]

@YellowNest
Thanks for the review and good catch. Applied your fix.

Do you know by any means how to force Windows to re-create the start button/glyph?
As so far I haven't figured that out. No matter what I do in taskbar settings (behavior, orientation, small icons, etc) it seems the button/glyph stays there. It is never removed and then added again.

I'm also testing with multiple monitors (well, two) and here it works nicely - with one monitor active there is one button announced, then when I turn on the other monitor new button/glyph is added. So the code handles it nicely.

Also I was curious whether Add could be called on existing element. It doesn't make much sense logically and current code doesn't count with that. But your original code handled that situation. So I was curious if you have ever observed such thing.

[YellowNest]

I ran an instrumented Windows 11 x64 test against 10877cb to investigate the XAML Add/Remove behavior.

Results:

• 16/16 Explorer lifecycle tests passed.
• 15 successful XAML TAP connections.
• 15 ControlAdd and 15 GlyphAdd notifications.
• No duplicate Add notifications within the same TAP instance.
• No GlyphRemove notifications or glyph replacements observed.
• The same control and glyph handles were reported across all 15 connections.
• No Explorer crashes or crash dumps.

The results are consistent with AdviseVisualTreeChange replaying existing elements for each new subscription. I found no evidence that a live element receives duplicate Add notifications within the same subscription.

I also haven't found a reliable way to force recreation of the glyph under an existing Start control.

The helper DLL was absent from Explorer's loaded module list after shutdown, including observations up to 180 seconds later.

Test run:
https://github.com/YellowNest/Open-Shell-Menu/actions/runs/39051986949

Based on these observations, I don't see a reason to add more defensive handling to the current implementation.