Re: win32clipboard writing to clipboard on Windows 11
On Tue, Jun 18, 2024 at 2:19 AM Eryk Sun wrote: > > > def set_clipboard_text(text): > hMem = global_alloc_text(text) > try: > win32clipboard.SetClipboardData(win32clipboard.CF_UNICODETEXT, > hMem) > # Now the system owns the global memory. > except: > kernel32.GlobalFree(hMem) Oops, that suppresses the exception. Fixed: def set_clipboard_text(text): hMem = global_alloc_from_text(text) try: win32clipboard.SetClipboardData(win32clipboard.CF_UNICODETEXT, hMem) # Now the system owns the global memory. except: kernel32.GlobalFree(hMem) raise -- https://mail.python.org/mailman/listinfo/python-list
Re: win32clipboard writing to clipboard on Windows 11
On Mon, Jun 17, 2024 at 8:36 PM MRAB via Python-list
wrote:
> On 2024-06-17 20:27, Rob Cliffe via Python-list wrote:
>
> > SetClipboardData(CF_UNICODETEXT, "0")
> > CloseClipboard()
win32clipboard.SetClipboardData() first tries to covert the second
argument as an integer handle to global memory, which gets passed to
WinAPI SetClipboardData(). The integer conversion is basically via
int(). With int("0"), it's passing a NULL handle value, which
instructs the window manager to query the data from the window that
was associated via OpenClipboard(), if any. Since no memory handle is
passed in this case, SetClipboardData() returns NULL.
win32clipboard.SetClipboardData() misinterprets this as failure and
raises an exception for whatever random error code is currently set in
the thread's last error value. On the other hand, for a numeric text
string with a nonzero value, such as "123",
win32clipboard.SetClipboardData() will raise an exception for the
error code ERROR_INVALID_HANDLE (6), unless the integer value happens
to be a valid global memory handle value.
I recommend just using win32clipboard.SetClipboardText(). Otherwise I
don't see an easy workaround given the peculiar design of
win32clipboard.SetClipboardData(). You'd have to manually allocate a
block of global memory, copy the numeric text string into it, and pass
the global memory handle to win32clipboard.SetClipboardData(). For
example:
import ctypes
import win32clipboard
from ctypes import wintypes
kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)
GMEM_MOVEABLE = 0x0002
kernel32.GlobalAlloc.restype = wintypes.HGLOBAL
kernel32.GlobalFree.argtypes = (wintypes.HGLOBAL,)
kernel32.GlobalLock.restype = wintypes.LPVOID
kernel32.GlobalLock.argtypes = (wintypes.HGLOBAL,)
kernel32.GlobalUnlock.argtypes = (wintypes.HGLOBAL,)
def global_alloc_text(text):
array_t = ctypes.c_wchar * (len(text) + 1)
hMem = kernel32.GlobalAlloc(GMEM_MOVEABLE, ctypes.sizeof(array_t))
if not hMem:
raise ctypes.WinError(ctypes.get_last_error())
pMem = kernel32.GlobalLock(hMem)
try:
try:
array_t.from_address(pMem).value = text
finally:
kernel32.GlobalUnlock(hMem)
except:
kernel32.GlobalFree(hMem)
raise
return hMem
def set_clipboard_text(text):
hMem = global_alloc_text(text)
try:
win32clipboard.SetClipboardData(win32clipboard.CF_UNICODETEXT,
hMem)
# Now the system owns the global memory.
except:
kernel32.GlobalFree(hMem)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Compiling python on windows with vs
On 6/15/23, Thomas Schweikle via Python-list wrote: > > No. This flag is not inherited. Someone has to set it for created > directories. It is easy to confirm: take a directory not under MSYS or > cygwin control (because it is mounted by MSYS or cygwin), set the flag, > then create directories. They all will have caseSensitivInfo disabled. That was how the attribute was implemented initially in Windows 10, but subsequently it was made inheritable. For example: C:\Temp\test>mkdir spam C:\Temp\test>fsutil file setCaseSensitiveInfo spam enable Error: Access is denied. Setting the case-sensitive attribute requires the right to add files and directories (i.e. "WD" = "write data" / "add file"; "AD" = "append data" / "add subdirectory") and the right to remove files and directories (i.e. "DC" = "delete child"). The owner of a directory doesn't necessarily inherit these rights from the parent directory (which is my case here), but the owner of any object usually has the implicit right to modify discretionary security. Let's simply grant the owner (i.e. "OW" = "owner rights") full control of the directory (i.e. "F"), inheritable to child directories (i.e. "CI" = "container inherit"). C:\Temp\test>icacls spam /grant *OW:(CI)(F) processed file: spam Successfully processed 1 files; Failed processing 0 files C:\Temp\test>fsutil file setCaseSensitiveInfo spam enable Case sensitive attribute on directory C:\Temp\test\spam is enabled. Now, create a child directory and confirm that it inherits the case-sensitive flag. C:\Temp\test>mkdir spam\eggs C:\Temp\test>fsutil file queryCaseSensitiveInfo spam\eggs Case sensitive attribute on directory C:\Temp\test\spam\eggs is enabled. > Python itself isn't the problem here. It is MSBuild.exe. For some reason > this tool lowercases sometimes whole paths to files included. This does > not matter if case sensitivity is disabled. It matters if case > sensitivity is enabled! There is no reason MSBUild.exe does it. But it > is done for some paths (as someone else pointed out). For the specific problem you had when building 3.10 and 3.11, it's actually a bug in Python's source code, which is no longer present in 3.12+. It can be fixed in 3.11, but 3.10 no longer gets bug fixes. Here's the link to the issue on GitHub: https://github.com/python/cpython/issues/105737 I encountered a different bug when building the main branch. Building the _decimal extension module includes an .asm file. The relative path in the project file has the correct case, but the build system resolved the fully-qualified path as all lower case. This problem only occurred for this single file, out of hundreds of relative paths in the project files, so it's not like the build system is completely broken when working in case-sensitive directories. There are probably a few such bugs that need to be fixed in msbuild, the compiler, and linker. After all, these tools have been developed and tested for decades on only case-insensitive filesystems. But you don't have to be on the bleeding edge. There's no reason to make directories case-sensitive for repositories that are intended for use on Windows, such as CPython. -- https://mail.python.org/mailman/listinfo/python-list
Re: Compiling python on windows with vs
On 6/15/23, Thomas Schweikle via Python-list wrote: > > In this case: not sure what is going on. Possibly you have a setting configured that affects the behavior of Git via the MinGW-w64 runtime, such that calling mkdir() ends up calling NtSetInformationFile() to set the FileCaseSensitiveInformation for the directory. Does the mkdir command in Git bash create a case-sensitive directory? It doesn't for me. I have to manually enable case sensitivity via `chattr +C`. What do you get for `which git` and `git --version`? $ which git /mingw64/bin/git $ git --version git version 2.41.0.windows.1 > $ fsutil file queryCaseSensitiveInfo . The MSYS2 environment includes lsattr and chattr commands, with the case-sensitive flag mapped to "C". It's probably more convenient than typing `fsutil file queryCaseSensitiveInfo` or `fsutil file setCaseSensitiveInfo`. $ lsattr -d test test $ chattr +C test $ lsattr -d test ---C test > core.ignorecase is not regarded in any way. It does not mater if it is > set or not. Git tests the case-sensitivity of the target directory to configure core.ignorecase when cloning a repo. If it's case insensitive, then core.ignorecase is enabled. This overrides the global value. AFAIK, the ignorecase setting is unrelated to actually setting the case sensitivity of created directories; it just affects how Git behaves on a case-insensitive filesystem. -- https://mail.python.org/mailman/listinfo/python-list
Re: Compiling python on windows with vs
On 6/14/23, Inada Naoki via Python-list wrote: >> Since Git enables Windows NTFS case sensitivity while checking out sources > > I didn't know that. Would you give us a link to this feature? > As far as I know, `git config core.ignorecase` doesn't mean NTFS case > sensitive. If a repo is cloned into a case-insensitive directory, then core.ignorecase should be enabled automatically. If a repo is cloned into a case-sensitive directory, then core.ignorecase should not be enabled automatically. I searched through relevant issues on the Git for Windows repo on GitHub, and I found nothing to indicate that a capability to automatically enable NTFS case sensitivity has been added. I searched through the source of Git and Git for Windows, and I didn't find any references to WinAPI SetFileInformationByHandle: FileCaseSensitiveInfo or NTAPI NtSetInformationFile: FileCaseSensitiveInformation, nor the use of fsutil file setCaseSensitiveInfo. -- https://mail.python.org/mailman/listinfo/python-list
Re: Compiling python on windows with vs
On 6/13/23, Thomas Schweikle via Python-list wrote: > > Since Git enables Windows NTFS case sensitivity while checking out > sources ... is it a bug or a "feature"? And: is there a simple AFAIK the Windows version of Git (you're not using the Linux version of Git via WSL, right?) does not automatically enable NTFS case sensitivity. But a newly created directory does inherit the case sensitivity of its parent directory. Make sure to clone the CPython repo in a directory that has case sensitivity disabled. >_testconsole.c > C:\Users\sct-muc\Documents\Projekte\cpython\PC\_testconsole.c(13,10): > fatal error C1083: Datei (Include) kann nicht geöffnet werde > n: "..\modules\_io\_iomodule.h": No such file or directory > [C:\Users\sct-muc\Documents\Projekte\cpython\PCbuild\_testconsole.vcxpro > j] I just built the main branch in a case sensitive tree. I had no problem building "_testconsole.c". However, building the _decimal extension module raised a couple of serious warnings. In "PCbuild/_decimal.vcxproj", there's an include for "..\Modules\_decimal\libmpdec\vcdiv64.asm". However, MSBuild resolved this relative path with all lower-case names, i.e. "modules" instead of the correct name "Modules", and it incorrectly tried to output "vcdiv64.obj" in a subdirectory of "pcbuild" instead of the correct name "PCbuild". This appears to be a bug in MSBuild. A lot of Windows programs don't handle case-sensitive directories well, including Python's standard library. It's understandable when comparing paths, but the behavior in this case is inexcusably bad. -- https://mail.python.org/mailman/listinfo/python-list
Re: Assistance Request - Issue with Installing 'pip' despite Python 3.10 Installation
On 6/10/23, Thomas Passin via Python-list wrote: > > Yes; I didn't want to get too esoteric with commands that are hard to > figure out and remember, because then why not use Powershell, whose > commands are hard to figure out and remember? Using `dir /s [/ad] [/b] "[path\]pattern"` with a wildcard pattern is a simple way to recursively search for a filename or directory, without needing to pipe the output to a findstr/grep/awk command. It's also fast. Of course, CMD's wildcards aren't nearly as powerful as regular expressions. The examples I included with `for` loops in CMD were for completeness to show how to get the results in a loop variable for further processing in a batch script. Personally, I use `for` loops a lot even when working at the command prompt, but I'm a dinosaur in that regard. Using PowerShell really should be preferred nowadays. -- https://mail.python.org/mailman/listinfo/python-list
Re: Assistance Request - Issue with Installing 'pip' despite Python 3.10 Installation
On 6/10/23, Thomas Passin via Python-list wrote: > > We can find pip.exe using good old-fashioned dir (we don't need any > new-fangled Powershell): > > C:\Users\tom>dir AppData\Local\Programs\Python /Aa /S /W /B |find > "pip"|find "Scripts" CMD's `dir` and `for` commands support simple wildcard matching. For example, the following recursively searches for a file named "pip*.exe" under "%ProgramFiles%\Python311": C:\>dir /b /s "%ProgramFiles%\Python311\pip*.exe" C:\Program Files\Python311\Scripts\pip.exe C:\Program Files\Python311\Scripts\pip3.11.exe C:\Program Files\Python311\Scripts\pip3.exe C:\>for /r "%ProgramFiles%\Python311" %f in (pip*.exe) do @(echo %f) C:\Program Files\Python311\Scripts\pip.exe C:\Program Files\Python311\Scripts\pip3.11.exe C:\Program Files\Python311\Scripts\pip3.exe The following recursively searches for a directory named "pip" under "%ProgramFiles%\Python311: C:\>dir /ad /b /s "%ProgramFiles%\Python311\pip" C:\Program Files\Python311\Lib\site-packages\pip Or search for a directory name that starts with "pip": C:\>dir /ad /b /s "%ProgramFiles%\Python311\pip*" C:\Program Files\Python311\Lib\site-packages\pip C:\Program Files\Python311\Lib\site-packages\pip-22.3.1.dist-info C:\Program Files\Python311\Lib\site-packages\win32\Demos\pipes With a recursive `for /r path [/d]` loop, the strings in the set have to include wildcard characters to actually check for an existing file or directory, else each string in the set simply gets appended to the directory names in the recursive walk. For example, the following recursively searches for a directory (i.e. /d) named "pip*" under "%ProgramFiles%\Python311": C:\>for /r "%ProgramFiles%\Python311" /d %d in (pip*) do @(echo %d) C:\Program Files\Python311\Lib\site-packages\pip C:\Program Files\Python311\Lib\site-packages\pip-22.3.1.dist-info C:\Program Files\Python311\Lib\site-packages\win32\Demos\pipes To match a specific name, you can filter the matches using an `if` statement to compare the base filename of the loop variable (i.e. [n]ame + e[x]tension) with the required name. For example: C:\>for /r "%ProgramFiles%\Python311" /d %d in (pip*) do @( More? if "%~nxd"=="pip" echo %d) C:\Program Files\Python311\Lib\site-packages\pip -- https://mail.python.org/mailman/listinfo/python-list
Re: Assistance Request - Issue with Installing 'pip' despite Python 3.10 Installation
On 6/8/23, Thomas Passin via Python-list wrote: > > It always gets installed, though. By default, the option to install pip is enabled. It's implemented by executing ensurepip after the interpreter is installed. However, ensurepip may silently fail during installation. As a CPython triager I've come across this problem a couple of times, but it should be rare. It can possibly be resolved by manually executing ensurepip via the following command: py [-3[.X]] -m ensurepip --default-pip --upgrade --verbose If Python is installed for all users, the latter should be executed from a shell that has administrator access. Even if this command also fails, the verbose output in the console may be helpful to further diagnose the problem. -- https://mail.python.org/mailman/listinfo/python-list
Re: Assistance Request - Issue with Installing 'pip' despite Python 3.10 Installation
On 6/7/23, Thomas Passin via Python-list wrote: > On 6/7/2023 6:28 PM, Eryk Sun wrote: > >> That won't be of any help if pip isn't installed. By default, Python's >> installer attempts to install pip by running the ensurepip package, >> but sometimes it fails. It can help to try to manually run ensurepip >> in the shell. For example: >> >> py -m ensurepip --default-pip --upgrade --verbose > > Yes, but why should anyone besides the OP think pip isn't installed? Let > him try py -m pip. If pip isn't installed he will see something like I didn't mean to imply that the OP shouldn't first try to run `py -m pip` or `py -3.10 -m pip`. -- https://mail.python.org/mailman/listinfo/python-list
Re: Assistance Request - Issue with Installing 'pip' despite Python 3.10 Installation
On 6/7/23, Thomas Passin via Python-list wrote: > > You have by now seen several responses, and the one most likely to be > helpful is to run pip with > > py -m pip That won't be of any help if pip isn't installed. By default, Python's installer attempts to install pip by running the ensurepip package, but sometimes it fails. It can help to try to manually run ensurepip in the shell. For example: py -m ensurepip --default-pip --upgrade --verbose -- https://mail.python.org/mailman/listinfo/python-list
