Alternate title from a non-programmer point of view: When I copy an executable to another name, sometimes it groups separately, and sometimes it groups with the original.
A customer had a product, let’s call it Contoso Designer. They decided to try an experimental new version of Contoso Designer. So they cloned the Contoso Designer project, and then started changing the parts of the program that were related to the experiment.
When they did this, they noticed that Contoso Designer Experimental and Contoso Designer both grouped together in the taskbar. This isn’t what they wanted, because the original and the experimental versions were not replacements for each other; they are separate programs that merely happen to have started out from the same code base.
So they ran another experiment.
They created a scratch project, put a scratch program in it, compiled it, and ran it. They then copied the scratch.exe
file to scratch2.exe
and ran that one, and it did not group with scratch.exe
in the taskbar. Then they cloned the scratch project, recompiled the scratch program, and ran the clone. All three copies were separate in the taskbar.
So what was haunted about their project that caused the clone to have a secret psychic connection to the original, and group together with it? And more important, how do they get it to stop?
The answer is in the Application User Model ID. As we saw some time ago, the Application User Model ID is how the taskbar identifies applications. If two processes have the same Application User Model ID, then they are treated as the same application, even if the physical executable is different. In other words, the program and its clone were following the instructions in that article and saying, “I want these programs to group together.”
Given that nudge, the customer wrote back, “Thanks. Updating the call to SetCurrentProcessExplicitAppUserModelID
did the trick.”
I hope they remembered to update their Start menu shortcut, too.
0 comments