From hartmut.niemann at siemens.com Fri Mar 2 03:07:05 2018 From: hartmut.niemann at siemens.com (Niemann, Hartmut) Date: Fri, 2 Mar 2018 08:07:05 +0000 Subject: [python-win32] Excel / Word: setting properties In-Reply-To: <99874e19-977c-dff1-2b4f-43b2972f42c6@probo.com> References: <1AE3002F400CE4498072DFDF74A843CC1F71C080@DEFTHW99EH3MSX.ww902.siemens.net> <99874e19-977c-dff1-2b4f-43b2972f42c6@probo.com> Message-ID: <1AE3002F400CE4498072DFDF74A843CC1F71D559@DEFTHW99EH3MSX.ww902.siemens.net> Hello Tim! print ('%r' % workbook.BuiltinDocumentProperties) gives me > What can I do with such an object? Mit freundlichen Gr??en Dr. Hartmut Niemann Siemens AG Mobility Division Rolling Stock Standardization, Remote Control, Display MO RS LM EN CCI SRD Werner-von-Siemens-Str. 67 91052 Erlangen, Deutschland Mobil: +49 173 5342327 mailto:hartmut.niemann at siemens.com www.siemens.com/ingenuityforlife -----Urspr?ngliche Nachricht----- Von: python-win32 [mailto:python-win32-bounces+hartmut.niemann=siemens.com at python.org] Im Auftrag von Tim Roberts Gesendet: Mittwoch, 28. Februar 2018 18:20 An: Python-Win32 List Betreff: Re: [python-win32] Excel / Word: setting properties Niemann, Hartmut wrote: > > ? > > How do I set the [Excel workbook] standard property "Keywords" to > "C_Restricted" and the user property "Document Confidentiality" to > "Restricted"? > The Document object should have a BuiltinDocumentProperties collection and a CustomDocumentProperties collection that you can query and manipulate.? You'll have to discover whether the properties you need to tweak are builtin or not. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. _______________________________________________ python-win32 mailing list python-win32 at python.org https://mail.python.org/mailman/listinfo/python-win32 From timr at probo.com Fri Mar 2 03:12:35 2018 From: timr at probo.com (Tim Roberts) Date: Fri, 2 Mar 2018 00:12:35 -0800 Subject: [python-win32] Excel / Word: setting properties In-Reply-To: <1AE3002F400CE4498072DFDF74A843CC1F71D559@DEFTHW99EH3MSX.ww902.siemens.net> References: <1AE3002F400CE4498072DFDF74A843CC1F71C080@DEFTHW99EH3MSX.ww902.siemens.net> <99874e19-977c-dff1-2b4f-43b2972f42c6@probo.com> <1AE3002F400CE4498072DFDF74A843CC1F71D559@DEFTHW99EH3MSX.ww902.siemens.net> Message-ID: <568ED205-615A-47F6-8AF8-827EFCA336AC@probo.com> On Mar 2, 2018, at 12:07 AM, Niemann, Hartmut wrote: > > print ('%r' % workbook.BuiltinDocumentProperties) > > gives me > > > > > What can I do with such an object? Are you checking the Word object model? The BuiltinDocumetProperties method returns a DocumentProperties object. I believe that is a collection of DocumentProperty objects. So you should be able to say something like for prop in workbook.BuiltinDocumentProperties: ? Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hartmut.niemann at siemens.com Fri Mar 2 04:18:00 2018 From: hartmut.niemann at siemens.com (Niemann, Hartmut) Date: Fri, 2 Mar 2018 09:18:00 +0000 Subject: [python-win32] Excel / Word: setting properties In-Reply-To: <568ED205-615A-47F6-8AF8-827EFCA336AC@probo.com> References: <1AE3002F400CE4498072DFDF74A843CC1F71C080@DEFTHW99EH3MSX.ww902.siemens.net> <99874e19-977c-dff1-2b4f-43b2972f42c6@probo.com> <1AE3002F400CE4498072DFDF74A843CC1F71D559@DEFTHW99EH3MSX.ww902.siemens.net> <568ED205-615A-47F6-8AF8-827EFCA336AC@probo.com> Message-ID: <1AE3002F400CE4498072DFDF74A843CC1F71D5B7@DEFTHW99EH3MSX.ww902.siemens.net> Hello Tim, workbook.CustomDocumentProperties.add(u'Document Confidentiality', False, 4, u'Restricted', False) for p in workbook.BuiltinDocumentProperties: if p.Name == 'Keywords': p.Value = 'C_Restricted' did the trick for me. Thank you for your support. Mit freundlichen Gr??en Dr. Hartmut Niemann Siemens AG Mobility Division Rolling Stock Standardization, Remote Control, Display MO RS LM EN CCI SRD Werner-von-Siemens-Str. 67 91052 Erlangen, Deutschland Mobil: +49 173 5342327 mailto:hartmut.niemann at siemens.com www.siemens.com/ingenuityforlife Von: python-win32 [mailto:python-win32-bounces+hartmut.niemann=siemens.com at python.org] Im Auftrag von Tim Roberts Gesendet: Freitag, 2. M?rz 2018 09:13 An: Python-Win32 List Betreff: Re: [python-win32] Excel / Word: setting properties On Mar 2, 2018, at 12:07 AM, Niemann, Hartmut > wrote: print ('%r' % workbook.BuiltinDocumentProperties) gives me > What can I do with such an object? Are you checking the Word object model? The BuiltinDocumetProperties method returns a DocumentProperties object. I believe that is a collection of DocumentProperty objects. So you should be able to say something like for prop in workbook.BuiltinDocumentProperties: ? Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vernondcole at gmail.com Sun Mar 4 14:53:29 2018 From: vernondcole at gmail.com (Vernon D. Cole) Date: Sun, 4 Mar 2018 12:53:29 -0700 Subject: [python-win32] Bug reporting In-Reply-To: <32dd7921-05e9-31c8-0dde-8e5fe8df0f63@skippinet.com.au> References: <25b03231-c10d-84e1-2c9e-18a4863c9316@skippinet.com.au> <9ba1e1ec-51a0-08dc-07d7-f11a7e961670@skippinet.com.au> <32dd7921-05e9-31c8-0dde-8e5fe8df0f63@skippinet.com.au> Message-ID: I decided to meditate for a few days rather than answer immediately and poorly. After I took over maintenance of adodbapi in about 2003, I was struggling with how to properly document that most users (CPython) had to install pywin32 as a prerequisite. At that time the odbc sub-module had a couple of bugs, and ADO seemed to be all the future. Also pywin32's odbc module follows the api 1.0 version. I asked, and received a green light, to bundle adodbapi with pywin32. When you (Mark) gave that okay, you had one stipulation: that the module get "some support". During the last few years I have failed to provide that support. That fact causes me daily regret. I want the opportunity to correct my failure. I also want to enable someone else to be able to support the package should the need arise, like if I have a stroke or something. I have already survived cancer. I understand that pywin32 support is "largely" just you, but adodbapi support is _only_ just me -- a critical difference. Here is what I propose: 1) This time, rather than copy a selected (major) part of the adodbapi source files over to their pywin32 directory, I would copy _all_ of the files. 2) Adjust adodbapi/MANIFEST.in and setup.py to create a proper PyPi submission from that directory. 3) Adjust the pywin32 MANIFEST.in to include a subset of adodbapi files that actually works. 4) Put a simple go/no-go test of adodbapi (perhaps ACCESS database only) into the pywin32 test suite. 5) document in SourceForge that future updates will take place in the pywin32 repo. -- Vernon On Mon, Feb 26, 2018 at 5:53 PM, Mark Hammond wrote: > On 27/02/2018 5:40 am, Vernon D. Cole wrote: > >> Second: the effective "bus size" of the adodbapi repo is *one*. The other >> three authorized maintainers are inactive. Indeed, the way I got approved >> as a maintainer 15 years ago (has it really been that long?) was to >> document to SourceForge that the then-existing two maintainers were >> unresponsive. Moving the working source into the pywin32 repo would solve >> that problem. >> > > It's not immediately clear that it would though. pywin32 itself has the > exact same issue (ie, it's largely just me), and I don't use or know much > about adodbapi - so it seems somewhat likely you'd have the same "bus size" > - just on a different bus :) > > My research this morning suggests that by suitable editing of the >> MANIFEST.in file in the pywin32 root, and the /adodbapi/MANIFEST.in and >> ./setup.py we could effectively send two seemingly independent (but source >> locked) versions of adodbapi to PyPi. That should keep both >> CPython/pywin32 and IronPython use cases covered. Should I pursue that? >> > > When building pywin32 I don't send *any* versions of adodbapi to pypi, so > I'm really not sure what that means. I'm reluctant to agree that building > pywin32 will create many discrete wheels - I already need to upload wheels > for each python version supported and for 64 and 32 bits and making the > build and release process more convoluted doesn't sound like a win for me. > > So can you please explain in more detail what is being proposed here, and > why it would be preferred to splitting adodbapi into its own repo on > github, possibly including removal of it from pywin32 if the duplication > causes problems? > > Cheers, > > Mark > > -- >> Vernon >> >> >> I spent the morning reviewing the documentation for setuptools and wheels >> and such. >> >> >> >> On Sun, Feb 25, 2018 at 7:35 PM, Bob Kline > bkline at rksystems.com>> wrote: >> >> On Sun, Feb 25, 2018 at 6:18 PM, Mark Hammond >> > wrote: >> >> > 1) There's a relatively easy fix that can be made to the copy of >> adodbapi >> > which is inside pywin32. >> >> Right. Basically, I think what needs to happen is for the fork on >> GitHub to be brought in sync with the working code on SF. I'm going to >> guess it's not quite as simple as that, because we'd want to be >> careful to preserve any patches which got applied on GitHub, but >> didn't make it to the original repo. Don't know for sure that there >> are any, but we should check. >> >> > 2) There's a concern regarding some IronPython bindings for >> adodbapi which >> > aren't in pywin32 and Vernon was asking something whether they >> should also >> > be included in pywin32. >> >> As I understand it, the code to support IronPython is already included >> in what's on GitHub. I think Vernon's hoping that there's a way to >> script an export of just the adodbapi portion of your GitHub repo for >> the use of the IronPython users (who, as you correctly point out, have >> no use for the pywin32 bits). If that's possible (and I can't see why >> it wouldn't be, as GitHub is pretty easy to script), he would be able >> to avoid the tedium and risks involved in having to maintain the same >> code base in two different places. It would also eliminate the "where >> am I supposed to file bugs" confusion, as well as make it easier to >> persuade others to assist with maintenance of the code. Most of the >> adodbapi code is common for IronPython and CPython users, and I don't >> see that the presence of "if IronPython: ..." code in the >> mhammond/pywin32 repo does any harm (after all, it's already there and >> I'll bet no one has noticed). >> >> I hope that makes things a little clearer. But this explanation is >> speculation on my part, and I should really let Vernon say what he >> means for #2. >> >> Regards, >> Bob >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhammond at skippinet.com.au Tue Mar 6 02:11:58 2018 From: mhammond at skippinet.com.au (Mark Hammond) Date: Tue, 6 Mar 2018 18:11:58 +1100 Subject: [python-win32] Bug reporting In-Reply-To: References: <25b03231-c10d-84e1-2c9e-18a4863c9316@skippinet.com.au> <9ba1e1ec-51a0-08dc-07d7-f11a7e961670@skippinet.com.au> <32dd7921-05e9-31c8-0dde-8e5fe8df0f63@skippinet.com.au> Message-ID: That sounds fine to me. On 5/03/2018 6:53 am, Vernon D. Cole wrote: > Here is what I propose: > > 1) This time, rather than copy a selected (major) part of the adodbapi > source files over to their pywin32 directory, > I would copy _all_ of the files. > > 2) Adjust adodbapi/MANIFEST.in and setup.py to create a proper PyPi > submission from that directory. That sounds good, but could you please tweak setup.py so that it sticks the files into "../dist", so everything I need to release ends up in the same dir. You'll probably also need to tweak adodbapi on pypi so I can upload. > 3) Adjust the pywin32 MANIFEST.in to include a subset of adodbapi files > that actually works. > > 4) Put a simple go/no-go test of adodbapi (perhaps ACCESS database only) > into the pywin32 test suite. > > 5) document in SourceForge that future updates will take place in the > pywin32 repo. I guess I'll look forward to a PR :) Cheers, Mark From sg.tino at gmail.com Fri Mar 9 13:54:36 2018 From: sg.tino at gmail.com (Stefano) Date: Fri, 9 Mar 2018 19:54:36 +0100 Subject: [python-win32] Read data from PyIUknown type variable Message-ID: Hello everyone I'm using win32com.client to read data from custom COM Object developed in VB.Net. With the following code I'm able to read a string result --- >>> import win32com.client>>> cstApp = win32com.client.Dispatch("CustomLib.CSTApp")>>> string = cstApp.GiveMeTestString()>>> print(type(string))>>> print("Test String: {0}".format(string))Test String: Well done! I come from COM Object --- I've now a method that give as result a VB.Net Dictionary type, but when I try to read it from my python script I get a PyIUknown type and I'm not able to read its values --- >>> username = 'artur'>>> resultset = cstApp.OpenTaskforUser(username)>>> print(type(resultset))>>> print(resultset) --- How can I read it's data? Otherwise, which type I need to use in VB.Net to be able to read a Python list containing dictionaries from win32com? Thank you for your help. Stefano PS: the same question was posted here https://stackoverflow.com/q/49196724/1891624 Thank you for your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kontakt at kluthr.de Thu Mar 15 04:44:30 2018 From: kontakt at kluthr.de (Robin Kluth) Date: Thu, 15 Mar 2018 09:44:30 +0100 Subject: [python-win32] pywintypes.error: (5, 'RegSetValueEx', 'Access denied') Message-ID: Hi :) I use Python 2.7 on win10 and pywin32 223. I want to log messqages to the EventLog: dllname = os.path.dirname(__file__) ntl = NTEventLogHandler("Python Logging Test", dllname=dllname) logger = logging.getLogger("") logger.setLevel(logging.DEBUG) logger.addHandler(ntl) logger.error("This is a '%s' message", "Error") But I get: Traceback (most recent call last): File "fpp_user_import.py", line 44, in ntl = NTEventLogHandler("Python Logging Test", dllname=dllname) File "C:\Python27\lib\logging\handlers.py", line 987, in __init__ self._welu.AddSourceToRegistry(appname, dllname, logtype) File "C:\Python27\lib\site-packages\win32\lib\win32evtlogutil.py", line 42, in AddSourceToRegistry msgDLL) pywintypes.error: (5, 'RegSetValueEx', 'Zugriff verweigert') If I run the script with Admin privs, it is working. How to log as "normal" user? Am I missing something? Thanks in advance! From timr at probo.com Thu Mar 15 13:10:43 2018 From: timr at probo.com (Tim Roberts) Date: Thu, 15 Mar 2018 10:10:43 -0700 Subject: [python-win32] pywintypes.error: (5, 'RegSetValueEx', 'Access denied') In-Reply-To: References: Message-ID: <42cc9bcc-b6ab-0952-90f5-3f5bd43da68f@probo.com> Robin Kluth wrote: > > I use Python 2.7 on win10 and pywin32 223. I want to log messqages to > the EventLog: > > dllname = os.path.dirname(__file__) > ntl = NTEventLogHandler("Python Logging Test", dllname=dllname) > logger = logging.getLogger("") > logger.setLevel(logging.DEBUG) > logger.addHandler(ntl) > > logger.error("This is a '%s' message", "Error") > > But I get: > ... > pywintypes.error: (5, 'RegSetValueEx', 'Zugriff verweigert') > > If I run the script with Admin privs, it is working. > > How to log as "normal" user? Am I missing something? You can't.? If you want to log to the event log, you'll need privileges.? Each app must register as an "event source".? Doing so requires writing to the HKEY_LOCAL_MACHINE part of the registry, and write requires admin privileges. Technically speaking, it would be possible to register that source once in an elevated process and then use it without re-registering, but the current code does not support that. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From eryksun at gmail.com Thu Mar 15 19:31:15 2018 From: eryksun at gmail.com (eryk sun) Date: Thu, 15 Mar 2018 23:31:15 +0000 Subject: [python-win32] pywintypes.error: (5, 'RegSetValueEx', 'Access denied') In-Reply-To: References: Message-ID: On Thu, Mar 15, 2018 at 8:44 AM, Robin Kluth wrote: > > I use Python 2.7 on win10 and pywin32 223. I want to log messqages to the > EventLog: > > dllname = os.path.dirname(__file__) > ntl = NTEventLogHandler("Python Logging Test", dllname=dllname) The Python module should not be used for dllname. This needs to be a PE image (e.g. PYD, DLL, EXE) that has an embedded message table. NTEventLogHandler currently just hard codes using event ID 1, which is "%1\r\n" in win32evtlog.pyd or win32service.pyd. The "%1" insert gets replaced by the message text when the log record is formatted. In your case, just leave it as the default. > Traceback (most recent call last): > File "fpp_user_import.py", line 44, in > ntl = NTEventLogHandler("Python Logging Test", dllname=dllname) > File "C:\Python27\lib\logging\handlers.py", line 987, in __init__ > self._welu.AddSourceToRegistry(appname, dllname, logtype) > File "C:\Python27\lib\site-packages\win32\lib\win32evtlogutil.py", line > 42, in AddSourceToRegistry > msgDLL) > pywintypes.error: (5, 'RegSetValueEx', 'Zugriff verweigert') > > If I run the script with Admin privs, it is working. > > How to log as "normal" user? Am I missing something? This should be enhanced in NTEventLogHandler. It's not the end of the world if this key doesn't get created. The event viewer will just show a warning that the event ID can't be found for the given source. Also, when installed an application can request elevation to register the event log source. Given this, I suggest you work around the problem with a subclass that ignores this error. For example: import logging import logging.handlers class NTEventLogHandler(logging.handlers.NTEventLogHandler): __doc__ = logging.handlers.NTEventLogHandler.__doc__ def __init__(self, appname, dllname=None, logtype="Application"): logging.Handler.__init__(self) self.appname = appname self.dllname = dllname self.logtype = logtype try: import win32evtlogutil, win32evtlog, winerror except ImportError: print('The Python Win32 extensions for NT (service, event ' 'logging) appear not to be available.') self._welu = None return self._welu = win32evtlogutil self.deftype = win32evtlog.EVENTLOG_ERROR_TYPE self.typemap = { logging.DEBUG : win32evtlog.EVENTLOG_INFORMATION_TYPE, logging.INFO : win32evtlog.EVENTLOG_INFORMATION_TYPE, logging.WARNING : win32evtlog.EVENTLOG_WARNING_TYPE, logging.ERROR : win32evtlog.EVENTLOG_ERROR_TYPE, logging.CRITICAL: win32evtlog.EVENTLOG_ERROR_TYPE, } try: win32evtlogutil.AddSourceToRegistry(appname, dllname, logtype) except win32evtlogutil.error as e: if e.winerror != winerror.ERROR_ACCESS_DENIED: raise From Pascal.Marchand at Honeywell.com Mon Mar 19 06:20:04 2018 From: Pascal.Marchand at Honeywell.com (Marchand, Pascal) Date: Mon, 19 Mar 2018 10:20:04 +0000 Subject: [python-win32] Advice about usinf win32com Message-ID: Hello, I don't know how to do something with the win32com module (or maybe with another...). I post my problem on stack overflow but I didn't get any reply. I do that piece of code for a project in my job for testing some possibilities of a zebra scanner, I chose python because it's interpreted and very easy for doing tests and because I know it a bit and I didn't want to invest time and money in Visual studio. I'm trying to discuss with a Zebra RFID/bar code scanner using the WMI provider as recommended in dev guides, it runs fairly well with properties, I got method names and parameters too, but I didn't reach to make run method with byref parameter e.g. method(inpar, outpar) both parameters are strings (xml message), the function returns a status code correctly, see code below. I searched on the net without finding solution, I give the corresponding .net c# code to call the method after python code (from the prog examples of the SDK guide for scanner), if it can help you to help me Python code # -*- coding: utf-8 -*- import win32com.client objWMIService = win32com.client.Dispatch("WbemScripting.SWbemLocator") strComputer = "." objSWbemServices = objWMIService.ConnectServer(strComputer,"root\cimv2") oos = objSWbemServices.ExecQuery("SELECT * FROM Symbol_BarcodeScanner") oo = oos[0] # list all object properties for op in oo.Properties_: print(op.Name, op.Value) # list all object methods for om in oo.Methods_: out_parameter_names = [] in_parameters_names = [] if om.OutParameters: out_parameter_names = [(i.Name, i.IsArray) for i in om.OutParameters.Properties_] if om.InParameters: in_parameters_names = [(i.Name, i.IsArray) for i in om.InParameters.Properties_] print('func : ',om.Name) print('In : ',in_parameters_names) print('Out : ',out_parameter_names) inxml="533,534" outxml="" oo._FlagAsMethod('GetAttributes') a = = oo.GetAttributes(inxml,outxml) .net C# code to call a method. ManagementObject o = new ManagementObject(); o.Scope = mgmtScope; o.Path = new ManagementPath("Symbol_BarcodeScanner.PartNumber='" + strPartNumber + "',SerialNumber='" + strSerialNumber + "'"); // Create ManagementBaseObject and get the parameters to the Method "GetAttributes" inParams = o.GetMethodParameters("GetAttributes"); // Fill the Parameter "attNumberList" with the attributeList string inParams["attNumberList"] = attributeList; // Invoke the "GetAttributes" Method and save the result to a new ManagementBaseObject outparams = o.InvokeMethod("GetAttributes", inParams, null); Thanks for your help Regards. Pascal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From timr at probo.com Tue Mar 20 12:33:28 2018 From: timr at probo.com (Tim Roberts) Date: Tue, 20 Mar 2018 09:33:28 -0700 Subject: [python-win32] Advice about usinf win32com In-Reply-To: References: Message-ID: Marchand, Pascal wrote: > ? > > I'm trying to discuss with a Zebra RFID/bar code scanner using the WMI > provider as recommended in dev guides, it runs fairly well with > properties, I got method names and parameters too, but I didn't reach > to make run method with byref parameter e.g. method(inpar, outpar) > both parameters are strings (xml message), the function returns a > status code correctly, see code below. > Python cannot do "out" parameters at all.? In the win32com world, when a call has one "in" and one "out" parameter, instead of this: ??? status = function( in, out ) it gets written like this: ??? (status, out) = function( in ) There are some cases when the win32com machinery can't detect that, but usually it works.? Give that a shot. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From scott at spigotlabs.com Fri Mar 23 12:44:13 2018 From: scott at spigotlabs.com (Scott Vitale) Date: Fri, 23 Mar 2018 10:44:13 -0600 Subject: [python-win32] win32com + Brother Printer + Django Message-ID: Hi there, I'm looking for some win32com help... I have a simple Python script that creates a `Dispatch` object for a `bpac.Document` type (it's a Brother printer SDK class). It works perfectly fine in a standalong script, but as soon as I attempt to call this code from Django, it hangs on creating the `Dispatch` object....so bizarre. I've tried calling `CoInitialize` in a variety of ways, no difference in behavior. The other oddity is that I can create `bpac.Printer` objects with no issue. It's only the `bpac.Document` type that hangs. Unfortunately I don't have access to the library source and I'm not sure how to debug why it's hanging. Any insight is greatly appreciated. Scott Vitale Founder & CEO 720.288.6336 @svvitale Learn about my perspectives on development, business, and my personal quest to shake up the #eventtech world on Medium ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From timr at probo.com Sun Mar 25 02:23:43 2018 From: timr at probo.com (Tim Roberts) Date: Sat, 24 Mar 2018 23:23:43 -0700 Subject: [python-win32] win32com + Brother Printer + Django In-Reply-To: References: Message-ID: <3023455A-9311-4480-A31F-5672DC4E6EB3@probo.com> On Mar 23, 2018, at 9:44 AM, Scott Vitale wrote: > > I'm looking for some win32com help... I have a simple Python script that creates a `Dispatch` object for a `bpac.Document` type (it's a Brother printer SDK class). It works perfectly fine in a standalong script, but as soon as I attempt to call this code from Django, it hangs on creating the `Dispatch` object....so bizarre. > > I've tried calling `CoInitialize` in a variety of ways, no difference in behavior. > > The other oddity is that I can create `bpac.Printer` objects with no issue. It's only the `bpac.Document` type that hangs. Unfortunately I don't have access to the library source and I'm not sure how to debug why it's hanging. How are you running your Django app? Is it running as a service? Is it networked, or directly connected? Microsoft does not recommend printing from Windows services, in parts because of security considerations. Your service is running as a special Windows user (unless you've configured it), and that special user needs permissions to use the printer. ? Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From scott at spigotlabs.com Sun Mar 25 12:41:24 2018 From: scott at spigotlabs.com (Scott Vitale) Date: Sun, 25 Mar 2018 16:41:24 +0000 Subject: [python-win32] win32com + Brother Printer + Django Message-ID: For this initial testing, I'm running Django directly. In production it will be run behind Apache/mod_wsgi. Setting sys.coinit_flags = 0 fixes the hang when running Django from a simple command line. This confirms to me that the issue is thread-related. What I'm seeing now is that the hang still occurs when running under the PyCharm debugger, but functions correctly in all other cases (run directly, run under Apache/mod_wsgi). It's no longer a blocking issue for me, but it would still be nice to understand root cause and if anything can be done (in my code or in PyCharm) to make the debugger function correctly. If you guys have any ideas on how to further debug or collect information on what might be hanging, that'd be greatly appreciated. Scott Vitale Founder & CEO 720.288.6336 @svvitale Learn about my perspectives on development, business, and my personal quest to shake up the #eventtech world on Medium On Sun, Mar 25, 2018 at 4:00 PM, wrote: > 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: win32com + Brother Printer + Django (Tim Roberts) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 24 Mar 2018 23:23:43 -0700 > From: Tim Roberts > To: Python-Win32 List > Subject: Re: [python-win32] win32com + Brother Printer + Django > Message-ID: <3023455A-9311-4480-A31F-5672DC4E6EB3 at probo.com> > Content-Type: text/plain; charset=utf-8 > > On Mar 23, 2018, at 9:44 AM, Scott Vitale wrote: > > > > I'm looking for some win32com help... I have a simple Python script that > creates a `Dispatch` object for a `bpac.Document` type (it's a Brother > printer SDK class). It works perfectly fine in a standalong script, but as > soon as I attempt to call this code from Django, it hangs on creating the > `Dispatch` object....so bizarre. > > > > I've tried calling `CoInitialize` in a variety of ways, no difference in > behavior. > > > > The other oddity is that I can create `bpac.Printer` objects with no > issue. It's only the `bpac.Document` type that hangs. Unfortunately I > don't have access to the library source and I'm not sure how to debug why > it's hanging. > > How are you running your Django app? Is it running as a service? Is it > networked, or directly connected? Microsoft does not recommend printing > from Windows services, in parts because of security considerations. Your > service is running as a special Windows user (unless you've configured it), > and that special user needs permissions to use the printer. > ? > 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 179, Issue 11 > ********************************************* > ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerardo.garcia at ggusoft.com Mon Mar 26 05:02:58 2018 From: gerardo.garcia at ggusoft.com (=?UTF-8?Q?Gerardo_Garc=C3=ADa_Urtiaga?=) Date: Mon, 26 Mar 2018 11:02:58 +0200 Subject: [python-win32] com_error creating VSS shadow copy (running as windows service) Message-ID: Hello, We have an application that launch a VSS (volume shadow copy), when the application is running as administrator user, the shadow copy is made correctly, but when the application is running as windows service the application has a crash: The instance's SvcRun() method failed Traceback (most recent call last): File "site-packages\win32\lib\win32serviceutil.py", line 835, in SvcRun File "backsec-service.py", line 29, in SvcDoRun File "backsec-service.py", line 36, in main File "backsec.py", line 877, in runBackups File "backsec.py", line 528, in doFullBackup File "backsec.py", line 515, in doVss File "backsec.py", line 490, in vssCreate File "site-packages\win32com\client_*init*_.py", line 72, in GetObject File "site-packages\win32com\client_*init*_.py", line 87, in Moniker com_error: (-2147221020, 'Sintaxis no v\xe1lida', None, None) %2: %3 The method "vssCreate" is this: def vssCreate(self,unidad="c:\\"): if os.name == "nt": wmi=win32com.client.GetObject("winmgmts:\\\\.\\root\\cimv2:Win32_ShadowCopy") createmethod = wmi.Methods_("Create") createparams = createmethod.InParameters createparams.Properties_[1].value=unidad results = wmi.ExecMethod_("Create",createparams) return results.Properties_[1].value return [] Thanks in advance ------------------------------------------------------------- *Gerardo Garc?a U.* GGUSOFT - Servicios de consultor?a de IT Email: gerardo.garcia at ggusoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason6543210 at hotmail.com Mon Mar 26 06:55:24 2018 From: jason6543210 at hotmail.com (Chang Dacool) Date: Mon, 26 Mar 2018 10:55:24 +0000 Subject: [python-win32] Get errors 7000 and 7009 Message-ID: The service will fail to start when we reboot the OS in some computers, when this happens we will get error code 7000 and 7009 in the event viewer. 7000: The ServiceName service failed to start due to the following error: The service did not respond to the start or control request in a timely fashion. 7009: A timeout was reached (30000 milliseconds) while waiting for The ServiceName service to connect. We checked our program, the Service timeout was before launching our program. We have no idea what made the Service timeout, we found a workaround after searching as link below. https://support.microsoft.com/en-us/help/922918/a-service-does-not-start-and-events-7000-and-7011-are-logged-in-window We don?t think this is a good solution because it is not a good idea to change user?s registry. Please help to provide the solution if there is any. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From timr at probo.com Mon Mar 26 13:09:40 2018 From: timr at probo.com (Tim Roberts) Date: Mon, 26 Mar 2018 10:09:40 -0700 Subject: [python-win32] com_error creating VSS shadow copy (running as windows service) In-Reply-To: References: Message-ID: <4e34daac-26c8-1002-ca3c-c590f64b4c21@probo.com> Gerardo Garc?a Urtiaga wrote: > > > We have an application that launch a VSS (volume shadow copy), when > the application is running as administrator user, the shadow copy is > made correctly, but when the application is running as windows service > the application has a crash: Under what user are you running the service?? If you are using LOCAL_SYSTEM, then you should have administrator privilege, but if you are using a regular user, then you do not. > com_error: (-2147221020, 'Sintaxis no v\xe1lida', None, None) > That's MK_E_SYNTAX, meaning the string could not be parsed in the current context. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From timr at probo.com Mon Mar 26 13:12:50 2018 From: timr at probo.com (Tim Roberts) Date: Mon, 26 Mar 2018 10:12:50 -0700 Subject: [python-win32] Get errors 7000 and 7009 In-Reply-To: References: Message-ID: <71af4bfb-574f-1ec0-d02d-d625eb830327@probo.com> Chang Dacool wrote: > > The service will fail to start when we reboot the OS in some > computers, when this happens we will get error code 7000 and 7009 in > the event viewer. > 7000: The ServiceName service failed to start due to the following error: > The service did not respond to the start or control request in a > timely fashion. > 7009: A timeout was reached (30000 milliseconds) while waiting for The > ServiceName service to connect. > > We checked our program, the Service timeout was before launching our > program. > I can't tell what you mean.? Are you saying your service sometimes takes more than 30 seconds to launch?? If so, then you need to figure out why it takes so long.? If you are waiting for some event during your startup, perhaps you can reorganize your code so that you defer some of your initialization until after you enter the main service loop. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From thopiekar at gmail.com Wed Mar 28 12:31:28 2018 From: thopiekar at gmail.com (Thomas Pietrowski) Date: Wed, 28 Mar 2018 18:31:28 +0200 Subject: [python-win32] Future of PyWin32 Message-ID: Dear pywin32-users, during the last months, I was using pywin32 to communicate between Cura and CAD software. It worked very well - better than comtypes, which was not fully working or accepting errors but didn't throw any errors. pywin32 convinced me because of its stability and in my opinion, this piece of software deserves some maintenance. Thus I would like to discuss with you about what you would like to see in the future done on pywin32. Here is my personal list of things, which need to be done soon: (1) Automated builds and tests on PRs Already began to work on this. There is one issue left, but I'm discussing with AppVeyor about a solution. (2) Syntax fixes and code-style. If I'm not wrong I saw mixed usage of tabs, 2-whitespace and 4-whitespace indents. Of course, I can be wrong and we are using 4-whitespaces everywhere, but I remember that I saw files using tabs and 2-whitespaces. It is boring work, but I can imagine, that people, who see this mixed usage, might get frightened. Also when it comes to code-style I would like to make everything well ordered. Eg. splitting long lines and splitting multiple options, so you can read the code without scrolling vertically too much. (3) Self-explaining variable names Some variables are using abbreviations. Instead, I would like to use full words, so the code is readable like a written book. Personally, I like this a lot because the source actually tells you what it is doing without any guesses. (4) Generated documentation I never did that before, but I can imagine, that someone else could prepare something like this. Using readthedocs would be great, so the docs are accessible for everyone. (5) More and extensive tests to ensure the quality of the code. (6) Focusing more on Python3 compatibility The end of life of Python2 is at 2020 and therefore I would suggest investing time into making the code compatible to Python3 asap. Many projects use Python-Six to get full compatibility, but I would suggest using Python-Nine because this module is written from the Python3 perspective. When Python2 becomes dead, I guess it will be easier to drop Python-Nine instead of Python-Six. Looking forward for a vivid discussion on this! With kind regards - Thomas Karl Pietrowski (aka thopiekar) -------------- next part -------------- An HTML attachment was scrubbed... URL: From timr at probo.com Wed Mar 28 12:55:02 2018 From: timr at probo.com (Tim Roberts) Date: Wed, 28 Mar 2018 09:55:02 -0700 Subject: [python-win32] Future of PyWin32 In-Reply-To: References: Message-ID: Thomas Pietrowski wrote: > > > (2) Syntax fixes and code-style. > > If I'm not wrong I saw mixed usage of tabs, 2-whitespace and > 4-whitespace?indents. Of course, I can be wrong and we are using > 4-whitespaces everywhere, but I remember that I saw files using tabs > and 2-whitespaces. > It is boring work, but I can imagine, that people, who see this mixed > usage, might get?frightened. > Also when it comes to code-style I would like to make everything well > ordered. Eg. splitting long lines and splitting multiple options, so > you can read the code without scrolling vertically too much. Remember that much of PyWin32 is automatically generated.? Automatically generated code is almost never pleasant to read. > (3) Self-explaining variable names > > Some variables are using abbreviations. Instead, I would like to use > full words, so the code is readable like a written book. Personally, I > like this a lot because the source actually?tells you what it is doing > without any guesses. Again, much of PyWin32 is automatically generated from the Win32 C API.? The names need to match the API, as terse as they may be. I am sympathetic to your plea, but renaming efforts like this are fraught with dangers.? It's awfully easy to cause duplicates or screw up the comments through an overactive search-and-replace. > (6) Focusing more on Python3 compatibility > > The end of life of Python2 is at 2020 and therefore I would suggest > investing time into making the code compatible to Python3 asap. PyWin32 has been Python 3 compatible for many years.? To what are you referring? -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From thopiekar at gmail.com Wed Mar 28 13:10:49 2018 From: thopiekar at gmail.com (Thomas Pietrowski) Date: Wed, 28 Mar 2018 19:10:49 +0200 Subject: [python-win32] Future of PyWin32 In-Reply-To: References: Message-ID: Hey Tim, thank you for your early feedback! > > (2) Syntax fixes and code-style. > > > > If I'm not wrong I saw mixed usage of tabs, 2-whitespace and > > 4-whitespace indents. Of course, I can be wrong and we are using > > 4-whitespaces everywhere, but I remember that I saw files using tabs > > and 2-whitespaces. > > It is boring work, but I can imagine, that people, who see this mixed > > usage, might get frightened. > > Also when it comes to code-style I would like to make everything well > > ordered. Eg. splitting long lines and splitting multiple options, so > > you can read the code without scrolling vertically too much. > > Remember that much of PyWin32 is automatically generated. Automatically > generated code is almost never pleasant to read. Hmm, I never saw any generator for this. Instead I see that people are doing additions manually already: https://github.com/mhammond/pywin32/pull/1176 Do you know or can you look up, where this generator is? It would be great to run this before build time. > > (3) Self-explaining variable names > > > > Some variables are using abbreviations. Instead, I would like to use > > full words, so the code is readable like a written book. Personally, I > > like this a lot because the source actually tells you what it is doing > > without any guesses. > > Again, much of PyWin32 is automatically generated from the Win32 C API. > The names need to match the API, as terse as they may be. > > I am sympathetic to your plea, but renaming efforts like this are > fraught with dangers. It's awfully easy to cause duplicates or screw up > the comments through an overactive search-and-replace. I know, that's why it makes fun to clean it up a bit. I have the experiance that I often hit superfluous variables in these situations. So for whatever is not generated, I would suggets to make use of the freedome of choosing meaningful variables. However, this is my opinion, which does not mean that this should be really done like that. :) > > (6) Focusing more on Python3 compatibility > > > > The end of life of Python2 is at 2020 and therefore I would suggest > > investing time into making the code compatible to Python3 asap. > > PyWin32 has been Python 3 compatible for many years. To what are you > referring? Well, we need to run setup3.py for Python3 installation, which is refactoring many files using lib2to3. With the end of Python2 I also expect that this module will become dead. These modules are not meant to be used forever, but creating a bridge over a period of time where different standards are used. And something that is already overdue is the use of print "bla" instead of print("bla"). Python 2.7 already understands print("bla") without any imports from the __future__ and since 2.6 is EOL, I would begin to fix that at first. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tritium-list at sdamon.com Wed Mar 28 13:20:35 2018 From: tritium-list at sdamon.com (Alex Walters) Date: Wed, 28 Mar 2018 13:20:35 -0400 Subject: [python-win32] Future of PyWin32 In-Reply-To: References: Message-ID: <5459e01d3c6b9$161e24c0$425a6e40$@sdamon.com> > > (6) Focusing more on Python3 compatibility > > > > The end of life of Python2 is at 2020 and therefore I would suggest > > investing time into making the code compatible to Python3 asap. > > PyWin32 has been Python 3 compatible for many years. To what are you > referring? > > Well, we need to run setup3.py for Python3 installation, which is refactoring many files using lib2to3. With the end of Python2 I also expect that this module will become dead. > These modules are not meant to be used forever, but creating a bridge over a period of time where different standards are used. > And something that is already overdue is the use of print "bla" instead of print("bla"). Python 2.7 already understands print("bla") without any imports from the __future__ and since 2.6 is EOL, I would begin to fix that at first All versions of python ?understand? `print(?foo?)`. In python 2, that just means `use the print statement to output the parenthesized string ?foo?, oh and the coder used poor practices and forgot the space`. Python 2.7 needs the future import to get rid of the print keyword. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thopiekar at gmail.com Thu Mar 29 12:48:22 2018 From: thopiekar at gmail.com (Thomas Pietrowski) Date: Thu, 29 Mar 2018 18:48:22 +0200 Subject: [python-win32] More info about Microsoft Foundation Classes (MFC) Message-ID: Hey, I have general questions about MFC and hope you can answer them. When compiling PyWin32 for Py2.7 and Py3.x I get successful builds, but setup.py can't find the MFC libraries, which are specified here: https://github.com/thopiekar/pywin32/blob/master/setup.py#L1059 for Python 2.7, Python 3.3 and Python3.4. This happens while using Appveyor and I contacted them about these "missing" files. One of the developers contacted me back and asked, whether mfc90*.dll is really needed for Python2.7. I think the question is quite eligible: Why are exactly these versions of MFC libraries strictly specified here? Isn't it possible to take the latest version, which is available? (Which is there for Python3.5 and 3.6.) Hope someone can explain so I can understand and find a solution for it, so we can build everything on Appveyor. Regards! -------------- next part -------------- An HTML attachment was scrubbed... URL: From timr at probo.com Thu Mar 29 13:15:09 2018 From: timr at probo.com (Tim Roberts) Date: Thu, 29 Mar 2018 10:15:09 -0700 Subject: [python-win32] More info about Microsoft Foundation Classes (MFC) In-Reply-To: References: Message-ID: <217cda91-337b-528b-db6d-2fcbd2739eab@probo.com> Thomas Pietrowski wrote: > > I have general questions about MFC and hope you can answer them. > When compiling PyWin32 for Py2.7 and Py3.x I get successful builds, > but setup.py can't find the MFC libraries, > which are specified here: > https://github.com/thopiekar/pywin32/blob/master/setup.py#L1059 > for Python 2.7, Python 3.3 and Python3.4. This happens while using > Appveyor and I contacted them about these "missing" files. > One of the developers contacted me back and asked, whether mfc90*.dll > is really needed for Python2.7. > I think the question is quite?eligible: Why are exactly these versions > of MFC libraries strictly specified here? > Isn't it possible to take the latest version, which is available? > (Which is there for Python3.5 and 3.6.) No.? It may not be obvious, but Python itself it entirely implemented in a DLL.? (Note that the "python.exe" command is only a couple dozen kilobytes.)? That DLL links to the dynamic version of the C run-time library.? To avoid conflicts in shared state and such, all of the DLLs it calls must either use a static C run-time library, or the same dynamic version that Python itself uses.? The same applies to MFC.? When an application or DLL links with MFC, it links to a specific version (e.g., mfc90.dll).? You can't substitute another. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From thopiekar at gmail.com Thu Mar 29 14:31:19 2018 From: thopiekar at gmail.com (Thomas Pietrowski) Date: Thu, 29 Mar 2018 20:31:19 +0200 Subject: [python-win32] More info about Microsoft Foundation Classes (MFC) In-Reply-To: <217cda91-337b-528b-db6d-2fcbd2739eab@probo.com> References: <217cda91-337b-528b-db6d-2fcbd2739eab@probo.com> Message-ID: Ok, so basically the same I know from Linux. But how likely is it that Python 2.7.14 (which is currently the latest version) is linked against old libraries? Isn't the Python Foundation updating their build system regularly, too? At the moment I'm quite convinced that the choice of an MFC version does not depend on Python, but on which version you built PyWin32. However, this is only my current feeling. Is our test script able to check a breakage here? So I would know by tests, whether it is safe to take newer MFC libraries or not? 2018-03-29 19:15 GMT+02:00 Tim Roberts : > Thomas Pietrowski wrote: > > > > I have general questions about MFC and hope you can answer them. > > When compiling PyWin32 for Py2.7 and Py3.x I get successful builds, > > but setup.py can't find the MFC libraries, > > which are specified here: > > https://github.com/thopiekar/pywin32/blob/master/setup.py#L1059 > > for Python 2.7, Python 3.3 and Python3.4. This happens while using > > Appveyor and I contacted them about these "missing" files. > > One of the developers contacted me back and asked, whether mfc90*.dll > > is really needed for Python2.7. > > I think the question is quite eligible: Why are exactly these versions > > of MFC libraries strictly specified here? > > Isn't it possible to take the latest version, which is available? > > (Which is there for Python3.5 and 3.6.) > > No. It may not be obvious, but Python itself it entirely implemented in > a DLL. (Note that the "python.exe" command is only a couple dozen > kilobytes.) That DLL links to the dynamic version of the C run-time > library. To avoid conflicts in shared state and such, all of the DLLs > it calls must either use a static C run-time library, or the same > dynamic version that Python itself uses. The same applies to MFC. When > an application or DLL links with MFC, it links to a specific version > (e.g., mfc90.dll). You can't substitute another. > > -- > Tim Roberts, timr at probo.com > Providenza & Boekelheide, Inc. > > _______________________________________________ > python-win32 mailing list > python-win32 at python.org > https://mail.python.org/mailman/listinfo/python-win32 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From timr at probo.com Thu Mar 29 15:41:53 2018 From: timr at probo.com (Tim Roberts) Date: Thu, 29 Mar 2018 12:41:53 -0700 Subject: [python-win32] More info about Microsoft Foundation Classes (MFC) In-Reply-To: References: <217cda91-337b-528b-db6d-2fcbd2739eab@probo.com> Message-ID: <0d63f7d0-6020-a0bb-860b-2a43b3337013@probo.com> Thomas Pietrowski wrote: > Ok, so basically the same I know from Linux. > But how likely is it that Python 2.7.14 (which is currently the latest > version) is linked against old libraries? > Isn't the Python Foundation updating their build system regularly, too? No.? In the past, the policy has been whatever build system is used for 2.7.0 will be used for all 2.7.x releases.? If they upgrade their Visual Studio, then all users have to upgrade, too, and in the Windows world that costs money. > At the moment I'm quite convinced that the choice of an MFC version > does not depend on Python, but on which version you built PyWin32. > However, this is only my current feeling. Right.? The core interpreter has no UI, and does not link to MFC. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc.