11

Whenever my windows forms application runs for the first time, the tray icon stays visible for about less than a minute, and then it autohides, what can i do to make it stick and not auto hide ?

I tried searching and can't find any useful information.

It appears that this is the default behavior for windows 7 and above, I wonder if there is a way to override that behavior from inside my application ?

sharp12345
  • 4,420
  • 3
  • 22
  • 38
  • 1
    No, there is no way to do that programatically. You can click "Customize" on the system tray and change it to always show, manually. – Blorgbeard Mar 01 '13 at 01:29
  • @Blorgbeard actually there must be. The details of which application icons to hide/show/display notifications for are stored **somewhere**, most likely the registry. I suspect the solution will require either direct access to the registry or a win32 api call – DiskJunky Mar 01 '13 at 01:30
  • 1
    @DiskJunky that's true, but I hope OP doesn't find out how :P – Blorgbeard Mar 01 '13 at 01:32
  • Any application overriding my personal choice of what icons are hidden/shown/displayed would get immediately uninstalled by me. – dtb Mar 01 '13 at 01:32
  • @dtb agreed but no reason not to set a default... – DiskJunky Mar 01 '13 at 01:33
  • @DiskJunky: The default is auto-hide after less than a minute. This lets me see that there is an icon, and if I want to see it I can bring it back easily. – dtb Mar 01 '13 at 01:35
  • @dtb , I plan to ask the user whether he want to keep it visible or not, I do not plan to annoy the user. – sharp12345 Mar 01 '13 at 01:38
  • @dtb again, agreed. My point is simply that this is *technically* possible if enough effort is applied. It becomes a question of feasability, not impossibility – DiskJunky Mar 01 '13 at 01:38
  • @sharp12345 that sounds pretty annoying to me. – Blorgbeard Mar 01 '13 at 01:40
  • @sharp12345: Don't call the user, let the user call you. That is, don't annoy the user with a non-standard way to configure your special snowflake. The user can express his preference for the visibility of your icon using the standard customization feature provided by Windows. – dtb Mar 01 '13 at 01:41
  • @dtb I am assuming that I am dealing with users that do not even know how to bring an icon from the system tray, -- never the less, I do agree to some level with what you and 'DiskJunky' are saying. – sharp12345 Mar 01 '13 at 01:45
  • 2
    Make sure you also tell your users, "This program is using an unsupported way of showing the icon, so it may stop working at any time (even a security hotfix may break it). Do not complain to Microsoft when this happens. Complain to Sharp12345." – Raymond Chen Mar 01 '13 at 01:49
  • Heh, @Raymond. I was searching through The Old New Thing trying to find backing evidence for my answer - I was sure I'd seen it at some point. MSDN will do, though. – Michael Petrotta Mar 01 '13 at 01:55
  • @RaymondChen in practice you probably have a few windows versions to go before you have to worry about it. Win32 api changes happen but not all that frequently and drastically. Exceptions abound but...a lot of apis are pretty much what they were in w95 – DiskJunky Mar 01 '13 at 01:58
  • 2
    @DiskJunky The documented APIs have remained stable, but the undocumented parts change constantly. In particular, the internal data structures that keep track of hidden notification icons change pretty much at every release of Windows. – Raymond Chen Mar 01 '13 at 05:14
  • @RaymondChen noted and good to know – DiskJunky Mar 01 '13 at 09:49
  • 1
    I do not see the way letting the user set an "icon stays on the tray" option in the software's setup window/tab annoying, if it: Is performed trough a documented and supported API-call. / Is not asked in popup widows/balloon help boxes/during the installation with a nonstandard default value. / Can be disabled as easily as enabling it. - Has no effect over other tray icons. - Gets disabled on software uninstall. Any other means of doing it are unacceptable in my opinion too. – mg30rg Aug 02 '13 at 11:59

2 Answers2

7

There is no supported programmatic way to override the system's default show/hide notification icon behavior. MSDN:

When an icon is added to the notification area on Windows 7, it is added to the overflow section of the notification area by default. This area contains notification area icons that are active, but not visible in the notification area. Only the user can promote an icon from the overflow to the notification area, although in certain circumstances the system can temporarily promote an icon into the notification area as a short preview (under one minute).

Emphasis mine.

Michael Petrotta
  • 59,888
  • 27
  • 145
  • 179
  • despite the documentation, I disagree with this. The settings have to be stored somewhere, regardless of how easy it is to update/read these settings. I find it extremely unlikely MS has gone to great lengths to encrypt or otherwise lock down such relatively trivial settings. It's possible that there's no api call but it doesn't mean that it's "impossible", just difficult – DiskJunky Mar 01 '13 at 01:36
  • 3
    Oh, no question, @DiskJunky. I'm just saying it's not *supported*. Given that, if your software finds and exploits the setting, it'll break if and when Microsoft moves things around. Which, since Win8, they've shown a greater willingness to do. – Michael Petrotta Mar 01 '13 at 01:38
  • 1
    @Michael , WRONG. You still can do it, Ive done it. The only way it would break is if Microsoft MOVED their actual reg keys and structure, this wont happen. And BTW Windows 8 the solution I offered works great there as it did in 7 and Vista :) – Trevor Mar 01 '13 at 03:47
  • @MrCoDeXeR, there's no supported programmatic way, as I said. Are you so sure about what Microsoft will and won't do? – Michael Petrotta Mar 01 '13 at 05:56
  • No, but this hasn't CHANGED IN YEARS. Do you think they will anytime soon. And here's what you said above... "Given that, if your software finds and exploits the setting, it'll break if and when Microsoft moves things around. Which, since Win8, they've shown a greater willingness to do". My way hasn't broke yet even in Windows 8 because they dont change this and I strongly believe they never will because it will require architectural changes, big changes... – Trevor Mar 01 '13 at 06:07
  • 1
    @MrCoDeXeR: maybe, maybe not. I think you're misinterpreting my answer. I'm saying that there's no *supported* way to do this. You're saying there's an *unsupported* way. There are costs associated with unsupported paths. If the OP, and future users, are ok with this, great. By the way, a Microsoft employee, a highly-connected one, has commented on this post, above. It's worthwhile listening to his take on this. – Michael Petrotta Mar 01 '13 at 06:10
  • 1
    (and yes, Microsoft has changed many *documented* areas of their operating system. To my personal pain. Undocumented areas? Better betcha they'll change) – Michael Petrotta Mar 01 '13 at 06:13
  • I've read it, who doesn't put those in their agreements? :/ The registry is old and has been the same for years... – Trevor Mar 01 '13 at 06:15
  • Also I agree with many not saying I don't, but I was saying it CAN be done. If they choose to do it, then thats on them. I dont recommend these to anyone, but it's their choice to make these changes... – Trevor Mar 01 '13 at 06:18
  • @Çöđěxěŕ - Can you show the actual way in which this can be achieved? – Gabriel Feb 14 '20 at 15:34
2

As you've no doubt read the discussion in the comments, there is indeed no supported way of doing this. That said, if you're determined and you have the time to do a little digging, I'd recommend using a few tools to bypass the documentation and looking at what's actually happening under the hood with the notification setting. There may be appropriate documentation on this but I've not found it.

The brute force approach would be to use SysInternal's RegMon tool to view all registry access . If you tie it to the "Explorer.exe" process, you will see all relevant information on what the desktop and start bar are doing, including any file access. Make no mistake - this is a brute force approach and will require a lot of effort and digging. Once tied to the explorer.exe process you can make changes to the notificaiton settings. Viewing and investigating the changes made by the process will give you an idea of where the relevant settings are stored and how. The downside is that there's going to be a lot of data to trawl through and investigate to find out what's going on but it can be done. This is not an ideal solution but if no other is forthcoming you're left with the rough and ready approach I'm afraid. It comes down to how much effort you want to put into a solution to this.

DiskJunky
  • 4,750
  • 3
  • 37
  • 66
  • @MichaelPetrotta agreed. Completely. But it's not that bad - I've done it when needed. Mainly back in the days before SO but still :-) There's very little that actually **can't** be done. SO is a little too tied to documentation at times on what's "possible" – DiskJunky Mar 01 '13 at 02:03
  • 1
    I deleted my comment above as unnecessary, but since DiskJunky replied to it, I'll add it back: "If the OP really needs this feature, this is a reasonable path, but RegMon against explorer.exe without good filters - like drinking from a firehose." – Michael Petrotta Mar 01 '13 at 02:05