The following Python 3 porting directive applies to anyone working with Windows API functions, specifically ones requiring strings for certain operations:
August 2019 Python 3 add-on directive no. 1: standardize around Unicode (wide character) functions unless justified otherwise
Certain Windows API functions expect different string data format depending on which function signature is invoked:
Functions defined this way include FindWindow, FindWindowEx, and others. Because Python 3 wants to use Unicode by default, you should call wide character functions (FindWindowW, for example) unless justified otherwise. If you absolutely need to use ANSI functions, please prefix strings with a “b” (without quotes).
HWND = winUser.user32.FindWindowW(“windowClassName”, None) # strictly Python 3
HWND = winUser.user32.FindWindowA(b“ANSIClassName”, None) # Python 2 and 3
HWND = winUser.user32.FindWindowW(u”UnicodeClassName”, None) # Python 2 and 3
HWND = winUser.user32.FindWindowA(“windowClassName”, None) # strictly Python 2
HWND = winUser.user32.FindWindowA(“UnicodeClassName”, None) # No in Python 3
HWND = winUser.user32.FindWindowW(b”ANSIClassName”, None) # Wrong data type across Python versions
Of these, I recommend going with option 3 (from first list), as it guarantees widest compatibility.
The following add-ons are affected:
Add-ons noted above may load under NVDA 2019.3 alpha if manifests are modified. For add-ons hosted on community add-ons website, StationPlaylist and SystrayList passes this check.
Next steps: please contact add-on authors regarding their thoughts on compatibility.