Also look for shortcut in the system Start Menu.

[agashlin]

With an installer a shortcut is often created in the system Start Menu under %PROGRAMDATA%, this patch looks for an existing shortcut there, to avoid creating a new shortcut in the user's Start Menu under %APPDATA%.

The permission had to change to STGM_READ on persistFile->Load() so the system shortcut can be read, this is all that's needed to read the shortcut, the persistFile->Save() call seems to still work correctly.

I wrote this before looking at PR #52, but it might help in some of those situations as well, though maybe this isn't sufficiently useful to take upstream.

[ChristianGalla]

Thanks tor the PR @agashlin.

If there is a shell link in %PROGRAMDATA% and %APPDATA%, should both shortcuts be checked for correct AUMI before changing the one in %APPDATA%?

Has someone checked what happens if there are multiple shortcuts having the same AUMI?

[agashlin]

If there is a shell link in %PROGRAMDATA% and %APPDATA%, should both shortcuts be checked for correct AUMI before changing the one in %APPDATA%?

Has someone checked what happens if there are multiple shortcuts having the same AUMI?

Hm, that's an interesting question. It's my understanding that having both a system and a user shortcut with the same name will cause the system one to be ignored, as far as showing them in the Start Menu, but I haven't checked if that applies to AUMI as well.