>devblog_

It’s a nice feature for your software if your customer can minimize it as an icon to the system tray. From our “minimize to tray” program I learned a few things about. Here’s a rundown of the basic and not-so-basic tricks.

1. You can add / modify / remove a tray icon with Shell_NotifyIcon. You can specify a callback message (for example WM_USER) to react to left/right clicks on the icon. To hide your program when minimized simply use ShowWindow.
2. To minimize to the tray when your user click the minimize button, handle the WM_NCLBUTTONDOWN message and watch for the HitTest HTMINBUTTON (or HTCLOSE if you want to override the X-button).
3. If you want to prevent Windows from hiding the icon, make a tiny chnge to the icon every now and then. (Do this only if you have good reason!)
4. You can use DrawAnimatedRects for a minmize animation. Use FindWindow(”Shell_TrayWnd”, …) to find the location (= target reactangle for the animation)
5. If the windows explorer crashes, the tray icons are gone and your user can’t get your application back. To detect this, use Shell_NotifyIcon(NIM_MODIFY, … every now and then and check the return value. If the function fails, then your icon is gone and you have to add in again.
6. Don’t forget to remove the tray icon if your program closes while being minimized.

Some years ago I wrote a computer game that had a really nice effect for displaying the menus. It looked really cool, but it took several seconds until the menu text was displayed properly. Since I knew the menus by heart, I clicked even before it was readable and could navigate the menus efficiently. I didn’t even notice that there was a problem until I’d shown the program to friend and he’d explained to me what I was doing.

I had gotten used to it and didn’t see the problem any more.

And I think that this is a common problem when you’re developing a program. In the end you know it so well, that you’re not noticing any more when anything isn’t solved properly. This applies mostly to the user interface, but it can also apply to programming and performance. The best way for this is to have somebody elso use the program and just sit next to him. Don’t explain. Just watch. You’ll be surprised…

However, sometimes there’s an easier way.

Currently I’m developing a new software and I noticed that there is a short time span before you get used to a bad solution. I noticed several times that I clicked at the wrong location, that I thought a dialog wasn’t easy to understand or that it would be great if the user could do this or that here (for example drag a file into the dialog instead of entering the path). For my new software (for a change) I try to note these thoughts and improve the program right away, hopefully creating a better first version.

So, if you’re creating a new software, notice your own problems and thoughts. And fix things before you get used to it.