Why has the tray icons still existing despite process being killed bug gone unfixed for decades? Microsoft does not care or extremely sucks at quality assurance.
Why has the display control panel pointer truncation bug gone unfixed for long?
11–13 of 13 posts
Re: Why has the display control panel pointer truncation bug gone unfixed for long?
#12Earlier quoted context omitted.
Does that make it okay? There are many ways to have it learn the process dies without needing to signal the process.
Yes, let's invent some system for Explorer to query and maintain the notification area icons and for the apps to report their list of the notification icons. Some KPI pusher would be vewy-vewy glad. By the way, if the app wouldn't respond in time, what should happen with the icon? What would happen if Explorer removes the icon but the app which still thinks it has - would update it?
Re: Why has the display control panel pointer truncation bug gone unfixed for long?
#13Earlier quoted context omitted.
Yes, let's invent some system for Explorer to query and maintain the notification area icons and for the apps to report their list of the notification icons. Some KPI pusher would be vewy-vewy glad. By the way, if the app wouldn't respond in time, what should happen with the icon? What would happen if Explorer removes the icon but the app which still thinks it has - would update it?
I'm not suggesting a new system or a timeout. I'm suggesting passing a two sided handle (like a socket) where you can listen for the other end closing. Upon closing, which should only happen due to a bug or the process exiting, the notification bar can remove the icon. This is IPC 101.
What happens if your NotificationAreaAPIv2 is not widely adopted?
What happens with the apps what were never adopted to your v2 API? (You still have the problem anyway).
EDIT: And what happens with the old apps when you deprecate the old API?