[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [h-e-w] Windows 10 Taskbar Behavior

From: David Vanderschel
Subject: Re: [h-e-w] Windows 10 Taskbar Behavior
Date: Fri, 9 Oct 2015 15:25:48 -0500
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 10/9/2015 2:40 AM, Eli Zaretskii wrote:

From: Rob Davenport <address@hidden>

Microsoft says the way to solve this is to explicitly set an AppID which
overrides the heuristics. So for better behavior in Windows 7 and later, all
emacs processes (emacs.exe, runemacs.exe, emacsclientw.exe, etc.) should be
modified to call SetCurrentProcessExplicitAppUserModelID() during their
Yes, that's true.  However, Emacs on Windows has been doing precisely
that, i.e. calling SetCurrentProcessExplicitAppUserModelID, since
2009, i.e. since Emacs 23.2 at least.  And IME it works fine on
Windows 7.  The question is, why doesn't it on Windows 10?

IOW, the issue is not the changes in Windows 7, which we already
handle, AFAIK, but the changes in Windows 10.

I think it is a bug in Windows 10. Using the app ID program after I pin Emacs to the taskbar in Windows 8.1, the app ID associated with the shortcut is already "GNU.Emacs". However, in Windows 10, the program reports that there is no app ID associated with the shortcut. So setting the ID (as it should have been set on pinning the program) fixes the problem. (I also observed that the app ID is not case sensitive.)

  David V.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]