CODEWITHSUNDEEP
c#.netvbawindows-7taskbar
Heinzi
Heinzi

Reputation: 172438

How do I associate my application with a pinned program on the Windows 7 taskbar?

We have an application, let's call it MyApp. On installation, we create a desktop icon for MyApp, which basically calls MyLauncher.exe /launch MyApp.exe. MyLauncher does some useful stuff (check for updates, etc.), and then starts MyApp.

MyApp on the Desktop

A user with Windows 7 might want to pin it to the task bar (i.e., right mouse button on the desktop icon, "Pin to Taskbar"):

MyApp on the Taskbar

However, since the shortcut points to MyLauncher, the following happens when the user starts the application (either with the desktop icon or the taskbar icon): MyLauncher does its stuff, and, afterwards, it starts MyApp. On the taskbar, the result is as follows:

MyApp twice on the Taskbar

I understand why this happens. Since MyLauncher starts MyApp, the Windows 7 taskbar sees them as two different applications.

Obviously, my question is: As the developer of MyLauncher and MyApp, can I do something about this? I'd like the Windows 7 taskbar to "associate" all instances of MyApp.exe with the shortcut starting MyLauncher.exe /lauch MyApp.exe.

Upvotes: 18

Views: 2990

Answers (4)

Coden
Coden

Reputation: 2888

It was already mentioned to set the Application user Model ID. How this is done could be easily seen in this post: How to group different apps in Windows task bar?

But then you still have the problem that when the Application is pinned, it will not pin the Launcher. But there is also a solution for this, that the Launcher is pinned instead: Pinning to the taskbar a "chained process"

Upvotes: 0

NSGaga
NSGaga

Reputation: 14312

1)
This is more of an architectural question / problem - that's a bit of an unusual design for such purposes,
i.e. if an updater (I'm guessing you have more but to start w/ that) is required that's usually checked within the app - then if update is deemed you start an outside process and update the app etc.
Launcher (as described) would make sense if you are launching many different things or you have a generic solution or in more complex cases - e.g. you have a 'host process' that loads dll-s, services etc.
So basically you're running into problems because of a bit unfortunate design, decision - unless you have something that warrants that sufficiently.
But having you said that you didn't wish to redesign...
2)
You could still do a 'trick' with launcher - and make kind of a simple work around...

  • Launch the 'MyApp -argument:check' first (and have icon on desktop belong to it, not the launcher), and have an argument 'fork' on startup and if 'check' do a small 'shim' code which lauches the 'MyLauncher',
  • get the launcher to do what it's supposed to be doing - you can even close the main MyApp after launching,
  • when launcher is done it launches the MyApp again (or more complex to close if left only if update is needed etc. - but the previous is easier), and use some other argument or don't use any (depends on what you want etc.),
  • You're doing some process double redirection of a sort - start app => launcher => app again,
  • you should have no problems with the icons this way,
  • with all this you should be careful about supplying proper manifests to either app (most often the launcher which needs to update, more permissions) if an 'admin' mode is required, but I guess you have that already,

that might do the trick, haven't tried but I don't see why it shouldn't - and you can keep the existing architecture in place etc.

Upvotes: 0

Mark Sowul
Mark Sowul

Reputation: 10610

Try playing around with the "App Ids" See here for more info: http://msdn.microsoft.com/en-us/library/windows/desktop/dd378459(v=vs.85).aspx

"Application User Model IDs (AppUserModelIDs) are used extensively by the taskbar in Windows 7 and later systems to associate processes, files, and windows with a particular application. In some cases, it is sufficient to rely on the internal AppUserModelID assigned to a process by the system. However, an application that owns multiple processes or an application that is running in a host process might need to explicitly identify itself so that it can group its otherwise disparate windows under a single taskbar button and control the contents of that application's Jump List."

Upvotes: 3

evasilchenko
evasilchenko

Reputation: 1870

One thing you can do is not show the task-bar icon for the application at all. In WPF it's as simple as a property setting:

ShowInTaskbar="False"

The problem with this approach is that it will reduce usability because the user can no longer tell when the application is running or easily bring it to the forefront when it gets lost behind other windows. In order to alleviate some of these concerns, you can create a notify icon for this application which would enable some of these functions and also give the user some feedback as to the application's current state. (Running, not running, etc..)

This msdn resource has a good code sample on how to create notify icons in windows forms. You can use the same method for WPF applications as well.

enter image description here

SMALL TIP: Notify icons are 16x16 pixels. Try to find a vector version of the icon prior to resizing as this will give you crisper results because you tend to lose a lot of detail at that size.

Some user interaction with the notify-icon can include:

  • Double-Click > Brings the application to the front
  • Right-Click > Brings up a context menu with some choices. (I.E. Bring to front, close, etc...)
  • Mouse-Over > Brings up a tool-tip with some information regarding the application.

Upvotes: 0

Related Questions