From mhammond at skippinet.com.au Sun Nov 6 02:52:22 2022 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 6 Nov 2022 18:52:22 +1100 Subject: [python-win32] [ANN] pywin32 build 305 released Message-ID: <83eda256-864d-b174-6296-918178fc0ab5@skippinet.com.au> Hi all, I'm happy to announce the release of pywin32 build 305. This release has quite a few changes under the hood, updating our use of older deprecated Python functions etc - so there's some risk of unintended consequences. Another unintended change is that .exe installers are deprecated, because the upstream support for building them is deprecated. Anyone still using them should start moving to pip: python -m pip install --upgrade pywin32 But while .exe files exist: https://github.com/mhammond/pywin32/releases/tag/b305 For initial support (eg, to ask questions about the release etc), please contact this mailing-list (python-win32 at python.org). If you want to report a bug, please do so at https://github.com/mhammond/pywin32/issues As always, thanks to everyone who contributed to this release, both in terms of code and reporting bugs. Cheers, Mark. Changes: * Installation .exe files were deprecated. * @kxrob put a lot of work towards removing use of the deprecated Unicode API so we can build on Python 3.12. This should be largely invisible, but please report any unintended consequences. * odbc: Handle `varchar(max)`/`nvarchar(max)` column sizes (#1954) * win32api.GetTickCount() now returns an unsigned 64bit integer (@kxrob, #1946) * win32pipe.GetNamedPipeHandleState() now takes a 3rd optional param indicating whether the username should be returned, and related constants added. (@kxrob, #1946) * Added win32gui.GetTopWindow() and win32gui.GetAncestor() (@CristiFati, #1928) * Tweaks to how pywintypes searches for DLLs to better support virtualenvs created with --system-site-packages. (@saaketp, #1933) * Added win32event.CreateWaitableTimerExW (#1945, @zariiii9003) * Changes in PARAM handling. Some functions which returned a WPARAM or LPARAM allowed you to return a pointer to a Python buffer object or a PyUnicode. These functions now only accept a Python long to be returned. Note that this DOES NOT apply to functions with accept WPARAM or LPARAM as arguments, only when they are being returned. Impacted functions are `OnNotify` handler, LV_ITEM/TV_ITEM objects, PyIContextMenu3::HandleMenuMsg2, and the result of a WNDPROC/DLGPROC (#1927). * service registration had an overhaul, avoiding a complicated, and ultimately unnecessary "single globally registered service runner" concept. Now, when registering a service, the host pythonservice.exe runner will be copied to `sys.exec_prefix`, along with possibly `pywintypesXX.dll` and run from there. (#1908) * Dropped support for allowing a bytes object to be passed where a COM BSTR is expected - this support was accidental on the path from 2.x->3.x. * win32crypt's PyCERTSTORE.CertCloseStore()'s `Flags` argument has been deprecated as it is likely to crash the process if `CERT_CLOSE_STORE_FORCE_FLAG` is specified. The underlying function is now always called with `CERT_CLOSE_STORE_CHECK_FLAG`, and support for this param will be dropped at some point in the future. * Fix a bug where win32crypt.CryptQueryObject() would return a PyCTL_CONTEXT object instead of a PyCERT_CONTEXT for base64 encoded certificates (#1859) * win32crypt.CryptQueryObject() is now able to return PyCTL_CONTEXT objects. This is technically a breaking change as previously it would return the address in memory of the object, but this address wasn't practically usable, so it's very unlikely anyone relied on this behavior. (#1859) From lukaszj at onet.pl Sun Nov 6 05:17:58 2022 From: lukaszj at onet.pl (=?iso-8859-2?B?o3VrYXN6IEpha3Vib3dza2k=?=) Date: Sun, 06 Nov 2022 11:17:58 +0100 Subject: [python-win32] [ANN] pywin32 build 305 released In-Reply-To: <83eda256-864d-b174-6296-918178fc0ab5@skippinet.com.au> References: <83eda256-864d-b174-6296-918178fc0ab5@skippinet.com.au> Message-ID: Hello, First, thanks for the update. In my pywin32 installation notes I have noted that "pywin32_postinstall.py -install" (not needed now?) and "pyscript.py --register" (to enable ActiveScipting) are required to make everything work correctly . What would be equivalents now? Regards, Lukasz > Hi all, > I'm happy to announce the release of pywin32 build 305. > > This release has quite a few changes under the hood, updating our use of > older deprecated Python functions etc - so there's some risk of > unintended consequences. > > Another unintended change is that .exe installers are deprecated, > because the upstream support for building them is deprecated. Anyone > still using them should start moving to pip: > > python -m pip install --upgrade pywin32 > > But while .exe files exist: > > https://github.com/mhammond/pywin32/releases/tag/b305 > > For initial support (eg, to ask questions about the release etc), please > contact this mailing-list (python-win32 at python.org). If you want to > report a bug, please do so at https://github.com/mhammond/pywin32/issues > > As always, thanks to everyone who contributed to this release, both in > terms of code and reporting bugs. > > Cheers, > > Mark. > > Changes: > > * Installation .exe files were deprecated. > > * @kxrob put a lot of work towards removing use of the deprecated > Unicode API so we can build on Python 3.12. This should be largely > invisible, but please report any unintended consequences. > > * odbc: Handle `varchar(max)`/`nvarchar(max)` column sizes (#1954) > > * win32api.GetTickCount() now returns an unsigned 64bit integer (@kxrob, > #1946) > > * win32pipe.GetNamedPipeHandleState() now takes a 3rd optional param > indicating whether the username should be returned, and related > constants added. (@kxrob, #1946) > > * Added win32gui.GetTopWindow() and win32gui.GetAncestor() (@CristiFati, > #1928) > > * Tweaks to how pywintypes searches for DLLs to better support > virtualenvs created with --system-site-packages. (@saaketp, #1933) > > * Added win32event.CreateWaitableTimerExW (#1945, @zariiii9003) > > * Changes in PARAM handling. Some functions which returned a WPARAM or > LPARAM allowed you to return a pointer to a Python buffer object or a > PyUnicode. These functions now only accept a Python long to be > returned. Note that this DOES NOT apply to functions with accept > WPARAM or LPARAM as arguments, only when they are being returned. > Impacted functions are `OnNotify` handler, LV_ITEM/TV_ITEM objects, > PyIContextMenu3::HandleMenuMsg2, and the result of a WNDPROC/DLGPROC > (#1927). > > * service registration had an overhaul, avoiding a complicated, and > ultimately unnecessary "single globally registered service runner" > concept. Now, when registering a service, the host pythonservice.exe > runner will be copied to `sys.exec_prefix`, along with possibly > `pywintypesXX.dll` and run from there. (#1908) > > * Dropped support for allowing a bytes object to be passed where a COM > BSTR is expected - this support was accidental on the path from > 2.x->3.x. > > * win32crypt's PyCERTSTORE.CertCloseStore()'s `Flags` argument has been > deprecated as it is likely to crash the process if > `CERT_CLOSE_STORE_FORCE_FLAG` is specified. The underlying function is > now always called with `CERT_CLOSE_STORE_CHECK_FLAG`, and support for > this param will be dropped at some point in the future. > > * Fix a bug where win32crypt.CryptQueryObject() would return a > PyCTL_CONTEXT object instead of a PyCERT_CONTEXT for base64 encoded > certificates (#1859) > > * win32crypt.CryptQueryObject() is now able to return PyCTL_CONTEXT > objects. This is technically a breaking change as previously it would > return the address in memory of the object, but this address wasn't > practically usable, so it's very unlikely anyone relied on this > behavior. (#1859) > _______________________________________________ > python-win32 mailing list > python-win32 at python.org > https://mail.python.org/mailman/listinfo/python-win32 -- U?ywam klienta poczty Opera Mail: http://www.opera.com/mail/ From mhammond at skippinet.com.au Sun Nov 6 05:35:54 2022 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 6 Nov 2022 21:35:54 +1100 Subject: [python-win32] [ANN] pywin32 build 305 released In-Reply-To: References: <83eda256-864d-b174-6296-918178fc0ab5@skippinet.com.au> Message-ID: <9ccdecc6-c738-2f1f-597d-696125e4d195@skippinet.com.au> On 6/11/2022 9:17 pm, ?ukasz Jakubowski wrote: > Hello, > > First, thanks for the update. You're welcome :) > > In my pywin32 installation notes I have noted that > "pywin32_postinstall.py -install" (not needed now?) It's still as needed as it ever was. > and "pyscript.py --register" (to enable ActiveScipting) are required > to make everything work correctly . I though the postinstall script did that? > > What would be equivalents now? Not sure what you mean. Are you referring to the .exe situation? The .exe installers run that script automatically, but pip has never offered that capability - so running postinstall remains important for pip installs if you rely on anything being globally installed/registered. I'm just noting .exe files will not exist soon-ish. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gary.Scorby at finastra.com Mon Nov 7 14:42:19 2022 From: Gary.Scorby at finastra.com (Scorby, Gary) Date: Mon, 7 Nov 2022 19:42:19 +0000 Subject: [python-win32] [EXT] [ANN] pywin32 build 305 released In-Reply-To: <83eda256-864d-b174-6296-918178fc0ab5@skippinet.com.au> References: <83eda256-864d-b174-6296-918178fc0ab5@skippinet.com.au> Message-ID: The error I reported in 304 still exists in the interactive window for Python 3.11. Is this scheduled to be fixed? Create the function below. Goes bad when you try to call the function. >>> def biff(x): ... x = x + 1 ... >>> biffFailed to format the args Traceback (most recent call last): File "C:\Python311-32\Lib\site-packages\pythonwin\pywin\idle\CallTips.py", line 133, in get_arg_text argText = inspect.formatargspec(*inspect.getfullargspec(fob)) ^^^^^^^^^^^^^^^^^^^^^ AttributeError: module 'inspect' has no attribute 'formatargspec' ( -----Original Message----- From: python-win32 On Behalf Of Mark Hammond Sent: Sunday, November 6, 2022 12:52 AM To: Python-win32 at python.org Subject: [EXT] [python-win32] [ANN] pywin32 build 305 released Hi all, I'm happy to announce the release of pywin32 build 305. This release has quite a few changes under the hood, updating our use of older deprecated Python functions etc - so there's some risk of unintended consequences. Another unintended change is that .exe installers are deprecated, because the upstream support for building them is deprecated. Anyone still using them should start moving to pip: python -m pip install --upgrade pywin32 But while .exe files exist: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmhammond%2Fpywin32%2Freleases%2Ftag%2Fb305&data=05%7C01%7Cgary.scorby%40finastra.com%7Cbbed47aa19c84221edd208dabfcbe483%7C0b9b90da3fe1457ab340f1b67e1024fb%7C0%7C0%7C638033179682788914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bOvV7xam09Bg4mv%2BdWZaJpTkXUBZR17CQtopv1r0Iyg%3D&reserved=0 For initial support (eg, to ask questions about the release etc), please contact this mailing-list (python-win32 at python.org). If you want to report a bug, please do so at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmhammond%2Fpywin32%2Fissues&data=05%7C01%7Cgary.scorby%40finastra.com%7Cbbed47aa19c84221edd208dabfcbe483%7C0b9b90da3fe1457ab340f1b67e1024fb%7C0%7C0%7C638033179682788914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=YUvKzL024GAvhS7Vz5qx8ElfZC%2FB8I%2FO1S56jOoONR0%3D&reserved=0 As always, thanks to everyone who contributed to this release, both in terms of code and reporting bugs. Cheers, Mark. Changes: * Installation .exe files were deprecated. * @kxrob put a lot of work towards removing use of the deprecated Unicode API so we can build on Python 3.12. This should be largely invisible, but please report any unintended consequences. * odbc: Handle `varchar(max)`/`nvarchar(max)` column sizes (#1954) * win32api.GetTickCount() now returns an unsigned 64bit integer (@kxrob, #1946) * win32pipe.GetNamedPipeHandleState() now takes a 3rd optional param indicating whether the username should be returned, and related constants added. (@kxrob, #1946) * Added win32gui.GetTopWindow() and win32gui.GetAncestor() (@CristiFati, #1928) * Tweaks to how pywintypes searches for DLLs to better support virtualenvs created with --system-site-packages. (@saaketp, #1933) * Added win32event.CreateWaitableTimerExW (#1945, @zariiii9003) * Changes in PARAM handling. Some functions which returned a WPARAM or LPARAM allowed you to return a pointer to a Python buffer object or a PyUnicode. These functions now only accept a Python long to be returned. Note that this DOES NOT apply to functions with accept WPARAM or LPARAM as arguments, only when they are being returned. Impacted functions are `OnNotify` handler, LV_ITEM/TV_ITEM objects, PyIContextMenu3::HandleMenuMsg2, and the result of a WNDPROC/DLGPROC (#1927). * service registration had an overhaul, avoiding a complicated, and ultimately unnecessary "single globally registered service runner" concept. Now, when registering a service, the host pythonservice.exe runner will be copied to `sys.exec_prefix`, along with possibly `pywintypesXX.dll` and run from there. (#1908) * Dropped support for allowing a bytes object to be passed where a COM BSTR is expected - this support was accidental on the path from 2.x->3.x. * win32crypt's PyCERTSTORE.CertCloseStore()'s `Flags` argument has been deprecated as it is likely to crash the process if `CERT_CLOSE_STORE_FORCE_FLAG` is specified. The underlying function is now always called with `CERT_CLOSE_STORE_CHECK_FLAG`, and support for this param will be dropped at some point in the future. * Fix a bug where win32crypt.CryptQueryObject() would return a PyCTL_CONTEXT object instead of a PyCERT_CONTEXT for base64 encoded certificates (#1859) * win32crypt.CryptQueryObject() is now able to return PyCTL_CONTEXT objects. This is technically a breaking change as previously it would return the address in memory of the object, but this address wasn't practically usable, so it's very unlikely anyone relied on this behavior. (#1859) _______________________________________________ python-win32 mailing list python-win32 at python.org https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-win32&data=05%7C01%7Cgary.scorby%40finastra.com%7Cbbed47aa19c84221edd208dabfcbe483%7C0b9b90da3fe1457ab340f1b67e1024fb%7C0%7C0%7C638033179682788914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2eOpX%2F7r3b%2Fb1hjxV%2BKydecNNKlzlIfWHfBHGkHF1lU%3D&reserved=0 "FINASTRA" is the trade name of the FINASTRA group of companies. This email and any attachments have been scanned for known viruses using multiple scanners. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and FINASTRA. Please refer to the executed contract between you and the relevant member of the FINASTRA group for the identity of the contracting party with which you are dealing. From afnetpf at gmail.com Mon Nov 7 16:20:14 2022 From: afnetpf at gmail.com (Antoine FINET) Date: Mon, 7 Nov 2022 11:20:14 -1000 Subject: [python-win32] Windows printing with the use of Device Context Message-ID: Hello, I would like to print information at the correct coordinates on a pre printed form. If I understood correctly my readings, the coordinates given to a "TextOut" Printer Device Context depend on the resolution of the printer. Am I right? If it depends on resolution, how can I query the printer to know the resolution and calculate the correct coordinates? I don't have another printer to test but my underlying question is : does the coordinates depend on the printer? Kind regards, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: From timr at probo.com Mon Nov 7 18:49:35 2022 From: timr at probo.com (Tim Roberts) Date: Mon, 7 Nov 2022 15:49:35 -0800 Subject: [python-win32] Windows printing with the use of Device Context In-Reply-To: References: Message-ID: <75e71dff-ac5a-edb8-5aa6-206a088ce553@probo.com> Antoine FINET wrote: > > I would like to print information at the correct coordinates on a pre > printed form. > > If I understood?correctly my readings, the coordinates given to a > "TextOut" Printer Device Context depend on the resolution of the > printer. Am I right? Yes, but the exact same thing is true of on-screen windows.? You can use GetDeviceCaps(hdc, LOGPIXELSX) to get the pixels per inch resolution.? There's also a LOGPIXELSY, but unless you have a 40-year-old graphics adapter, they are the same.? The DeviceCapabilities API returns a DEVMODE structure that has detailed information about the printer. > I don't have another printer to test but my underlying question is : > does the coordinates depend on the printer? Absolutely, yes.? Modern printers can be 300, 600, or 1200 dots per inch.? Label printers can use even wilder values. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3428 bytes Desc: S/MIME Cryptographic Signature URL: From Neil.Kenig at modahealth.com Mon Nov 7 20:25:57 2022 From: Neil.Kenig at modahealth.com (Neil Kenig) Date: Tue, 8 Nov 2022 01:25:57 +0000 Subject: [python-win32] Windows printing with the use of Device Context In-Reply-To: <75e71dff-ac5a-edb8-5aa6-206a088ce553@probo.com> References: <75e71dff-ac5a-edb8-5aa6-206a088ce553@probo.com> Message-ID: You may want to try https://pypi.org/project/PyMuPDF/. It's relatively easy to create a blank PDF and then insert text of a given font and size at precise locations on the page. PDF files use points (1/72nd of an inch) for both font sizes and location on a page and will print properly regardless of the printer's resolution (assuming the stock size is the same, e.g. US Letter or A4). You can then print the PDF and if the preprinted stock is loaded into the printer, you should get the desired result. Neil Kenig Print Software Engineer (Document Services) -----Original Message----- From: python-win32 On Behalf Of Tim Roberts Sent: Monday, November 7, 2022 3:50 PM To: python-win32 at python.org Subject: Re: [python-win32] Windows printing with the use of Device Context EXTERNAL MESSAGE - TREAT LINKS/FILES WITH CARE Antoine FINET wrote: > > I would like to print information at the correct coordinates on a pre > printed form. > > If I understood correctly my readings, the coordinates given to a > "TextOut" Printer Device Context depend on the resolution of the > printer. Am I right? Yes, but the exact same thing is true of on-screen windows. You can use GetDeviceCaps(hdc, LOGPIXELSX) to get the pixels per inch resolution. There's also a LOGPIXELSY, but unless you have a 40-year-old graphics adapter, they are the same. The DeviceCapabilities API returns a DEVMODE structure that has detailed information about the printer. > I don't have another printer to test but my underlying question is : > does the coordinates depend on the printer? Absolutely, yes. Modern printers can be 300, 600, or 1200 dots per inch. Label printers can use even wilder values. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From timr at probo.com Tue Nov 8 02:04:07 2022 From: timr at probo.com (Tim Roberts) Date: Mon, 7 Nov 2022 23:04:07 -0800 Subject: [python-win32] Windows printing with the use of Device Context In-Reply-To: References: <75e71dff-ac5a-edb8-5aa6-206a088ce553@probo.com> Message-ID: <3d2a8c7f-e017-7b83-8d5f-d8d2b6c8933e@probo.com> On 11/7/22 5:25 PM, Neil Kenig wrote: > You may want to try https://pypi.org/project/PyMuPDF/. It's relatively easy to create a blank PDF and then insert text of a given font and size at precise locations on the page. PDF files use points (1/72nd of an inch) for both font sizes and location on a page and will print properly regardless of the printer's resolution (assuming the stock size is the same, e.g. US Letter or A4). You can then print the PDF and if the preprinted stock is loaded into the printer, you should get the desired result. This is excellent advice, and it has the huge advantage of being cross-platform.? The Windows printing API is, in my expert opinion, peculiar and finicky. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From brian at brian3johnson.me Tue Nov 8 10:53:19 2022 From: brian at brian3johnson.me (Brian Johnson) Date: Tue, 08 Nov 2022 15:53:19 -0000 Subject: [python-win32] Welcome to the "python-win32" mailing list (Digest mode) In-Reply-To: References: Message-ID: <31fcf032-1fee-4985-8942-a2c1473fc2f9@me.com> Hi python-win32 community.I am trying to get this toy COM server (code is below) to work. It is the sample code from "Python Programming for Win32" and adapted for python 3.10. When I test it using VBA in Word, I get this error:Run-time error '429':ActiveX component can't create objectI don't know if I am missing one a required _reg_param_ that is needed for Win10.Is there is an extra step I need to take to register/run the COM server?I don't know if win32com.server.localserver.serve [] is necessary.Does the class need an?__init__ method to do something?I appreciate any help or insight into getting this to work. Thank you!Sincerely, BrianContext:Windows 10, python 3.10, Office 365, running python code as AdministratorI have verified the python class works in python only.I tried registering/unregistering using both options shown below. Both appear to work - no error messages. I can find info about the COM Server using Regedit.I tried the --debug flag, but it didn't provide any verbosity.I'm learning COM, but the info about it is sparse and generally very abstract.Python script, SimpleCOMServer.py:"""A sample COM server - almost as small as they come."""# import sysimport pythoncomimport win32com.server.registerclass PythonUtilities:? ? """We expose a simple method in a Python COM object."""? ? _reg_clsctx_ = pythoncom.CLSCTX_LOCAL_SERVER? ? _public_methods_ = ["SplitString"]? ? _reg_progid_ = "PythonDemos.Utilities"? ? _reg_desc_ = "PythonDemos Test COM Server"? ? # NEVER copy the following ID? ? # Use "print(pythoncom.CreateGUID())" to made a new on.? ? _reg_clsid_ = "{819E8336-00B5-4025-979A-46EE1EF411B7}"? ? # for Python 3.7+? ? # https://stackoverflow.com/questions/1054849/consuming-python-com-server-from-net? ? _reg_verprogid_ = "PythonDemos.Utilities.1"? ? # .? ? _reg_class_spec_ = "SimpleCOMServer.PythonUtilities"? ? def SplitString(self, val, separator=None):? ? ? ? """Split a string by a separator."""? ? ? ? # if separator is not None:? ? ? ? # ? ? return val.split(separator)? ? ? ? # else:? ? ? ? # ? ? return val.split()? ? ? ? if separator is not None:? ? ? ? ? ? return str(val).split(str(separator))? ? ? ? else:? ? ? ? ? ? return str(val).split()# Add code so that when this script is run by python e.e, it self-registers.if __name__ == "__main__":? ? print("Registering COM server...")? ? win32com.server.register.UseCommandLine(PythonUtilities)? ? # if "--register" in sys.argv[1:] or "--unregister" in sys.argv[1:]:? ? # ? ? win32com.server.register.UseCommandLine(PythonUtilities)? ? # else:? ? # ? ? # start the server.? ? # ? ? from win32com.server.localserver import serve? ? # ? ? serve(["{819E8336-00B5-4025-979A-46EE1EF411B7}"])Word VBA macro:Sub TestPython() ??? Dim PythonUtils As Object??? Set PythonUtils = CreateObject("PythonDemos.Utilities")??? response = PythonUtils.SplitString("Hello from VB")??? For Each Item In response??????? MsgBox Item??? NextEnd Sub -------------- next part -------------- An HTML attachment was scrubbed... URL: From skippy.hammond at gmail.com Tue Nov 8 17:49:10 2022 From: skippy.hammond at gmail.com (Mark Hammond) Date: Wed, 9 Nov 2022 09:49:10 +1100 Subject: [python-win32] Welcome to the "python-win32" mailing list (Digest mode) In-Reply-To: <31fcf032-1fee-4985-8942-a2c1473fc2f9@me.com> References: <31fcf032-1fee-4985-8942-a2c1473fc2f9@me.com> Message-ID: <786b01fa-6bd4-164e-bfcd-986f46a46705@gmail.com> pythoncom.CLSCTX_LOCAL_SERVER means this COM object will be hosted by python.exe - so COM/office is going to look up the registry to get a command-line to execute. As written, that will just re-register the COM server - so yes, you do want that `localserver.serve()`. The default of CLSCTX_INPROC_SERVER generally doesn't need an explicit serve() as python.exe isn't used - the DLLs are loaded directly into office - but that probably isn't going to help in a concrete way (ie, the underlying problem would probably exist in both cases) Assuming it still fails with that: it might be that this command is failing for reasons - eg, if you installed pywin32 via pip and didn't run the pywin32_postinstall script I can imagine things going wrong. The .exe installer runs that for you though. You mention you found the entry in the registry - does executing that command in a "clean" environment (ie, without any special environment variables etc, from a directory unrelated to python - ie, trying to emulate the same environment office itself runs in) work OK? If it fails importing modules etc, that's probably the same failure when COM tries to start it. You mention "running code as Administrator" - is Office and this registration code running as the exact same user? I've currently no environments with Office available, so can't really test at the moment. HTH, Mark On 9/11/2022 2:53 am, Brian Johnson wrote: > Hi python-win32 community. > > I am trying to get this toy COM server (code is below) to work. It is > the sample code from /"Python Programming for Win32"/ and adapted for > python 3.10. When I test it using VBA in Word, I get this error: > Run-time error '429': > ActiveX component can't create object > > * I don't know if I am missing one a required _reg_param_ that is > needed for Win10. > * Is there is an extra step I need to take to register/run the COM server? > * I don't know if win32com.server.localserver.serve [] is necessary. > * Does the class need an __init__ method to do something? > > > I appreciate any help or insight into getting this to work. Thank you! > Sincerely, Brian > > *Context*: > > * Windows 10, python 3.10, Office 365, running python code as > Administrator > * I have verified the python class works in python only. > * I tried registering/unregistering using both options shown below. > Both appear to work - no error messages. I can find info about the > COM Server using Regedit. > * I tried the --debug flag, but it didn't provide any verbosity. > * I'm learning COM, but the info about it is sparse and generally very > abstract. > > > *Python script, SimpleCOMServer.py:* > """A sample COM server - almost as small as they come.""" > # import sys > > importpythoncom > importwin32com.server.register > > > classPythonUtilities: > """We expose a simple method in a Python COM object.""" > > _reg_clsctx_= pythoncom.CLSCTX_LOCAL_SERVER > _public_methods_= ["SplitString"] > _reg_progid_= "PythonDemos.Utilities" > _reg_desc_= "PythonDemos Test COM Server" > # NEVER copy the following ID > # Use "print(pythoncom.CreateGUID())" to made a new on. > _reg_clsid_= "{819E8336-00B5-4025-979A-46EE1EF411B7}" > > # for Python 3.7+ > # > https://stackoverflow.com/questions/1054849/consuming-python-com-server-from-net > _reg_verprogid_= "PythonDemos.Utilities.1" > # . > _reg_class_spec_= "SimpleCOMServer.PythonUtilities" > > defSplitString(self, val, separator=None): > """Split a string by a separator.""" > # if separator is not None: > # ? ? return val.split(separator) > # else: > # ? ? return val.split() > > ifseparatorisnotNone: > returnstr(val).split(str(separator)) > else: > returnstr(val).split() > > > # Add code so that when this script is run by python e.e, it self-registers. > if__name__== "__main__": > print("Registering COM server...") > win32com.server.register.UseCommandLine(PythonUtilities) > > # if "--register" in sys.argv[1:] or "--unregister" in sys.argv[1:]: > # ? ? win32com.server.register.UseCommandLine(PythonUtilities) > > # else: > # ? ? # start the server. > # ? ? from win32com.server.localserver import serve > > # ? ? serve(["{819E8336-00B5-4025-979A-46EE1EF411B7}"]) > > *Word VBA macro:* > Sub TestPython() > ??? Dim PythonUtils As Object > ??? Set PythonUtils = CreateObject("PythonDemos.Utilities") > ??? response = PythonUtils.SplitString("Hello from VB") > ??? For Each Item In response > ??????? MsgBox Item > ??? Next > End Sub > > > _______________________________________________ > python-win32 mailing list > python-win32 at python.org > https://mail.python.org/mailman/listinfo/python-win32 From wlfraed at ix.netcom.com Tue Nov 8 20:50:24 2022 From: wlfraed at ix.netcom.com (Dennis Lee Bieber) Date: Tue, 08 Nov 2022 20:50:24 -0500 Subject: [python-win32] Welcome to the "python-win32" mailing list (Digest mode) References: <31fcf032-1fee-4985-8942-a2c1473fc2f9@me.com> Message-ID: On Tue, 08 Nov 2022 15:53:19 -0000, Brian Johnson declaimed the following: >Hi python-win32 community.I am trying to get this toy COM server (code is below) to work. It is the sample code from "Python Programming for Win32" and adapted for python 3.10. When I test it using VBA in Word, I get this error:Run-time error '429':ActiveX component can't create objectI don't know if I am missing one a required _reg_param_ that is needed for Win10.Is there is an extra step I need to take to register/run the COM server?I don't know if win32com.server.localserver.serve [] is necessary.Does the class need an?__init__ method to do something?I appreciate any help or insight into getting this to work. Thank you!Sincerely, BrianContext:Windows 10, python 3.10, Office 365, running python code as AdministratorI have verified the python class works in python only.I tried registering/unregistering using both options shown below. Both appear to work - no error messages. I can find info about the COM Server using Regedit.I tried the --debug flag, but it didn't provide any >verbosity.I'm learning COM, but the info about it is sparse and generally very abstract.Python script, SimpleCOMServer.py:"""A sample COM server - almost as small as they come."""# import sysimport pythoncomimport win32com.server.registerclass PythonUtilities:? ? """We expose a simple method in a Python COM object."""? ? _reg_clsctx_ = pythoncom.CLSCTX_LOCAL_SERVER? ? _public_methods_ = ["SplitString"]? ? _reg_progid_ = "PythonDemos.Utilities"? ? _reg_desc_ = "PythonDemos Test COM Server"? ? # NEVER copy the following ID? ? # Use "print(pythoncom.CreateGUID())" to made a new on.? ? _reg_clsid_ = "{819E8336-00B5-4025-979A-46EE1EF411B7}"? ? # for Python 3.7+? ? # https://stackoverflow.com/questions/1054849/consuming-python-com-server-from-net? ? _reg_verprogid_ = "PythonDemos.Utilities.1"? ? # .? ? _reg_class_spec_ = "SimpleCOMServer.PythonUtilities"? ? def SplitString(self, val, separator=None):? ? ? ? """Split a string by a separator."""? ? ? ? # if separator is >not None:? ? ? ? # ? ? return val.split(separator)? ? ? ? # else:? ? ? ? # ? ? return val.split()? ? ? ? if separator is not None:? ? ? ? ? ? return str(val).split(str(separator))? ? ? ? else:? ? ? ? ? ? return str(val).split()# Add code so that when this script is run by python e.e, it self-registers.if __name__ == "__main__":? ? print("Registering COM server...")? ? win32com.server.register.UseCommandLine(PythonUtilities)? ? # if "--register" in sys.argv[1:] or "--unregister" in sys.argv[1:]:? ? # ? ? win32com.server.register.UseCommandLine(PythonUtilities)? ? # else:? ? # ? ? # start the server.? ? # ? ? from win32com.server.localserver import serve? ? # ? ? serve(["{819E8336-00B5-4025-979A-46EE1EF411B7}"])Word VBA macro:Sub TestPython() ??? Dim PythonUtils As Object??? Set PythonUtils = CreateObject("PythonDemos.Utilities")??? response = PythonUtils.SplitString("Hello from VB")??? For Each Item In response??????? MsgBox Item??? NextEnd Sub (UGH! what type of line endings is your client sending?) 32-bit or 64-bit? Office 365 may be 32-bit applications, and will need a 32-bit Python COM server. -- Wulfraed Dennis Lee Bieber AF6VN wlfraed at ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ From afnetpf at gmail.com Wed Nov 9 16:44:46 2022 From: afnetpf at gmail.com (Antoine FINET) Date: Wed, 9 Nov 2022 11:44:46 -1000 Subject: [python-win32] Windows printing with the use of DeviceContext In-Reply-To: References: Message-ID: Thank you very much Neil Kenig, the PyMuPDF library will completely meet my needs and seems super easy to use. In 15 minutes of tests, I managed to process one of the fields and the management of the step between the boxes (one letter per box). Many thanks also to you Tim Roberts for the initial answer as well as co-opting Neil's answer. Going through PDF rather than attacking the Windows printing API will probably save me a lot of time as well as a few gray hairs (more). Thank you again for your participation and your answers to my question, it's so nice. Kind regards, Antoine Le mar. 8 nov. 2022 ? 07:10, a ?crit : > Send python-win32 mailing list submissions to > python-win32 at python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/python-win32 > or, via email, send a message with subject or body 'help' to > python-win32-request at python.org > > You can reach the person managing the list at > python-win32-owner at python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of python-win32 digest..." > > > Today's Topics: > > 1. Re: Windows printing with the use of Device Context (Neil Kenig) > 2. Re: Windows printing with the use of Device Context (Tim Roberts) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 8 Nov 2022 01:25:57 +0000 > From: Neil Kenig > To: "python-win32 at python.org" > Subject: Re: [python-win32] Windows printing with the use of Device > Context > Message-ID: > < > DM8PR08MB7494EA822D5915BBCE8F9785E03F9 at DM8PR08MB7494.namprd08.prod.outlook.com > > > > Content-Type: text/plain; charset="utf-8" > > You may want to try https://pypi.org/project/PyMuPDF/. It's relatively > easy to create a blank PDF and then insert text of a given font and size at > precise locations on the page. PDF files use points (1/72nd of an inch) > for both font sizes and location on a page and will print properly > regardless of the printer's resolution (assuming the stock size is the > same, e.g. US Letter or A4). You can then print the PDF and if the > preprinted stock is loaded into the printer, you should get the desired > result. > > Neil Kenig > Print Software Engineer (Document Services) > > -----Original Message----- > From: python-win32 modahealth.com at python.org> On Behalf Of Tim Roberts > Sent: Monday, November 7, 2022 3:50 PM > To: python-win32 at python.org > Subject: Re: [python-win32] Windows printing with the use of Device Context > > EXTERNAL MESSAGE - TREAT LINKS/FILES WITH CARE > > Antoine FINET wrote: > > > > I would like to print information at the correct coordinates on a pre > > printed form. > > > > If I understood correctly my readings, the coordinates given to a > > "TextOut" Printer Device Context depend on the resolution of the > > printer. Am I right? > > Yes, but the exact same thing is true of on-screen windows. You can use > GetDeviceCaps(hdc, LOGPIXELSX) to get the pixels per inch resolution. > There's also a LOGPIXELSY, but unless you have a 40-year-old graphics > adapter, they are the same. The DeviceCapabilities API returns a DEVMODE > structure that has detailed information about the printer. > > > > I don't have another printer to test but my underlying question is : > > does the coordinates depend on the printer? > > Absolutely, yes. Modern printers can be 300, 600, or 1200 dots per inch. > Label printers can use even wilder values. > > -- > Tim Roberts, timr at probo.com > Providenza & Boekelheide, Inc. > > > ------------------------------ > > Message: 2 > Date: Mon, 7 Nov 2022 23:04:07 -0800 > From: Tim Roberts > To: "python-win32 at python.org" > Subject: Re: [python-win32] Windows printing with the use of Device > Context > Message-ID: <3d2a8c7f-e017-7b83-8d5f-d8d2b6c8933e at probo.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 11/7/22 5:25 PM, Neil Kenig wrote: > > > You may want to try https://pypi.org/project/PyMuPDF/. It's > relatively easy to create a blank PDF and then insert text of a given font > and size at precise locations on the page. PDF files use points (1/72nd of > an inch) for both font sizes and location on a page and will print properly > regardless of the printer's resolution (assuming the stock size is the > same, e.g. US Letter or A4). You can then print the PDF and if the > preprinted stock is loaded into the printer, you should get the desired > result. > > This is excellent advice, and it has the huge advantage of being > cross-platform.? The Windows printing API is, in my expert opinion, > peculiar and finicky. > > -- > Tim Roberts, timr at probo.com > Providenza & Boekelheide, Inc. > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > python-win32 mailing list > python-win32 at python.org > https://mail.python.org/mailman/listinfo/python-win32 > > > ------------------------------ > > End of python-win32 Digest, Vol 233, Issue 3 > ******************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From toddfiske at gmail.com Wed Nov 9 19:50:14 2022 From: toddfiske at gmail.com (Todd Fiske) Date: Wed, 9 Nov 2022 19:50:14 -0500 Subject: [python-win32] Windows printing with the use of DeviceContext In-Reply-To: References: Message-ID: Hi Antoine, If you ever do want to use the Windows printing API, there is a library called MSWinPrint that provides a wrapper that makes it easier to use and understand. https://pypi.org/project/MSWinPrint/ But I also agree with the others that the PDF option is more general and practical. I've used ReportLab for generating PDFs but will give the PyMuPDF library a try too. https://www.reportlab.com/ Todd On 11/9/22, Antoine FINET wrote: > Thank you very much Neil Kenig, the PyMuPDF library will completely meet my > needs and seems super easy to use. > In 15 minutes of tests, I managed to process one of the fields and the > management of the step between the boxes (one letter per box). > > Many thanks also to you Tim Roberts for the initial answer as well as > co-opting Neil's answer. > > Going through PDF rather than attacking the Windows printing API will > probably save me a lot of time as well as a few gray hairs (more). > > Thank you again for your participation and your answers to my question, > it's so nice. > > Kind regards, > > Antoine From paul.newton.hudl at gmail.com Tue Nov 15 16:56:39 2022 From: paul.newton.hudl at gmail.com (Paul Newton) Date: Tue, 15 Nov 2022 21:56:39 +0000 Subject: [python-win32] Looking for PyWin32 for Python 2.3.1 Message-ID: Hi Please don't ask why I would want to install such an old version of Python, but I have Python 2.3.1 installed anyway.? Now I am looking for the corresponding PyWin32 install files.? I believe they are available here https://sourceforge.net/projects/pywin32/files/pywin32/ or here https://www.lfd.uci.edu/~gohlke/pythonlibs/ but I cannot fathom exactly what I need to download or what to do with the download. I am sure somebody can help ... Thanks Paul Newton From skippy.hammond at gmail.com Tue Nov 15 17:06:23 2022 From: skippy.hammond at gmail.com (Mark Hammond) Date: Wed, 16 Nov 2022 09:06:23 +1100 Subject: [python-win32] Looking for PyWin32 for Python 2.3.1 In-Reply-To: References: Message-ID: Looks like the last to support 2.3 was build 218 and can be found at https://sourceforge.net/projects/pywin32/files/pywin32/Build%20218/ Cheers, Mark On 16/11/2022 8:56 am, Paul Newton wrote: > Hi > > Please don't ask why I would want to install such an old version of > Python, but I have Python 2.3.1 installed anyway.? Now I am looking for > the corresponding PyWin32 install files.? I believe they are available > here https://sourceforge.net/projects/pywin32/files/pywin32/ or here > https://www.lfd.uci.edu/~gohlke/pythonlibs/ but I cannot fathom exactly > what I need to download or what to do with the download. > > I am sure somebody can help ... Thanks > > Paul Newton > > _______________________________________________ > python-win32 mailing list > python-win32 at python.org > https://mail.python.org/mailman/listinfo/python-win32 From timr at probo.com Tue Nov 15 18:47:32 2022 From: timr at probo.com (Tim Roberts) Date: Tue, 15 Nov 2022 15:47:32 -0800 Subject: [python-win32] Looking for PyWin32 for Python 2.3.1 In-Reply-To: References: Message-ID: <795e4b30-a707-f08a-cf3d-3a7401c800a6@probo.com> Paul Newton wrote: > > Please don't ask why I would want to install such an old version of > Python, but I have Python 2.3.1 installed anyway.? Now I am looking > for the corresponding PyWin32 install files.? I believe they are > available here https://sourceforge.net/projects/pywin32/files/pywin32/ > or here https://www.lfd.uci.edu/~gohlke/pythonlibs/ but I cannot > fathom exactly what I need to download or what to do with the download. If you click on version 200, for example, you'll see there is a file "pywin32-200.win32-py2.3.exe".? Download it and execute it. It will install itself in the proper location, which is stored in the registry. And, as a rule, it's considered rude in a list like this to say "please don't ask why".? It may not be the case for you, but very often we get very specific off-the-wall questions that arose only because the asker took a wrong turn several steps ago.? By learning more about the "why", we can offer a much better overall experience. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3428 bytes Desc: S/MIME Cryptographic Signature URL: From timr at probo.com Tue Nov 15 19:27:09 2022 From: timr at probo.com (Tim Roberts) Date: Tue, 15 Nov 2022 16:27:09 -0800 Subject: [python-win32] Looking for PyWin32 for Python 2.3.1 In-Reply-To: References: <795e4b30-a707-f08a-cf3d-3a7401c800a6@probo.com> Message-ID: Paul Newton wrote: > > Thanks for your reply Tim and my apologies - I did not mean to be rude > and I take your point.? I made an earlier mistake, my Python version > is 2.1.3 not 2.3.1 but I am looking at doing an install using > pywin32-200.zip. You don't really want to build these from source.? It does look like that file is missing, but even if it weren't, that is a project file for Visual Studio 2003.? You almost certainly do not have a copy of Visual Studio 2003 hanging around, and they typically don't build with newer compilers.? Just use the executable installer. The DSP is present in the 201.1 zip.? I don't know whether that builds for Python 2.1 or not. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3428 bytes Desc: S/MIME Cryptographic Signature URL: From bkline at rksystems.com Mon Nov 28 16:12:01 2022 From: bkline at rksystems.com (Bob Kline) Date: Mon, 28 Nov 2022 16:12:01 -0500 Subject: [python-win32] Memory access violation using pywin32 as WSH Message-ID: We've got a project we've supported for many years which involves using XMetaL (a commercial XML editor) customized with macros written in JScript. The vendor claims that the scripting "can use any scripting language that conforms to the Microsoft Scripting Language Interface." Since JScript is much more restricted in what it can do, and since our team is much more familiar with Python than with JScript, we would like to switch to Python for our scripts. However, a dirt-simple proof of concept fails with a memory access violation. We created a macro file with a single macro which displays an alert box with a simple string. If the lang attribute for the macro element (the macros are stored in an XML file, with the code for each macro stored in a MACRO element) is set to "JScript" the macro can be run an unlimited number of times without any problems. If the lang attribute is set to "Python" (the macro is so simple that the syntax is identical for the two languages) the macro can be run once without any apparent problems, as long as you close the XMetaL application and launch it again before the next run of the macro. However, if XMetaL is launched and the macro is run twice or more before shutting down the application, it is no longer possible to launch it again until the user logs off the machine and logs back in. When the user logs off, a dialog box appears reporting a memory access violation ("xmetal.exe - Application Error. The instruction at referenced memory at . The memory could not be read."). To be clear ? the macro does what it's supposed to (display a dialog box with a string) each time it is run. The problem only manifests itself when trying to launch the application again or when logging off the machine. Interestingly, when the application is in this "I can't be launched again and I will report a failure at logoff time" state there is no evidence that the process is still hanging around. It doesn't show up in Process Manager, for example. But it seems clear from the title bar of the error dialog that it's coming from the application. At this point I don't know for sure whether the problem is caused by something the XMetaL application is doing wrong (and presumably differently than what it does when the scripting engine is JScript) or by something that pyscript.py is doing. I am aware that I could easily get caught between two projects, each of which claims that the failure must be caused by the other. I have reported the problem to the XMetaL support team and I am waiting to hear what they have to say. I'm hoping that the data point of "one macro invocation succeeds, two macro invocations fail" provides a useful clue. What would be helpful from the pywin32 team's side would be any suggestions you might have for how I might go about tracking what's going on, presumably by hacking pyscript.py and/or framework.py in win32comext/axscript/client to add logging to the file system. Perhaps, for example, I'll be able to find something which is supposed to get released at application shutdown time but which isn't. I'm still trying to absorb the axscript/client code and wrap my head around what the processing flow is and what the different classes are doing. Any clues for where to start? Anyone else run into similar memory access violations using Python as a Windows Scripting Host? Many thanks! -- Bob Kline https://www.rksystems.com mailto:bkline at rksystems.com From bkline at rksystems.com Mon Nov 28 18:38:33 2022 From: bkline at rksystems.com (Bob Kline) Date: Mon, 28 Nov 2022 18:38:33 -0500 Subject: [python-win32] Memory access violation using pywin32 as WSH In-Reply-To: References: Message-ID: On Mon, Nov 28, 2022 at 4:12 PM Bob Kline wrote: > .... > Perhaps, for example, I'll be able to find something which is supposed > to get released at application shutdown time but which isn't. .... I've added some debug logging to the top of most methods in pyscript.py, mostly just announcing that the method was invoked. I was a little surprised to find that for each invocation of the macro seven instances of the ScriptItem class were created, instead of just one. So clearly I have yet to figure out exactly what a ScriptItem is. The really interesting thing is that if I invoke the macro once for a given run of the host application, the ScriptItem.Close() method is called seven times, matching the seven times the ScriptItem constructor is hit. However, if the macro is invoked twice for a run of the host application, I still see only seven calls to ScriptItem.Close(), even though there are now fourteen calls to the ScriptItem constructor. Can I assume that this is a problem? Sure smells like one. Where does the responsibility for calling the Close() method ultimately fall? -- Bob Kline https://www.rksystems.com mailto:bkline at rksystems.com From mhammond at skippinet.com.au Mon Nov 28 19:24:19 2022 From: mhammond at skippinet.com.au (Mark Hammond) Date: Tue, 29 Nov 2022 11:24:19 +1100 Subject: [python-win32] Memory access violation using pywin32 as WSH In-Reply-To: References: Message-ID: It's been years since I've looked at this, but IIRC, a "script item" is whatever the host wants it to be - eg, in a HTML page, it would be anything between tags. I believe WSH would just use one for a script file. The Close() method will generally be called by the host - not calling this could cause a memory leak (particularly if the COM reference count also didn't hit zero), but it shouldn't cause a crash. That said though, I certainly would not rule out a bug in pywin32's implementation. The absolute best thing for us would be to reproduce the crash in the test code at https://github.com/mhammond/pywin32/tree/main/com/win32comext/axscript/test. The next best thing would probably be a stack trace of the crash. Cheers, Mark On 29/11/2022 10:38 am, Bob Kline wrote: > On Mon, Nov 28, 2022 at 4:12 PM Bob Kline wrote: >> .... >> Perhaps, for example, I'll be able to find something which is supposed >> to get released at application shutdown time but which isn't. .... > > I've added some debug logging to the top of most methods in > pyscript.py, mostly just announcing that the method was invoked. I was > a little surprised to find that for each invocation of the macro seven > instances of the ScriptItem class were created, instead of just one. > So clearly I have yet to figure out exactly what a ScriptItem is. The > really interesting thing is that if I invoke the macro once for a > given run of the host application, the ScriptItem.Close() method is > called seven times, matching the seven times the ScriptItem > constructor is hit. However, if the macro is invoked twice for a run > of the host application, I still see only seven calls to > ScriptItem.Close(), even though there are now fourteen calls to the > ScriptItem constructor. Can I assume that this is a problem? Sure > smells like one. Where does the responsibility for calling the Close() > method ultimately fall? > From bkline at rksystems.com Tue Nov 29 06:16:16 2022 From: bkline at rksystems.com (Bob Kline) Date: Tue, 29 Nov 2022 06:16:16 -0500 Subject: [python-win32] Memory access violation using pywin32 as WSH In-Reply-To: References: Message-ID: On Mon, Nov 28, 2022 at 7:24 PM Mark Hammond wrote: > ... > The absolute best thing for us would be to reproduce the crash in the > test code at > https://github.com/mhammond/pywin32/tree/main/com/win32comext/axscript/test. I presume that would depend on getting the vendor to open the kimono and reveal which calls to the scripting engine the application is making at what times. One handicap I'm dealing with is the fact that I don't have a good understanding of what the "Microsoft Scripting Language Interface" is. Searching for it in MSDN turns up only an article ("Using COM Objects in Windows Script Host") which describes running scripts using WScript.exe or CScript.exe. It seems unlikely that the XMetaL application would be launching a fresh CScript.exe or WScript.exe process every time a macro is invoked (with the massive performance hit that would introduce), so presumably they have a copy of this elusive interface specification which they're following to emulate what those applications are doing. > The next best thing would probably be a stack trace of the crash. Any tips for how I would go about obtaining such a thing? I suppose it's possible that the crash happens while some Python code is running, and I'd be able to wrap that code in a try block and dump a stack track to a file (assuming I can guess what code that would be). But it seems at least as likely that when the crash occurs (that is, when the dialog window appears at logoff time reporting the memory access violation) we are no longer anywhere near any of the Python code. Perhaps the Python code (or C code underneath it) has done something naughty (for example, trashing a pointer somewhere) well before the actual crash happens and it only manifests itself at logoff time when the OS forces the application to let go and really shut down. Any advice you can provide to help me get a better understanding of how the moving parts interact and what I should try next would be immensely appreciated. Many thanks, Bob From bkline at rksystems.com Tue Nov 29 11:06:58 2022 From: bkline at rksystems.com (Bob Kline) Date: Tue, 29 Nov 2022 11:06:58 -0500 Subject: [python-win32] Memory access violation using pywin32 as WSH In-Reply-To: References: Message-ID: Cranking up the microscope (or spelunking deeper, whichever metaphor you prefer), the first thing I'll say is that this code is devilishly complex. Here's what I've found in the latest pass. First, there's a minor bug at line 353 of pyscript.py [1], where globalNameSpaceModule is set to None when it's self.globalNameSpaceModule which should be set to None. The bug is currently innocuous, as the only invocation of the method in which that assignment is made in this version of the code is from PyScript.Close(), and that method makes the correct assignment: self.globalNameSpaceModule = None It seems to me that there's a more serious problem at line 350 of that module [2], where that same method appears to be invoking a method which does not exist, at least as far as I can determine (bearing in mind that I might not completely understand all the nuances of the tricky code here). self.globalNameSpaceModule.ax._Reset_() Working backward, to see if I can figure out where _Reset_ would be defined, I found this code in the PyScript class: def InitNew(self): framework.COMScript.InitNew(self) import imp self.scriptDispatch = None self.globalNameSpaceModule = imp.new_module("__ax_main__") self.globalNameSpaceModule.__dict__['ax'] = AXScriptAttribute(self) .... It's not completely clear how this method gets invoked (I don't see any calls to it, but I do see that "InitNew" appears as one of the strings in the _public_methods_ array attribute of the base class), but I can tell from my logging that it does get called. However it gets invoked, that means that the _Reset_() call being made above is on an instance of the AXScriptAttribute class, which?as far as I can tell?has no _Reset_() method (and no base class from which it could inherit that method). This is confirmed by an exception which is caught at shutdown time in the PyScript.ResetNamespace() method. The handler for that exception looks like this: except AttributeError: pass # ??? The obvious questions would be * what was the non-existent method expected to do? * could the fact that it didn't get done be causing my problem? The ResetNamespace method has no documentation, so all I would have for answers to those questions would be wild guesses. As a side note, imp.new_module() [3] was deprecated back in Python 3.4. I'm attaching the logs I captured. One set is for a session in which the macro was only invoked once (and therefore didn't result in any observable failures) and the other for the session in which the macro was invoked twice, with the symptoms described earlier in this thread. Please let me know if anything else stands out as potentially useful in the logs. Cheers, Bob [1] https://github.com/SublimeText/Pywin32/blob/master/lib/x64/win32comext/axscript/client/pyscript.py#L353 [2] https://github.com/SublimeText/Pywin32/blob/master/lib/x64/win32comext/axscript/client/pyscript.py#L350 [3] https://docs.python.org/3/library/imp.html#imp.new_module -------------- next part -------------- A non-text attachment was scrubbed... Name: pyscript-logs.tar Type: application/x-tar Size: 26624 bytes Desc: not available URL: From bkline at rksystems.com Tue Nov 29 17:09:05 2022 From: bkline at rksystems.com (Bob Kline) Date: Tue, 29 Nov 2022 17:09:05 -0500 Subject: [python-win32] Memory access violation using pywin32 as WSH In-Reply-To: References: Message-ID: One more data point. I added a bit more to my logging and learned that the seven calls to the ScriptItem constructor each time the macro is invoked are for the seven global objects which the host application (XMetaL) makes available to the scripts: * FormDriver * ActiveDocument * Selection * Application * FormFuncs * ResourceManager So at least part of that puzzle is cleared up, though it's still somewhat unsettling that only seven calls to ScriptItem.Close() are made, regardless of how many ScriptItem objects have been instantiated during a session. Cheers, Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhammond at skippinet.com.au Tue Nov 29 18:19:49 2022 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 30 Nov 2022 10:19:49 +1100 Subject: [python-win32] Memory access violation using pywin32 as WSH In-Reply-To: References: Message-ID: <7209e0b0-12e2-ea7f-de57-6fdf5bafbbcb@skippinet.com.au> On 30/11/2022 3:06 am, Bob Kline wrote: > Cranking up the microscope (or spelunking deeper, whichever metaphor > you prefer), the first thing I'll say is that this code is devilishly > complex. > > Here's what I've found in the latest pass. > > First, there's a minor bug at line 353 of pyscript.py [1], where > globalNameSpaceModule is set to None when it's > self.globalNameSpaceModule which should be set to None. The bug is > currently innocuous, as the only invocation of the method in which > that assignment is made in this version of the code is from > PyScript.Close(), and that method makes the correct assignment: Oops, yeah, that looks like a bug (but note that the links you are using are from sublime text, not from pywin32 - it looks quite old - the correct link is https://github.com/mhammond/pywin32/blob/main/com/win32comext/axscript/client/pyscript.py where it is at line 416. > self.globalNameSpaceModule = None > > It seems to me that there's a more serious problem at line 350 of that > module [2], where that same method appears to be invoking a method > which does not exist, at least as far as I can determine (bearing in > mind that I might not completely understand all the nuances of the > tricky code here). > > self.globalNameSpaceModule.ax._Reset_() > > Working backward, to see if I can figure out where _Reset_ would be > defined, I found this code in the PyScript class: > > def InitNew(self): > framework.COMScript.InitNew(self) > import imp > self.scriptDispatch = None > self.globalNameSpaceModule = imp.new_module("__ax_main__") > self.globalNameSpaceModule.__dict__['ax'] = AXScriptAttribute(self) > .... > > It's not completely clear how this method gets invoked (I don't see > any calls to it, but I do see that "InitNew" appears as one of the > strings in the _public_methods_ array attribute of the base class), Yes, that's a COM method, so called by the host - see https://learn.microsoft.com/en-us/dotnet/api/microsoft.visualstudio.debugger.interop.iactivescriptparse64. That try/except block was probably just handling the case where Reset is called twice without an InitNew call in between (in which case self.globalNameSpaceModule is None, so will not have a .ax attribute) - but I agree with your analysis that even if it *did* have that attribute, the ax object isn't going to have a Reset - so whatever that's trying to do isn't getting done. > As a side note, imp.new_module() [3] was deprecated back in Python 3.4. Yep, you are looking at a very old version. > I'm attaching the logs I captured. One set is for a session in which > the macro was only invoked once (and therefore didn't result in any > observable failures) and the other for the session in which the macro > was invoked twice, with the symptoms described earlier in this thread. > Please let me know if anything else stands out as potentially useful Nothing stands out there :( But that's not particularly surprising as it really should be impossible for bugs in that .py code to crash the process - strangeness could happen, but an access violation shouldn't be possible. Something like a COM reference counting bug in (either in axscript or in the host) could explain this. Re your other message, when I say I'm hoping to see a stack trace, I mean a native stack trace, as should be shown in the event viewer or in a JIT debugger, which will show the symbols in the various DLLs rather than the Python functions. Eg, it showing the crash happening in, say, IUnknown::Release would imply such a reference counting bug, or if it instead shows it in some other COM method it would help narrow down the problem area. Unfortunately, without knowing your environment I can't offer specific advice about how to get it - but running the crashing program under any Visual Studio version would certainly offer it. HTH, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhammond at skippinet.com.au Tue Nov 29 18:23:11 2022 From: mhammond at skippinet.com.au (Mark Hammond) Date: Wed, 30 Nov 2022 10:23:11 +1100 Subject: [python-win32] Memory access violation using pywin32 as WSH In-Reply-To: References: Message-ID: On 30/11/2022 9:09 am, Bob Kline wrote: > > So at least part of that puzzle is cleared up, though it's still > somewhat unsettling that only seven calls to ScriptItem.Close() are > made, regardless of how many ScriptItem objects have been instantiated > during a session. The close method is https://learn.microsoft.com/en-us/dotnet/api/microsoft.visualstudio.debugger.interop.iactivescript.close?view=visualstudiosdk-2019, so it's the responsibility of the host to call that. I agree it's a bit of a red flag, and may point to confusion in the host about object lifetimes, which could certainly end up causing what you are seeing. It's worth pointing out that any "obvious" bug in pywin32 here would probably be able to be reproduced in, and reported by, the various other hosts, including cscript.exe and wscript.exe (which themselves are just active script hosts, just like your problematic host) Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkline at rksystems.com Wed Nov 30 04:40:09 2022 From: bkline at rksystems.com (Bob Kline) Date: Wed, 30 Nov 2022 04:40:09 -0500 Subject: [python-win32] Memory access violation using pywin32 as WSH In-Reply-To: <7209e0b0-12e2-ea7f-de57-6fdf5bafbbcb@skippinet.com.au> References: <7209e0b0-12e2-ea7f-de57-6fdf5bafbbcb@skippinet.com.au> Message-ID: On Tue, Nov 29, 2022 at 6:19 PM Mark Hammond wrote: > ... the ax object isn't going to have a Reset - so whatever that's trying to do isn't getting done. How would we go about finding out what that missing method was supposed to do, so that we can know whether the failure to do it is related to the problem? One of the frustrations here is that while the documentation for the host application says "You can use any scripting language that conforms to the Microsoft Scripting Language Interface" trying to find the specification for that interface on Microsoft's web site turns up nothing. Has Microsoft published the spec and then gone to the trouble of extirpating every trace of it? Do you have a copy? > ... Yep, you are looking at a very old version. Sorry for the old link. Don't have any idea how I ended up in that repository. Obviously the copy I was hacking to get my debug logging was the real thing, installed by pip. I'm suitably embarrassed that I didn't notice that they didn't match. > ... when I say I'm hoping to see a stack trace, I mean a native stack trace I'll see what I can do to produce one. Thanks, Bob From bkline at rksystems.com Wed Nov 30 05:15:16 2022 From: bkline at rksystems.com (Bob Kline) Date: Wed, 30 Nov 2022 05:15:16 -0500 Subject: [python-win32] Memory access violation using pywin32 as WSH In-Reply-To: References: Message-ID: On Tue, Nov 29, 2022 at 6:23 PM Mark Hammond wrote: > The close method is .... Microsoft is not helping much here. The documentation to which you linked has no information about this method other than that it returns a 32-bit integer for which no semantics are given, and that it lives in the Microsoft.VisualStudio.Debugger.Interop namespace. I'm having a little difficulty figuring out how that namespace would be appropriate for their general scripting language interface. > It's worth pointing out that any "obvious" bug in pywin32 > here would probably be able to be reproduced in, and > reported by, the various other hosts, including cscript.exe > and wscript.exe (which themselves are just active script > hosts, just like your problematic host) I had that thought, too. But then I realized that cscript.exe and wscript.exe use a model of a separate process for each invocation of a single script. That script can be very complicated, but it's loaded, parsed, and executed once. I can run a pretty complicated Python macro once per XMetaL session (by which I mean separate process) without any problem. If I want to run a script twice using cscript.exe I have to launch two separate cscript.exe processes. It occurred to me that a better comparison might be using Internet Explorer, which can presumably run multiple scripts multiple times in a single process. So I grabbed form.htm from axscript/Demos/client/ie (I promise I'm looking at the correct repository now ?), thinking I'd see if clicking the Submit button multiple times caused any problems. Unfortunately, the scripts didn't fire at all, and the browser's console window didn't provide any explanation as to why. (By the way, I had to fix the third INPUT element, which was malformed, as its tag was missing its right angle bracket delimiter. IE may have been tolerant of that broken syntax at some time in the past, but it doesn't accept it now.) Cheers, Bob From bkline at rksystems.com Wed Nov 30 07:59:41 2022 From: bkline at rksystems.com (Bob Kline) Date: Wed, 30 Nov 2022 07:59:41 -0500 Subject: [python-win32] Memory access violation using pywin32 as WSH In-Reply-To: <7209e0b0-12e2-ea7f-de57-6fdf5bafbbcb@skippinet.com.au> References: <7209e0b0-12e2-ea7f-de57-6fdf5bafbbcb@skippinet.com.au> Message-ID: On Tue, Nov 29, 2022 at 6:19 PM Mark Hammond wrote: > > On 30/11/2022 3:06 am, Bob Kline wrote: > .... >> As a side note, imp.new_module() [3] was deprecated back in Python 3.4. > > Yep, you are looking at a very old version. True, but I checked HEAD for the main branch, and the code [1] is still calling the deprecated method. Cheers, Bob [1] https://github.com/mhammond/pywin32/blob/main/com/win32comext/axscript/client/pyscript.py#L217 From bkline at rksystems.com Wed Nov 30 16:51:22 2022 From: bkline at rksystems.com (Bob Kline) Date: Wed, 30 Nov 2022 16:51:22 -0500 Subject: [python-win32] Memory access violation using pywin32 as WSH In-Reply-To: References: <7209e0b0-12e2-ea7f-de57-6fdf5bafbbcb@skippinet.com.au> Message-ID: We have a glimmer of hope. Just got a fresh build of xmetal.exe from the vendor, and it's not failing in my initial tests. Much more testing to do, but this looks very promising. I've asked them to tell me about the fix, but they've dodged that question so far. So let me stop here and tell you how grateful I am for your patient assistance. And (of course) for creating this package in the first place. ?? Many thanks, Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From nina.punji at gmail.com Wed Nov 30 11:16:49 2022 From: nina.punji at gmail.com (QMUL_EECS DVS) Date: Wed, 30 Nov 2022 16:16:49 +0000 Subject: [python-win32] Pywin32 without the interface Message-ID: Hi all, I hope you are well. I?m trying to use pywin32 on my local server, is it possible to run it without the Visio/ Word interface open? Since I can only see the command line Thanks Best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From timr at probo.com Wed Nov 30 23:57:40 2022 From: timr at probo.com (Tim Roberts) Date: Wed, 30 Nov 2022 20:57:40 -0800 Subject: [python-win32] Pywin32 without the interface In-Reply-To: References: Message-ID: <51adf103-005e-527c-1c8a-1b4585da808a@probo.com> On 11/30/22 8:16 AM, QMUL_EECS DVS wrote: > I hope you are well. I?m trying to use pywin32 on my local server, is > it possible to run it without the Visio/ Word interface open? Since I > can only see the command line The question doesn't make much sense.? Are you saying that you want to automate Visio and Word through pythoncom, but you don't want the application window to be visible?? That can be done. Please clarify. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc.