[python-win32] Problem reading a shortcut (.lnk) with cPython 3.7 (32 bit)

[David Hughes]

On 18/06/2019 22:38, Tim Roberts wrote:
> David Hughes wrote:
>>
>> I'm in the process of upgrading my software from Python 2.7 to 3.7 
>> now that wxPython has been migrated to 3. As part of a procedure for 
>> upgrading an end user's own installation I check for it's location 
>> via the desktop shortcut that Innosetup created during the original 
>> installation.
>>
> That's not a particularly good method in the general case.  I don't 
> find much use for the desktop icon, so I suppress it.  You might be 
> better served to use the registry, in 
> HKEY_LOCAL_MACHINE\Software\Python\PythonCore.  32-bit installations 
> will be in HKEY_LOCAL_MACHINE\Software\WOW6432Node\Python\PythonCore 
> (if you're reading from a 64-bit app).

My apologies, I should have made it clear the shortcut is to the 
stand-alone executable (py2exe/PyInstaller) version of my own software.

>> I have a procedure for doing this that worked/works fine with Python 
>> 2.7 that is very similar to the one published in 
>> /http://timgolden.me.uk/python/win32_how_do_i/read-a-shortcut.html/. 
>> Neither mine nor Tim's works under Python 3.7 (I haven't checked any 
>> other version of 3). With Tim's version, when the line
>>
>>     name, _ = link.GetPath (shell.SLGP_UNCPRIORITY)
>>
>> is executed, after a delay it responds with /aborted (disconnected)/ 
>> and the program terminates, as does mine.
>>
> Is it possible you have installed a 32-bit Python on a 64-bit system?  
> Theoretically, you should be able to use CLSID_ShellLink from either 
> one, but I'm trying to narrow things down.  Tim's code works fine for 
> me with Python 3.7.2 (64 bit) on Windows 10. 

The problem first arose in a 32 bit Python installed on a 64 bit Windows 
10 but the same error also occurs with 64 bit Python. However, both of 
these are virtual environments installed using venv. When I tried Tim's 
program using the original system-installed Pythons both the 32 and 64 
bit versions of 3.7 work fine.

Aha! To make the system-installed Pythons work I had to pip install 
pywin32 and this installed version 224. Both the virtual environments 
contained pywin32 version 223. After upgrading to version 224 both now 
work! :))

-- 
Regards

David Hughes
Forestfield Software