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

[Rob Davenport]

I tried it again tonight on my Windows 10 laptop.  Pinning Emacs created a shortcut to emacs.exe with no applications user model id.  And taskbar icons weren't grouped.  I added the GNU.Emacs id to the shortcut using the registry technique mentioned before.  Then the icons were grouped.   Which is the same behavior I saw on my Windows 7 laptop.  David reported pinning did create a shortcut that worked (grouping icons) so presumably setting the app id.  I suspect *I'm* doing something different than David -- or have a different environment, and if I were running Windows 8.1, it wouldn't work for me either.  

And I was thinking when pinning, Windows may look into the target file looking for a property store containing the app id, but emacs.exe doesn't have a property store - it's sets the app id when running - so the shortcut doesn't get the id.  Then again, I only know that shortcut files contain property stores.  And it may be that only shortcuts contain property stores that the shell cares about.  It's not probably much of a problem since most windows programs concerned with the taskbar grouping are installed with installers and they set the app id in the shortcut so the grouping is as expected.  

On Fri, Oct 9, 2015 at 5:08 PM, Rob Davenport <address@hidden> wrote:

Interesting.  I ran my earlier test on this Windows 7 laptop and when I pinned Emacs, the shortcut did *not* have any App ID.   I don't have a Windows 8 machine (my other laptop is now Windows 10), as I would like to test it there.  But you're saying it works correctly in Windows 8.1.   Does it work for you in Windows 7?   If so, then there's something different about my Windows 7 machine causing it to not set the app id when pinning.  And apparently it only works in Windows 8.1, not 7 or 10.  Odd.

Either way, I think we have two ways to set the App ID in the shortcut (win7appid tool and the Details tab after applying that registry change - and I updated emacswiki.org with that tip as well [1]).

Rob

[1] http://www.emacswiki.org/emacs/EmacsClient#toc16

p.s. Every time this week I go to emacswiki.org it comes up in a non-English mode - it's been in Russian and Swedish for me.  Anyone else seen that?  I tried clearing cookies and cache.  Weird.


-----Original Message-----
From: help-emacs-windows-bounces+rob.davenport=address@hidden [mailto:help-emacs-windows-bounces+rob.davenport=address@hidden] On Behalf Of David Vanderschel
Sent: Friday, October 09, 2015 4:26 PM
To: Eli Zaretskii <address@hidden>; Rob Davenport <address@hidden>
Cc: address@hidden

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



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

Regards,
   David V.