I implement a notify icon for my application by call Shell_NotifyIcon.
In the default, the notify icon display in the notify icon area instead of task bar in windows 7.
If the user want to show the notify icon in the task bar, he/she need to open the Notification Area Icons control panel item, find the application and set "Show icon and notifications" for the application.
I think it will be difficult to the user with poor windows knowledge. I want to implement this function that show the notify icon in the task bar in my VC++ code or installer. Is it possible? If yes, what should I do?
Appreciate.
No, this is not possible.
Windows 7 introduces a feature where notification icons can be hidden. It is an attempt to reduce the noise created by decades of developers dumping notification icons in the taskbar for no good reason.
In order for that feature to work effectively, there can't be a loophole for applications to get around it, because everyone thinks their application is the most important and the most deserving of prime real estate. Eventually, nothing is sacred anymore.
Raymond Chen has blogged about this very request, and provides some additional background info.
You just create the notification icon and provide the user with instructions in the documentation on how to show it permanently, if they so desire.
Why not just pin your application to the task bar? They can just click it and it will launch the application?
Related
If I have a program running in the background and it needs the user to see it (like a dialog box) when it pops up, can I take the user out of Metro Mode (in Windows 8) for him to be able to see this notification?
I highly doubt it, such a capability would spawn a bunch of apps that would essentially try to take over and be very jarring for the user. Your desktop app though could generate a toast notification that would alert the user there is some action to take, see this MSDN topic for details.
I agree with Jim: switching context automatically from the desktop to Metro (or whatever they're calling it now) would be visually jarring and user-hostile. I realize the OS itself does this, like when you launch a desktop app from the Start screen. That doesn't make it good design.
Besides, when it does it, the user (presumably) wanted to interact with the newly-launched application. That's not necessarily the case when you're just showing a notification. There may not even be action required.
Instead, I recommend that you use Toast, the notification framework designed explicitly for this purpose. There's a sample application available for download: Sending toast notifications from desktop apps.
Note, however, that in order for Toast notifications to work from desktop applications, you must install a shortcut to your desktop application in the Start screen, with a System.AppUserModel.ID. This should be handled by your installer. More information is here.
Of course, the user can disable this by either turning off notifications or removing your app's shortcut from their Start screen. That's perfectly okay—if they take either of these actions, you can assume that they no longer want to receive notifications from your app.
How do I find which Windows process is displaying a given taskbar system tray icon?
I've just realised that in Windows 7 the 'Select which icons and notifications appear on the taskbar' menu helps a bit here. Find it by right-clicking the taskbar, go to 'Properties', then click the 'Customize...' button in the 'Notification area' frame.
Each row in that window represents a taskbar icon that Windows Explorer has seen. Of the left two rwos, I believe the top one is the process's description as shown in Task Manager, and the bottom one is the window title for the window showing the taskbar icon.
This would've helped me track down my original problem! VisualSVN was popping up a 'Register me!' nag window in the system tray, despite no obvious VisualSVN processes running. Eventually I noticed that this nag window disappeared when I closed Visual Studio, so it was clear that the VisualSVN add-in DLL loaded in Visual Studio was creating the nag window.
Shell_NotifyIcon works by sending a special WM_COPYDATA message to the taskbar, if you inject into explorer and subclass the taskbar you could catch this message, you could then get the process id by calling GetWindowThreadProcessId on COPYDATAstruct.NOTIFYICONDATA.hwnd.
...and of course, this is a hack and relies on undocumented information that could change at any time!
I don't believe this to be possible. Certainly Spy++ reports that the Notification area is a single window named "User Promoted Notification Area". This window is ultimately parented with the desktop window and has no obvious association with the process that created the notification icon.
Well, by possible I mean possible without resorting to hacks like Anders suggests which is no doubt feasible, but not what I imagine the OP is looking for!
I'd like to show another app's windows under my app's taskbar button. It's a background app that reports another process's windows as my app's own. Is there any universal way to do this, e.g. each "new" window, alert glow, progressmeter, and other taskbar features, show under my own app's button?
For example, Winfox runs under its own process and steals Firefox's windows. It also adds features, but that's irrelevant -- I just want to support another app's existing taskbar features under my own app's button -- multiple windows, progressmeter, alert flashing, error flashing, mini-icons, etc. Is there a near-universal way to steal an app, or is it largely app-specific? Thanks!
You should be able to use SetParent() to take ownership of a window, but I'm not sure how much this will help you in your attempt to add taskbar features to the legacy app.
new Windows 7 hides systray icons by default.
what is the recommended way to show information to users now?
I need to have a small clickable icon visible to user so user can access my "tool" anytime. Should I use the gadget to show my GUI instead? Can it communicate with my Delphi app somehow?
Without more information it's a little difficult to provide a recommendation.
However, I would imagine that a sufficiently important tool, the user would simply keep minimized. They could then use Jumplists to access quick functionality.
For example, Live Messenger uses this setup on Win7.
If your users really like your icon/application they can always choose to not hide your application.
The only difference is that only the user can choose which icon is shown, instead of every application claiming it's "real estate".
In my opinion this is a good functionality and if I were you I wouldn't change the application, just provide a first run GUI which explains how to make your tray icon visible in windows 7.
The entire reason why change was made, was to stop programs like yours. If you need to show information, go ahead and do so. But the notification areas ("systray") is not where shortcuts go. For that, you've got the start menu, desktop and/or the quick launch bar (and please let the user decide).
I've seen a few Windows 7 applications popping up around the web that take advantage of the new task bar functionality. However, some of these applications are treating the task bar like the notification area. There is no foreground window. All interaction is done through the task bar button (with overlays, progress bars, jump lists, etc).
Personally, I like the new task bar more than the notification area because I have the ability to use larger icons and give the user a very familiar user interface with a rich experience. But I also feel like applications like those described above should be kept in the notification area.
What do you think about applications that use the Windows 7 task bar as the "new notification area"? Should it be avoided?
Microsoft is doing its best to discourage use of the 'notification area', frequently referred to as the 'System Tray'. Instead they encourage more detailed and interactive application icons. For example, the progress bar that's visible on the explorer icon when you're performing file operations in the explorer.
Read the windows user experience interaction guidelines for more details on the new recommended functionality.