How do I programmatically control the order of my program’s notification icons?

A customer had a program that created multiple taskbar notification icons, and they wanted to know if there was a way to control the order in which they appeared.

Nope, that's not something you can control. You can create multiple icons, but the system chooses where they go. They might go into the visible portion of the notification area. They might go into the overflow. The user can use the control panel to move your icon between the two places, or the system could decide automatically. The user can also drag the icon directly from the notification area into the overflow, or vice versa. The user can even drag the icon within the notification area to customize the order.

The customer responded that they figured out how to do it. They performed a Find­Window for the control that renders the notification area and sent it private messages to reorder the icons.

These customers make the application compatibility team sad.

Comments (35)
  1. pc says:

    But on the plus side, the developer probably got a nice bonus for that feature!


  2. Users can reorder the icons.But I wonder why the order of icons was so important to them.

    1. Damien says:

      To which the obvious solution is to run a timer and correct the user’s mistake every 250ms.

      1. Let me parapharse: The use can reorder the icons not just by dragging and dropping the icons themselves but also by changing the taskbar’s position and resizing it. If the resist all this, they risk losing market share.

    2. Stéphan Leclercq says:

      Maybe the icons represent steps in a multi-stage process (status of the input bin, status of the high-speed-frobbing engine, status of the output bin) and it would make sense to have them displayed in that order…

    3. Vilx- says:

      I can think of several scenarios where the order could be important. For example, it could be a music player that adds prev/next/play/pause buttons to the taskbar (there’s a pretty standard order to these). Maybe they tried to make one “mega-button” by adding several matching images together. Maybe the application could control the speed of something (“1”, “2”, “3”). Maybe they tried to show the progress of some process there with multiple icons (Stage 1 status, Stage 2 status, Stage 3 status). Etc. In all of these cases, I suppose you could ignore the order, but it would be weird from UI/UX perspective.

      1. Scott H. says:

        I remember a music player that did just this in the Win9x days. I believe it kept its order by occasionally removing and re-adding the control buttons. This wasn’t perfect as things could happen but in general Win9x seemed to keep them approximately in the order they were created. User rearrangement wasn’t typically a thing although IIRC there were a couple third party apps that could do it.

      2. Tim! says:

        @Vilx- of course the real solution in all those scenarios is either “combine the icons into one, with details in a menu as necessary” or “don’t use the notification area for this feature”.

      3. mikeb says:

        I’m probably the last person that should be giving UI advice, but it seems to me that it would be weird from a UI/UX perspective to use notification icons as prev/next/play/pause buttons.

        On the other hand, showing what stage is active (or completed?) seems to make sense for a notification icon, but I’d think you’d only have to show one of those icons at a time – why is a “stage 1” icon still showing when “stage 3” is underway?

      4. TwelveBaud says:

        That’s a job for TaskbarItemInfo.ThumbButtonInfos. And if that’s not available to you for some reason, the Windows API Code Pack (never supported, no longer offered by MS, but still best in breed) has you covered.

    4. Torkell says:

      Many, many years ago (before toolbars in the task bar were a thing) I used a utility that could place program shortcuts in the notification area, and that allowed its icons to be ordered. Given the age of it I’d guess it just created the icons in the order it wanted them.

      (on “things programmers don’t do properly”, it’s surprising how many programs don’t recreate their icons if explorer is restarted!)

    5. Brian says:

      The likely reason for the importance of this is that there are specs that include a picture of the icons in a particular order. Changing the order of the icons (or specifying that there is no order) would require a change to the specs, and approval up and down the SDLC (it might even been in the requirements document – who knows). Not everyone develops code in a rational, agile manner.

  3. Don Reba says:

    Huh, never knew I could reorder the icons.

    1. Shawn says:

      I believe it was introduced with Windows 7. Taskbar didn’t get much more than a new color in Vista, so I doubt the notification area was able to be adjusted in it.

      1. Ray Koopa says:

        Yeah, it was all part of the “superbar” renovations in Windows 7.

  4. Mr Cranky says:

    I would thank this customer for reporting the “security exposure”, and promise it will be closed in the next Windows update.

  5. Danny says:

    Your team should’ve responded/helped with a “custom notifications dude” reply. Sometime it pays to go the extra mile since not only you have an already code base for future similar requests, but also steer the customer from an unwanted direction. Letting the customer run wild is what comes bite in the proverbial rear your compatibility team later.

  6. Rick C says:

    “The user can also drag the icon directly from the notification area into the overflow, or vice versa. The user can even drag the icon within the notification area to customize the order. ”


  7. Joshua says:

    At least this doesn’t fall under “what if two programs did this”. There’s no fundamental reason why rearranging your own program’s notification icons is asking for a proxy fight.

    1. Scarlet Manuka says:

      Until they start fighting for the first position, or something.

  8. Z says:

    I did not know that you could drag the notification icons around. Nifty

  9. DWalker07 says:

    I agree with others, aren’t there more important things for the programmer to worry about? Have they thoroughly tested every piece of their code for possible buffer overflows, invalid assumptions, etc.? Sheesh.

    1. Chris Crowther says:

      Changes like this aren’t being driven by developers looking for something to do. They’re driven by usually non-developers going “can’t you make it $foo”?

  10. kantos says:

    Cases like this I’d kindly inform them that the window name may change with every release of windows. Then I’d set a build step to randomize the window name for that control with every single patch that touched that component. This is similar to what some compiler writers have done to discourage people from using internal methods, they deliberately change them every single release.

    1. Koro says:

      Why stop there, change it at every run!

      Though it won’t stop the determined developer from making up an heuristic (“second child of the first control near this position whose class name matches this pattern…”)

    2. Azarien says:

      Microsoft chooses rather not to break badly written applications (or hacky UI customizers) just for the sake of breaking them. For example the class name of the taskbar has been Shell_TrayWnd since Windows 95.

    3. Stéphan Leclercq says:

      Alternatively, and for approximately the same amount of work, you may want to realize one day that some of us write Windows applications that are used in “kiosk” mode and shared by multiple users to control some (usually large and expensive) hardware thingy. In that case the assumption “it’s the one currently holding the mouse who gets to decide where icons go” is not valid… So some variation of the “Windows embedded” version could be activated, where questions such as “what if two apps did that ?” do not hold because you guarantee there is only one app.

      1. GL says:

        In that case, you would change the shell program from Explorer to your kiosk program (policy available in GPEdit since long), and you can draw whatever you like in that program. By the way, Windows 10 seems to have more convenient interfaces for assigning dedicated apps to kiosk accounts.

  11. James Sutherland says:

    Presumably what they should have done is have a single notification icon, which would then show some sort of popup/menu containing the icons they wanted? I could see the appeal of something like a media player having a set of “<< [] >>” icons as a single group, at least – but better a little popup window than hacking around overriding the order though, and less clutter when the user isn’t interacting with it.

    1. Damien says:

      You’re not getting into the right mindset here. Obviously this program is the most important program that the user will ever run. Of course, it should take up as much space in the notification area as it wants to.

      1. Aged .Net Guy says:

        You win the comments.

        I’d not be surprised to learn their true goal was to locate and hide icons from competing products while ensuring their precious product’s sole icon is always in visible position 1.

        To be sure there’s lots of raw incompetence amongst the world’s techies and plenty of confused UI/UX designers as well. But for sheer “You want to do WHAT!!??!” bad citizenship by apps look to the sales department as the driver.

  12. ender9 says:

    I wish Windows remembered the order of notification icons that I (as user) set, but unfortunately they always move around somewhat.

  13. jimbo1qaz says:

    Honestly I would prefer if the icons of Core Temp (the temperature of each CPU core) remained in order of the CPU cores they represent. But that feature doesn’t exist and Microsoft won’t let it happen.

    1. Entegy says:

      Drag them into the order you want. Done.

      1. dmex says:

        The shell only remembers the order of application icons not each individual icon… If you have App1, App2, App3 then you arrange those icons App2, App3, App1 the shell will remember that order when you close/launch each of those applications later. However, if App2 creates three icons Core1, Core2, Core3 then you rearrange those icons Core2, Core3, Core1 and later restart the application they’ll be reset 1,2,3 instead of previous 2,3,1 configuration.

        The main problem is users expect the order to be remembered for every individual icon like it already does for other icons and when other applications that ‘fix’ the behavior using hacky workarounds they’ll assume that application is doing it wrong and blame the developer when in reality its a problem with how the shell persists icon guidItem/uID ordering.

Comments are closed.

Skip to main content