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.
Related
When Firefox downloads a file, its title button on the taskbar doubles as a progress bar (it gets progressively painted green, starting from the left).
Other programs do it, too. (Windows Commander, AIMP3...)
How to do it with Lazarus? (Or using the Win API directly)
This capability was introduced in Windows 7 as part of its Taskbar Extensions:
As of Windows 7, the taskbar has been extended significantly under the guiding principle of getting users where they're going as quickly and efficiently as possible. To that end, the application windows, files, and commands that the user needs to accomplish that are now centralized into a single taskbar button that consolidates previously scattered information sources and controls. A user can now find common tasks, recent and frequent files, alerts, progress notifications, and thumbnails for individual documents or tabs all in one place.
...
Progress Bars
A taskbar button can be used to display a progress bar. This enables a window to provide progress information to the user without that user having to switch to the window itself. The user can stay productive in another application while seeing at a glance the progress of one or more operations occurring in other windows. It is intended that a progress bar in a taskbar button reflects a more detailed progress indicator in the window itself. This feature can be used to track file copies, downloads, installations, media burning, or any operation that's going to take a period of time. This feature is not intended for use with normally peripheral actions such as the loading of a webpage or the printing of a document. That type of progress should continue to be shown in a window's status bar.
The taskbar button progress bar is a similar experience to the familiar Progress Bar control. It can display either determinate progress based on a completed percentage of the operation or an indeterminate marquee-style progress to indicate that the operation is in progress without any prediction of time remaining. It can also show that the operation is paused or has encountered an error and requires user intervention.
APIs
ITaskbarList3::SetProgressState
ITaskbarList3::SetProgressValue
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?
I am working on a windows phone 8 c# application. I have to get long tap events of Forward and Backward buttons that I have placed in the Application bar, but found only Click event for application bar button.
Please let me know how to capture the long tap event for an application bar button?
Thanks in Advance
This is not possible. The ApplicationBar API is quite restrictive, which is a deliberate move by Microsoft to ensure consistency. You cannot handle arbitrary events from the ApplicationBar. If you want this kind of behaviour, you will have to build your own UI to support it.
It is worth noting that your users will not expect 'long press' (more commonly referred to as tap-and-hold) behaviour on the app-bar.
I'm a Mac user and a Windows user (and once upon a time I used to be an Amiga user). I much prefer the menu-bar-at-the-top-of-the-screen approach that Mac (and Amiga) take (/took), and I'd like to write something for Windows that can provide this functionality (and work with existing applications).
I know this is a little ambitious, especially as it's just an itch-to-scratch type of a project and, thanks to a growing family, I have virtually zero free time. I looked in to this a few years a go and concluded that it was very difficult, but that was before StackOverflow ;)
I presume that I would need to do something like this to achieve the desired outcome:
Create application that will be the custom menu bar that sits on top of all other windows. The custom menus would have to provide all functionality to replace the standard Win32 in-window menus. That's OK, it's just an application that behaves like a menu bar.
It would continuously enumerate windows to find windows that are being created/destroyed. It would enumerate the child windows collection to find the menu bar.
It would build a menu that represents the menu options in the window.
It would hide the menu bar in the window and move all direct child windows up by a corresponding pixel amount. It would shorten the window height too.
It would capture all messages that an application sends to its menu, to adjust the custom menu accordingly.
It would constantly poll for the currently active window, so it can switch menus when necessary.
When a menu hit occurs, it would post a message to the window using the hwnd of the real menu child control.
That's it! Easy, eh? No, probably not.
I would really appreciate any advice from Win32 gurus about where to start, ideas, pitfalls, thoughts on if it's even possible. I'm not a Win32 C++ programmer by day, but I've done a bit in my time and I don't mind digging my way through the MSDN platform SDK docs...
(I also have another idea, to create a taskbar for each screen in a multi-monitor setup and show the active windows for the desktop -- but I think I can do that in managed code and save myself a lot of work).
The real difference between the Mac menu accross the top, and the Windows approach, is not just in the menu :- Its how the menu is used to crack open MDI apps.
In windows, MDI applications - like dev studio and office - have all their document windows hosted inside an application frame window. On the Mac, there are no per-application frame windows, all document windows share the desktop with all other document windows from other applications.
Lacking the ability to do a deep rework of traditional MDI apps to get their document windows out and onto the desktop, an attempt, however noble, to get a desktop menu, seems doomed to be a novelty with no real use or utility.
I am, all things considered, rather depressed by the current state of window managers on both Mac and Windows (and Linux): Things like tabbed paged in browsers are really acts of desperation by application developers who have not been given such things as part of the standard window manager - which is where I believe tabs really belong. Why should notepad++ have a set of tabs, and chrome, and firefox, and internet explorer (yes, I have been known to run all 4), along with dev studios docking view, various paint programs.
Its just a mess of different interpretations of what a modern multi document interface should look like.
The menu bar on a typical window is part of the non-client area of the window. It's drawn when the WndProc gets a WM_NCPAINT message and passes it on to DefWindowProc, which is part of User32.dll - the core window manager code.
Other things that are drawn in the same message? The caption, the window borders, the min/max/close boxes. These are all drawn while processing a single message. So in order to hide the menu for an application, you will have to take over handling of this message, which means changing the behavior of user32.dll. Hiding the menu is going to mean that you become responsible for drawing all of the non-client area.
And the appearance of all of these elements - The caption, the borders, etc. changes with every major version of Windows. So you have to chase that as well.
That's just one of about a dozen insurmountable problems with this idea. Even Microsoft probably couldn't pull this off and they have access to the source code of user32.dll!
It would be a far less difficult job to echo the menu for each application at the top of the screen, and even that is a nearly impossible job. When the menu pops there is lots of interaction with the application during which the menu can be (and often is) changed. It is very common for applications to change the state of menu items just before they are drawn. So you will have to replicate not only the appearance of the menus, but their entire message flow interaction with the application.
What you are trying to do is about a dozen impossible jobs all at once, If you try it, you will probably learn a lot, but you will never get it to work.
I'm wondering how to dock / snap a window to the side of the screen in Windows, preferably with straight Win32 API. The effect I'm looking for is like the task bar -- a window that has a reserved space on screen, so that maximizing another window makes that window take up the rest of the screen, but leaves my window in place and visible.
I know various IM clients do this, but haven't been able to find any resources on how to do it. Not sure what the appropriate name for it is either.
Edit: "Application Desktop Toolbar" is the search term to use to find info on this.
IIUYC you're looking for an app bar (MS-officially "Application Desktop Toolbar"). You can indeed create these with the Windows API.
"App Bar" - you turn a window into an App Bar by sending the ABM_NEW message. Examples on MSDN:
http://msdn.microsoft.com/en-us/library/cc144177(VS.85).aspx
http://support.microsoft.com/kb/134206