From simon.vanbezooijen at student.hu.nl Thu Dec 12 07:50:56 2019 From: simon.vanbezooijen at student.hu.nl (Simon van Bezooijen) Date: Thu, 12 Dec 2019 12:50:56 +0000 Subject: [python-win32] win32com creates unwanted reference to what is already a pointer Message-ID: Hello and good day, I am having trouble with calling a certain COM interface, (a closed-source 32-bit COM interface DLL of a Robot controller) from my Python application. Because so far my entire application is made in Python, it would be a nice bonus if I could call this interface directly from Python too. The win32com library seemed perfect for this task. One of the functions in this interface is the following: BOOL _DataNumReg::SetValuesInt( [in] LONG Index, [in, out] LONG* Value, [in] LONG Count ); With the parameter Value being a pointer to the first element of a C-style array. My idea was to create a C array in Python using the ctypes library, and use the ctypes.addressof() function to get the pointer to the array, and then pass this pointer to the COM interface with win32com. The issue, as you might've guessed is that win32com automatically creates a new pointer to, what already is a pointer. This was already mentioned earlier in 2013, https://mail.python.org/pipermail/python-win32/2013-May/012821.html In which is told that "passing the address of a Python integer object clearly isn't correct - or to put it another way - what exact are you hoping to pass as this parameter?", while for my specific case, passing a Python integer IS correct, as it is already a valid pointer. Because the COM library is closed source I can't change it to expect a pointer to a pointer, so as far as I can come up with, my only solutions left are: A. Write a Win32 DLL wrapper that can call the COM interface. B. Change the win32com library myself to stop creating pointers automatically, or accept a Python list, copy it to a buffer, and send a pointer to that buffer. C. Hope that you might have more advice or information I missed. I already tried changing the .py wrapper generated by makepy.py to hopefully make win32com think that the COM interface requires a VT_UI4/VT_I4 instead of the generated VT_BYREF | VT_I4, but that didn't work, the behavior of win32com creating a pointer to a pointer was still occurring. Nor did changing the [in, out] (3) to [in] (1) in the .py wrapper help. Can you give me any more advice/tricks on how to make the COM interface receive a pointer to a C-array instead of a single value, preferably using win32com? Any information is greatly appreciated. Regards, Simon van Bezooijen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Danesprite at posteo.net Thu Dec 12 21:18:49 2019 From: Danesprite at posteo.net (Dane Finlay) Date: Fri, 13 Dec 2019 13:18:49 +1100 Subject: [python-win32] Win32 SendInput function? Message-ID: Dear all, I've noticed that the Win32 SendInput API function is not currently exposed by any pywin32 module. I was wondering if this function could be exposed in win32api, where the related keybd_event and mouse_event functions are already present. I am aware that SendInput can be used via ctypes, I just think it would be nice if the function could also be used via pywin32. As I see it, the main benefit of using SendInput over the keybd_event and mouse_event functions is that you can pass an array of events for the system to send, rather than one event per call. Microsoft's documentation also states that the aforementioned functions have been superseded by SendInput. The INPUT structures expected by SendInput can also be used to specify timestamps for each keyboard and mouse event. SendInput could be exposed via a wrapper function taking a single list or tuple to be converted to the array of INPUT structures required for the |||pInputs| parameter. The cInputs and cbSize parameters could then be derived from the list internally. Each list element could be a tuple of struct members starting with the INPUT type (0-2). Alternatively, the new function could require each list item to use Python structs defined in win32api or elsewhere. While I do have some experience working with the C-Python API, I don't think I could implement and test this myself because it looks like pywin32's build process is /very/ complicated. Let me know your thoughts! All the best, Dane Finlay -------------- next part -------------- An HTML attachment was scrubbed... URL: