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

Question

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.

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"):

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:

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.

Ess

Just in case it's relevant: MyApp.exe is actually msaccess.exe MyVbaProject.mdb, hence the VBA tag. The VBA application makes heavy use of (our own) .net libraries, hence the c# and .net tags. A solution in any of these languages is fine. Windows API calls are fine as well. – Ess

See Windows® API Code Pack for Microsoft® .NET Framework and Code Project: Windows 7 / VS2010 demo app – Laniferous

This might help #3648886 – Aires

Answer 1

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."

Mercola

If you're a .NET process, the Windows API code pack will be of help. – Mercola

Answer 2

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.

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.

Kempis

Answer 3

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.

Tmesis

Answer 4

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"

Jezreel