Problem
In Lite, clicking Dismiss, Snooze 15m, Snooze 1h, or Snooze 4h on an alert toast (SnoozeBalloon) appears to do nothing — the popup stays on screen. Users report having to click Dismiss dozens of times for a single alert.
Root cause
SnoozeBalloon.CloseBalloon() was raising Hardcodet's TaskbarIcon.BalloonClosingEvent and assuming the library would tear the popup down in response. It does not.
In Hardcodet.NotifyIcon.Wpf 2.0.1, BalloonClosingEvent is a notification the library emits when it closes a popup (from TaskbarIcon.CloseBalloon(), which is called internally on ShowCustomBalloon replacement and on timeout). There is no class handler that converts a balloon-initiated raise of that event back into a CloseBalloon() call.
// from Hardcodet TaskbarIcon.CloseBalloon():
RoutedEventArgs eventArgs = RaiseBalloonClosingEvent(element, this);
if (!eventArgs.Handled)
{
popup.IsOpen = false; // <-- only happens when LIBRARY closes
RaiseBalloonClosedEvent(...);
...
}
So:
- Library-initiated close (timeout or replacement-on-new-show) → popup closes ✓
- User-initiated close (dismiss/snooze button) → routed event bubbles into the void, popup persists ✗
_closed = true in SnoozeBalloon silenced subsequent click handlers, so the popup couldn't even be re-dismissed — it just sat there until the next refresh tick replaced it with a fresh alert.
Fix
SnoozeBalloon now receives an Action closePopup callback at construction. SystemTrayService.ShowSnoozableNotification supplies () => _trayIcon.CloseBalloon(). The dismiss/snooze handlers invoke it directly instead of raising the routed event.
How it was diagnosed
Added per-instance lifecycle logging (SHOW/LOADED/USER_DISMISS/RAISE_CLOSE/CLOSING_EVT/CLOSED_EVT/UNLOADED) and reproduced via HammerDB load. Log showed CLOSING_EVT #2 firing on each dismiss click but never CLOSED_EVT #2 and never UNLOADED #2, confirming the library wasn't closing the popup.
Problem
In Lite, clicking Dismiss, Snooze 15m, Snooze 1h, or Snooze 4h on an alert toast (
SnoozeBalloon) appears to do nothing — the popup stays on screen. Users report having to click Dismiss dozens of times for a single alert.Root cause
SnoozeBalloon.CloseBalloon()was raising Hardcodet'sTaskbarIcon.BalloonClosingEventand assuming the library would tear the popup down in response. It does not.In
Hardcodet.NotifyIcon.Wpf2.0.1,BalloonClosingEventis a notification the library emits when it closes a popup (fromTaskbarIcon.CloseBalloon(), which is called internally onShowCustomBalloonreplacement and on timeout). There is no class handler that converts a balloon-initiated raise of that event back into aCloseBalloon()call.So:
_closed = trueinSnoozeBalloonsilenced subsequent click handlers, so the popup couldn't even be re-dismissed — it just sat there until the next refresh tick replaced it with a fresh alert.Fix
SnoozeBalloonnow receives anAction closePopupcallback at construction.SystemTrayService.ShowSnoozableNotificationsupplies() => _trayIcon.CloseBalloon(). The dismiss/snooze handlers invoke it directly instead of raising the routed event.How it was diagnosed
Added per-instance lifecycle logging (
SHOW/LOADED/USER_DISMISS/RAISE_CLOSE/CLOSING_EVT/CLOSED_EVT/UNLOADED) and reproduced via HammerDB load. Log showedCLOSING_EVT #2firing on each dismiss click but neverCLOSED_EVT #2and neverUNLOADED #2, confirming the library wasn't closing the popup.