|
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>
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.)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 startup.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.
Regards, David V.
[Prev in Thread] | Current Thread | [Next in Thread] |