From vano at mail.mipt.ru Sat Jul 22 05:07:17 2017 From: vano at mail.mipt.ru (Ivan Pozdeev) Date: Sat, 22 Jul 2017 12:07:17 +0300 Subject: [python-win32] Sometimes, oleobj is returned instead of dispobj Message-ID: See https://stackoverflow.com/questions/45243545/when-getting-document-object-from-word-application-object-its-members-are-not-f In brief, when getting properties of a "static" object, in some cases, a "dynamic" object is returned even though there is info on its members: | In [112]: w =win32com.client.GetActiveObject('Word.Application') In [113]: w Out[113]: In [114]: w.ActiveDocument Out[114]: In [115]: d=_ In [116]: d._dispobj_ Out[116]: Since this is very inconvenient and there's no earthy need to do so that I can see, maybe a fix is in order? | -- Regards, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Wed Jul 26 19:31:44 2017 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 27 Jul 2017 11:31:44 +1200 Subject: [python-win32] Registering COM servers doesn't work out of the box any more Message-ID: <59792660.3070406@canterbury.ac.nz> I recently tried to install a COM server written in Python and ran into a small problem. The procedure I used was this: 1. Install Python 3 using the standard Windows installer, as Administrator, for All Users, adding Python to the path. 2. pip install pypiwin32 3. Run my script for registering the COM server, which calls win32com.server.register.UseCommandLine. This didn't work, and the reason turned out to be that the InprocServer32 registry was just the filename of the dll, rather than a full pathname. When I changed it to an absolute pathname, the server worked fine. The standard win32com code for server registration seems to be assuming that pythoncom.dll and winctypes.dll have been installed in C:\Windows\System32. However, pip doesn't put them there, and I get the impression that installing all DLLs there is no longer considered best practice. I found an old sourceforge bug report about this: https://sourceforge.net/p/pywin32/bugs/393/ which suggests a one-line change to win32com\server\register.py to address this problem, but it was closed with works-for-me. Am I right that using a relative pathname for InprocServer32 is no longer the right thing to do? Should I reopen this issue? -- Greg From mc at mclaveau.com Thu Jul 27 03:56:19 2017 From: mc at mclaveau.com (mc@mclaveau) Date: Thu, 27 Jul 2017 09:56:19 +0200 Subject: [python-win32] Registering COM servers doesn't work out of the box any more In-Reply-To: <59792660.3070406@canterbury.ac.nz> References: <59792660.3070406@canterbury.ac.nz> Message-ID: <36ac9fca-09de-b9eb-6d12-dfbcb27065b8@mclaveau.com> Hi! When you had installed Python, had you choose "Add to path" (at end of list of install's options)? (sorry for my bad english) @-salutations -- install's Le 27/07/2017 ? 01:31, Greg Ewing a ?crit : > I recently tried to install a COM server written in Python and > ran into a small problem. The procedure I used was this: > > 1. Install Python 3 using the standard Windows installer, as > Administrator, for All Users, adding Python to the path. > > 2. pip install pypiwin32 > > 3. Run my script for registering the COM server, which > calls win32com.server.register.UseCommandLine. > > This didn't work, and the reason turned out to be that the > InprocServer32 registry was just the filename of the dll, > rather than a full pathname. When I changed it to an > absolute pathname, the server worked fine. > > The standard win32com code for server registration seems to > be assuming that pythoncom.dll and winctypes.dll have been > installed in C:\Windows\System32. However, pip doesn't > put them there, and I get the impression that installing > all DLLs there is no longer considered best practice. > > I found an old sourceforge bug report about this: > > https://sourceforge.net/p/pywin32/bugs/393/ > > which suggests a one-line change to win32com\server\register.py > to address this problem, but it was closed with works-for-me. > > Am I right that using a relative pathname for InprocServer32 is > no longer the right thing to do? Should I reopen this issue? > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sign-styloplume.GIF Type: image/gif Size: 9129 bytes Desc: not available URL: