If you use the pinning feature in Windows on a running session, it will pin a reference to vncviewer.exe and not tlclient.exe. This is of course not what we want. There are two options here: a) Prevent pinning b) Force pinning to associate with tlclient.exe They both require similar kind of effort, so b) is probably more sensible. Documentation for doing this can be found here: http://msdn.microsoft.com/en-us/library/dd378459(v=vs.85).aspx Unfortunately it involves a lot of magical COM, so it's probably a fair bit of work. Might also need fixes in mingw.
Also, if you drag the shortcut to the taskbar, grouping does not work.
One workaround for this problem could be to tweak vncviewer.exe so that it instead launches tlclient.exe, if called without arguments.
I'm not seeing this problem on my Windows 7 laptop with the 4.6.0 client - it works correctly, as far as I can tell. Reopening for discussion.
Since this seems to work, we are moving to test. The tester should however see if it is possible to reproduce the problem with earlier versions of the client and/or Windows.
(In reply to comment #4) > Since this seems to work, we are moving to test. The tester should however see > if it is possible to reproduce the problem with earlier versions of the client > and/or Windows. Tested using 4.6.0 client. Verified an pinned shortcuts (Win 7, Win 8) still points to vncviewer.exe which with Bug 5373 opens the ThinLinc client. I couldn't verify Win 10 due to its shortcut was not stored on disk Note that Win10 didn't store the shortcut on the same place as Win 7/8 but google says it should so i couldnt verify this platform
We haven't checked what the consequences of the current workaround is, but they will most likely be related to actions performed on the exe:s. E.g. getting the properties of the file and adjusting compatibility settings, or dragging files to the shortcut and expecting the right program to open it.
