From robinjim@earthlink.net Sun Sep 1 13:29:53 2002 From: robinjim@earthlink.net (robin and jim) Date: Sun, 1 Sep 2002 06:29:53 -0600 Subject: [python-win32] BLT / Pmw / Tk installation problem Message-ID: <001301c251b3$470e23a0$b14ef4d1@robinjim> This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C25180.FB91DF20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, So far, I have not been able to get the Tk BLT extension package to work = with Python 2.2.1 and Pmw 1.1. I have tried placing the BLT24.dll various places, but the error = message, when running a sample script, is always: TclError: invalid command name "::blt::graph" Any suggestions would be appreciated. ------=_NextPart_000_0010_01C25180.FB91DF20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
So far, I have not been able = to get the=20 Tk BLT extension package to work with Python 2.2.1 and Pmw = 1.1.
 
I have tried placing the = BLT24.dll=20 various places, but the = error message,=20 when running a sample script, is always:
 
TclError: invalid command = name=20 "::blt::graph"
Any suggestions would be=20 appreciated.
------=_NextPart_000_0010_01C25180.FB91DF20-- From andy@agmweb.ca Sun Sep 8 06:21:10 2002 From: andy@agmweb.ca (Andy McKay) Date: Sat, 7 Sep 2002 22:21:10 -0700 Subject: [python-win32] XP sanity check Message-ID: <00a201c256f7$8c8989d0$89505018@cr582427a> Hi there, So I have an installer that works very sweetly to install a product (Plone actually http://www.plone.org) on Windows. At the end of the install it runs a python script (using 2.1.3) that happily installs a service. Or that is the plan except on XP. The log files I get back indicate that it has problems importing one of the following modules... win32gui, win32api, win32con, win32service, win32serviceutil, pywintypes I've increased logging even more to find out which one it is and what the problem might be, is there any known issue with these on XP or is this something else. I've googled to no success so I would doubt something this big would be wrong, but I wanted to do a sanity check before I hit something... Thanks -- Andy McKay Agmweb Consulting http://www.agmweb.ca From andy@agmweb.ca Sun Sep 8 07:10:18 2002 From: andy@agmweb.ca (Andy McKay) Date: Sat, 7 Sep 2002 23:10:18 -0700 Subject: [python-win32] XP sanity check References: <00a201c256f7$8c8989d0$89505018@cr582427a> Message-ID: <010301c256fe$694385f0$89505018@cr582427a> Okay ignore that. The problem was pywintypes which is really looking for PyWinTypes21.dll (in this case) which has to be in a system path, rather than in the Python path, which it doesnt appear to look through. It was in the Path on my box and so the script was working, but it wouldnt be on an installed machine and would hence fail. I think thats it anyway... Cheers. -- Andy McKay Agmweb Consulting http://www.agmweb.ca From reggie@merfinllc.com Mon Sep 9 17:48:41 2002 From: reggie@merfinllc.com (Reggie Dugard) Date: 09 Sep 2002 09:48:41 -0700 Subject: [python-win32] BLT / Pmw / Tk installation problem In-Reply-To: <001301c251b3$470e23a0$b14ef4d1@robinjim> References: <001301c251b3$470e23a0$b14ef4d1@robinjim> Message-ID: <1031590121.28889.6.camel@pika> Sorry about this being so delayed, but since I haven't seen any response, I though I'd reply anyway. I haven't done this in a while, but when I installed BLT the last time, I moved tcl\lib\tcl8.3\blt2.4 to tcl\tcl8.3\blt2.4 so that pkgIndex.tcl could be found and then I made sure that tcl\bin was in the PATH. Hope this helps. Reggie Dugard Merfin, LLC On Sun, 2002-09-01 at 05:29, robin and jim wrote: > Hello, > > So far, I have not been able to get the Tk BLT extension package to work with Python 2.2.1 and Pmw 1.1. > > I have tried placing the BLT24.dll various places, but the error message, when running a sample script, is always: > > TclError: invalid command name "::blt::graph" > > Any suggestions would be appreciated. From lbates@syscononline.com Tue Sep 10 14:22:11 2002 From: lbates@syscononline.com (Larry Bates) Date: Tue, 10 Sep 2002 08:22:11 -0500 Subject: [python-win32] membuf and memory leaks Message-ID: <2C1A673A677CD311988E00902773A6DD35CA9E@qbert.syscon-computers.com> I've recently been using Sam Rushing's calldll/membuf functions to interface to several .DLL based toolkits. It has taken quite a bit of digging to get these working properly, but I finally have them working to my satisfaction. Today it occurred to me that while I'm allocating memory buffers in my class interface to the .DLL, I'm never releasing them. I'm concerned that over time I will be leaking memory to every function call that must allocate a membuf. I'm not a C-programmer, but I looked over the source code to membuf function and there appears to be code there for deallocation of memory buffer (membuf_object_deallocate), but no entry point to it in the membuf_object_methods list to access it. Can anyone shed some light on proper method for destroying membuf instances after they are no longer required so that I don't have a memory leak? Thanks in advance for any assistance. Regards, Larry Bates Syscon, Inc. From jens.jorgensen@tallan.com Tue Sep 10 15:25:15 2002 From: jens.jorgensen@tallan.com (Jens B. Jorgensen) Date: Tue, 10 Sep 2002 09:25:15 -0500 Subject: [python-win32] membuf and memory leaks References: <2C1A673A677CD311988E00902773A6DD35CA9E@qbert.syscon-computers.com> Message-ID: <3D7E00CB.2010800@tallan.com> This is a cryptographically signed message in MIME format. --------------ms060500020302080400060108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Python objects take care of cleaning themselves up. You should find that the membuf_object_deallocate symbol is present in the definition of the PyTypeObject assigned to the tp_dealloc member. The runtime calls this when the object goes away. Larry Bates wrote: >I've recently been using Sam Rushing's calldll/membuf >functions to interface to several .DLL based toolkits. >It has taken quite a bit of digging to get these working >properly, but I finally have them working to my satisfaction. > >Today it occurred to me that while I'm allocating memory buffers >in my class interface to the .DLL, I'm never releasing them. >I'm concerned that over time I will be leaking memory to >every function call that must allocate a membuf. I'm not >a C-programmer, but I looked over the source code to membuf >function and there appears to be code there for deallocation >of memory buffer (membuf_object_deallocate), but no entry >point to it in the membuf_object_methods list to access it. >Can anyone shed some light on proper method for destroying >membuf instances after they are no longer required so that >I don't have a memory leak? > >Thanks in advance for any assistance. > >Regards, >Larry Bates >Syscon, Inc. > > > >_______________________________________________ >Python-win32 mailing list >Python-win32@python.org >http://mail.python.org/mailman/listinfo/python-win32 > > -- Jens B. Jorgensen jens.jorgensen@tallan.com "With a focused commitment to our clients and our people, we deliver value through customized technology solutions" --------------ms060500020302080400060108 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJmjCC AyswggKUoAMCAQICAwdmRzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDUwNjE0NDQ0MVoXDTAzMDUwNjE0NDQ0MVowZjES MBAGA1UEBBMJSm9yZ2Vuc2VuMQ0wCwYDVQQqEwRKZW5zMRcwFQYDVQQDEw5KZW5zIEpvcmdl bnNlbjEoMCYGCSqGSIb3DQEJARYZamVucy5qb3JnZW5zZW5AdGFsbGFuLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALpRu41RjbKdgKkVQ4+0r38pZjxYFENSvBSQDup8 NBBC1Dj9oUkuEHuwJYg0jjYO4GdOT2QBhozGP+MUuxqYXQv2Kd0gP9lkSMhCkn+XggvEnWb/ nbs8J8bYV2Od5juy5i+qXvkyTJ1F7wRACInEMyHZIOR5/z0OPycnhxOxLpzHf0bqjJQj5GVj vig+42VGFM3/p/pialli3DXQWJnkcFIy5sTZKK4ussztU1wBCXyMm0SdXjXTcxXjGnRRBO4D j+ACe4jn6NsEMvJF+89iA8pyWNQQYch9QiC3gfwxtauUvJPFnPfmYAknQSMpgAuUl1ORUz6p hHN/R143i5AIeIkCAwEAAaM2MDQwJAYDVR0RBB0wG4EZamVucy5qb3JnZW5zZW5AdGFsbGFu LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAEEPvKr3A9pLwIHD08Jx+SzY l3fWSOz92+hiHTIfgY0MkdPgzd59BylMiXcbsW0h/TGKpJgColgwsMvL8D5REMvtqlccPyRv hOvP1Mi5mDt+9wJt2+Upd3sTp5KyxPSPVTRk4y43byrGDnEch0t2dD1Z5eaKSOrAc0InpUFo F3sRMIIDKzCCApSgAwIBAgIDB2ZHMA0GCSqGSIb3DQEBBAUAMIGSMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRo YXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFs IEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwHhcNMDIwNTA2MTQ0NDQxWhcNMDMwNTA2MTQ0NDQx WjBmMRIwEAYDVQQEEwlKb3JnZW5zZW4xDTALBgNVBCoTBEplbnMxFzAVBgNVBAMTDkplbnMg Sm9yZ2Vuc2VuMSgwJgYJKoZIhvcNAQkBFhlqZW5zLmpvcmdlbnNlbkB0YWxsYW4uY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAulG7jVGNsp2AqRVDj7SvfylmPFgUQ1K8 FJAO6nw0EELUOP2hSS4Qe7AliDSONg7gZ05PZAGGjMY/4xS7GphdC/Yp3SA/2WRIyEKSf5eC C8SdZv+duzwnxthXY53mO7LmL6pe+TJMnUXvBEAIicQzIdkg5Hn/PQ4/JyeHE7EunMd/RuqM lCPkZWO+KD7jZUYUzf+n+mJqWWLcNdBYmeRwUjLmxNkori6yzO1TXAEJfIybRJ1eNdNzFeMa dFEE7gOP4AJ7iOfo2wQy8kX7z2IDynJY1BBhyH1CILeB/DG1q5S8k8Wc9+ZgCSdBIymAC5SX U5FTPqmEc39HXjeLkAh4iQIDAQABozYwNDAkBgNVHREEHTAbgRlqZW5zLmpvcmdlbnNlbkB0 YWxsYW4uY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAQQ+8qvcD2kvAgcPT wnH5LNiXd9ZI7P3b6GIdMh+BjQyR0+DN3n0HKUyJdxuxbSH9MYqkmAKiWDCwy8vwPlEQy+2q Vxw/JG+E68/UyLmYO373Am3b5Sl3exOnkrLE9I9VNGTjLjdvKsYOcRyHS3Z0PVnl5opI6sBz QielQWgXexEwggM4MIICoaADAgECAhBmRXK3zHT1z2N2RYTQLpEBMA0GCSqGSIb3DQEBBAUA MIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBl IFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN MDAwODMwMDAwMDAwWhcNMDQwODI3MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAb BgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFp bCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+ 0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbd YaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlm AC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEE BQADgYEAMbFLR135AXHl9VNsXXnWPZjAJhNigSKnEvgilegbSbcnewQ5uvzm8iTrkfq97A0q OPdQVahs9w2tTBu8A/S166JHn2yiDFiNMUIJEWywGmnRKxKyQF1q+XnQ6i4l3Yrk/NsNH50C 81rbyjz2ROomaYd/SJ7OpZ/nhNjJYmKtBcYxggMnMIIDIwIBATCBmjCBkjELMAkGA1UEBhMC WkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQK EwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJz b25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMHZkcwCQYFKw4DAhoFAKCCAWEwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwOTEwMTQyNTE2WjAjBgkq hkiG9w0BCQQxFgQUzMi4U2BWbAWJ5gjjH3+0WVJQsHgwUgYJKoZIhvcNAQkPMUUwQzAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwga0GCyqGSIb3DQEJEAILMYGdoIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UE CBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAyMDAwLjguMzACAwdmRzANBgkqhkiG9w0BAQEFAASCAQCGhn1wkkCPBgFUbMot gJHbKVSkLUmnHcXm7lMr2dSF51keaqX8+VlXyxocAvCKTc3M/Pt3FsJ/FXmohgniegMXkUTd A6BiR3/h+iqMosVBPP34tXOPdFA5Op0ixTDJTAa8lC7JPuSbxWF6SzUlsLUYvm20E+1ibTOL Iy90CA4TSOWlCgwtSyqB6vDYpuhz5BCnY6TWD32QpQZEJJyIxO2pjszlU+V7gql0qfjPRBHb jTUjSrKZ7BDSaWd/rxgiXf2KYMpOLY+yI6ayP70wPSXDXdJQxaC1JsCTtfbBRWl6ejbGFcUb Xe++qpoWii2MxO0iWyBDEe0Y8l0rf27Vg2V1AAAAAAAA --------------ms060500020302080400060108-- From robin@jessikat.fsnet.co.uk Tue Sep 10 15:04:06 2002 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Tue, 10 Sep 2002 15:04:06 +0100 Subject: [python-win32] membuf and memory leaks In-Reply-To: <2C1A673A677CD311988E00902773A6DD35CA9E@qbert.syscon-computers.com> References: <2C1A673A677CD311988E00902773A6DD35CA9E@qbert.syscon-computers.com> Message-ID: <9LnelJAWvff9EwiK@jessikat.demon.co.uk> In message <2C1A673A677CD311988E00902773A6DD35CA9E@qbert.syscon- computers.com>, Larry Bates writes >I've recently been using Sam Rushing's calldll/membuf >functions to interface to several .DLL based toolkits. >It has taken quite a bit of digging to get these working >properly, but I finally have them working to my satisfaction. > >Today it occurred to me that while I'm allocating memory buffers >in my class interface to the .DLL, I'm never releasing them. >I'm concerned that over time I will be leaking memory to >every function call that must allocate a membuf. I'm not >a C-programmer, but I looked over the source code to membuf >function and there appears to be code there for deallocation >of memory buffer (membuf_object_deallocate), but no entry >point to it in the membuf_object_methods list to access it. >Can anyone shed some light on proper method for destroying >membuf instances after they are no longer required so that >I don't have a memory leak? > >Thanks in advance for any assistance. > >Regards, >Larry Bates >Syscon, Inc. I think they get properly freed when they go out of scope. There's certainly a destructor method set on the membuf object. A simple test would be to put an allocation into a method or function and then call it repeatedly several thousand times. Check with procexp or task manager to see if the process size increases steadily. -- Robin Becker From BKaminski@mbisoftware.de Thu Sep 12 09:35:51 2002 From: BKaminski@mbisoftware.de (=?iso-8859-1?Q?=22Kaminski=2C_Bj=F6rn=22?=) Date: Thu, 12 Sep 2002 10:35:51 +0200 Subject: [python-win32] "importing" dll's with LoadLibrary Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C25A37.66AE3830 Content-Type: text/plain; charset="iso-8859-1" Hi List, I have a problem I cannot solve on my own: I used win32ui.LoadLibrary() to load a DLL File. The Functions returns some kind of DLL-Object. Then I use dllObject.AttachToMFC() But how can I use the newly attached Functions/Methods ? I haven't found anything about this... thx in advance bjoern (<-- my name) ------_=_NextPart_001_01C25A37.66AE3830 Content-Type: text/html; charset="iso-8859-1" "importing" dll's with LoadLibrary

Hi List,

I have a problem I cannot solve on my own:

I used win32ui.LoadLibrary() to load a DLL File. The Functions returns some kind of DLL-Object.
Then I use dllObject.AttachToMFC()
But how can I use the newly attached Functions/Methods ?

I haven't found anything about this...

thx in advance
bjoern (<-- my name)

------_=_NextPart_001_01C25A37.66AE3830-- From mrroach@uhg.net Thu Sep 12 15:24:23 2002 From: mrroach@uhg.net (Roach, Mark R.) Date: 12 Sep 2002 09:24:23 -0500 Subject: [python-win32] "importing" dll's with LoadLibrary In-Reply-To: References: Message-ID: <1031840663.6762.7.camel@tncorpmrr001.uhg> On Thu, 2002-09-12 at 03:35, "Kaminski, Bj=F6rn" wrote: > Hi List,=20 >=20 > I have a problem I cannot solve on my own:=20 >=20 > I used win32ui.LoadLibrary() to load a DLL File. The Functions returns > some kind of DLL-Object.=20 > Then I use dllObject.AttachToMFC()=20 > But how can I use the newly attached Functions/Methods ?=20 >=20 I wasn't able to directly use LoadLibrary, I have found windll/calldll/dynwin very useful. Documentation is a little sparse but google will turn up a couple of good examples. -Mark From tim.golden@viacom-outdoor.co.uk Thu Sep 12 15:41:21 2002 From: tim.golden@viacom-outdoor.co.uk (Tim Golden) Date: Thu, 12 Sep 2002 15:41:21 +0100 Subject: [python-win32] "importing" dll's with LoadLibrary Message-ID: <5F5E25C9F098D3119F140008C784457304DFD2E4@iron.ima.umn.edu> ... and in fact, someone has recently added a useful recipe on this = subject to the Python cookbook: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/146847 I freely admit I haven't used it yet, but the idea looks good. TJG -----Original Message----- From: Roach, Mark R. [mailto:mrroach@uhg.net] Sent: 12 September 2002 15:24 To: 'python-win32@python.org' Subject: Re: [python-win32] "importing" dll's with LoadLibrary On Thu, 2002-09-12 at 03:35, "Kaminski, Bj=F6rn" wrote: > Hi List,=20 >=20 > I have a problem I cannot solve on my own:=20 >=20 > I used win32ui.LoadLibrary() to load a DLL File. The Functions = returns > some kind of DLL-Object.=20 > Then I use dllObject.AttachToMFC()=20 > But how can I use the newly attached Functions/Methods ?=20 >=20 I wasn't able to directly use LoadLibrary, I have found windll/calldll/dynwin very useful. Documentation is a little sparse but google will turn up a couple of good examples. -Mark _______________________________________________ Python-win32 mailing list Python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32 ________________________________________________________________________= This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________= ________________________________________________________________________ This=20e-mail=20has=20been=20scanned=20for=20all=20viruses=20by=20Star=20I= nternet.=20The service=20is=20powered=20by=20MessageLabs.=20For=20more=20information=20on= =20a=20proactive anti-virus=20service=20working=20around=20the=20clock,=20around=20the=20gl= obe,=20visit: http://www.star.net.uk ________________________________________________________________________ From cphoenix@best.com Sat Sep 14 18:25:32 2002 From: cphoenix@best.com (Chris Phoenix) Date: Sat, 14 Sep 2002 12:25:32 -0500 Subject: [python-win32] Trouble loading any DLL in embedded Python Message-ID: <3D83710C.ECF7FDCB@best.com> I've embedded Python in an MFC application, linking to python21_d.lib (Python version 2.1.3). It appears to me that the embedded Python interpreter is refusing even to look for modules with extension .pyd. I wrote a simple file, deffoo.py, and put it in a new 'c:/pytest' directory. It imported correctly in both IDLE and my program. (I deleted deffoo.pyc between each test.) IDLE >>> import sys >>> sys.path.append('c:/pytest') >>> import deffoo >>> dir(deffoo) ['__builtins__', '__doc__', '__file__', '__name__', 'foo'] >>> Embedded, verbose mode on import sys sys.path.append('c:/pytest') import deffoo import deffoo # from c:/pytest\deffoo.py # wrote c:/pytest\deffoo.pyc dir(deffoo) >>> ['__builtins__', '__doc__', '__file__', '__name__', 'foo'] Then I renamed it from deffoo.py to deffoo.pyd. Here's what happened... IDLE, renamed extension >>> import sys >>> sys.path.append('c:/pytest') >>> import deffoo Traceback (most recent call last): File "", line 1, in ? import deffoo ImportError: DLL load failed: A device attached to the system is not functioning. >>> Embedded, renamed extension import sys sys.path.append('c:/pytest') import deffoo Traceback (most recent call last): File "", line 1, in ? ImportError: No module named deffoo [ At this point I moved deffoo.pyc back from the recycle bin] import deffoo import deffoo # precompiled from c:/pytest\deffoo.pyc So, it looks like the embedded version is simply not looking for files ending in .pyd, though it will look for .pyc files in the same directory. How can I fix this? Thanks, Chris -- Chris Phoenix cphoenix@best.com http://www.best.com/~cphoenix Interests: nanotechnology, dyslexia, caving, filk, SF, patent reform, stained glass, hang gliding From praveen.patil@silver-software.com Mon Sep 16 16:57:46 2002 From: praveen.patil@silver-software.com (Praveen Patil) Date: Mon, 16 Sep 2002 16:57:46 +0100 Subject: [python-win32] Please help solving the problem In-Reply-To: Message-ID: Hi , Please help me in solving the problem below. step 1: I have written three dlls : a.dll , b.dll , c.dll. a.dll contains funct_A(); b.dll contains funct_B(); c.dll contains funct_C(); step 2: I am copying a.dll to directory C:\Program Files\Python\DLLs and renaming as a.pyd similarly I am copying b.dll to directory C:\Program Files\Python\DLLs. I am not renaming as b.pyd I am copying c.dll to directory C:\Program Files\Python\DLLs and renaming as c.pyd So my C:\Program Files\Python\DLLs directory contain a.pyd , b.dll , c.pyd step 3: a)Python function func_pyA() calls funct_A() b)funct_A() call funct_B() c)funct_B() call funct_C() d)funct_C() call python fuction func_pyC() step 4: I am importing a.pyd and c.pyd in python program. import a import c step 5: I am having problem in importing 'a' because 'a' need to load b.dll and c.dll. But I copied c.dll as c.pyd. Please suggest me some solution. here is my code : 1)a.c (a.dll) ---------- void func_A(); 2)b.c (b.dll) ----------- void func_B(); 3)c.c( c.dll) ----------- void func_C(); 4) example.py --------- import a import c G_Logfile = None def TestFunction(): G_Logfile = open('Pytestfile.txt', 'w') G_Logfile.write("%s \n"%'I am writing python created text file') G_Logfile.close G_Logfile = None if __name__ == "__main__": a.func_A(); ..... ..... Please help me in solving the problem. Cheers, Praveen. [ The information contained in this e-mail is confidential and is intended for the named recipient only. If you are not the named recipient, please notify us by telephone on +44 (0)1249 442 430 immediately, destroy the message and delete it from your computer. Silver Software has taken every reasonable precaution to ensure that any attachment to this e-mail has been checked for viruses. However, we cannot accept liability for any damage sustained as a result of any such software viruses and advise you to carry out your own virus check before opening any attachment. Furthermore, we do not accept responsibility for any change made to this message after it was sent by the sender.] From mhammond@skippinet.com.au Mon Sep 16 23:08:55 2002 From: mhammond@skippinet.com.au (Mark Hammond) Date: Tue, 17 Sep 2002 08:08:55 +1000 Subject: [python-win32] Please help solving the problem In-Reply-To: Message-ID: > step 5: I am having problem in importing 'a' because 'a' need to > load b.dll > and c.dll. But I copied c.dll as c.pyd. > Please suggest me some solution. Dont rename the file. Either stick with the .dll version, or have the linker create the .pyd directly. Further, note that a standard DLL can not simply be used. The DLL must be a Python extension module. Check out the Python Embedding and Extending documentation for more details. If it is a standard Windows DLL you wish to call, look for the calldll/dynawin modules. Mark. From cphoenix@best.com Tue Sep 17 00:29:23 2002 From: cphoenix@best.com (Chris Phoenix) Date: Mon, 16 Sep 2002 18:29:23 -0500 Subject: [python-win32] Why does pyexpat_d crash my system? References: Message-ID: <3D866953.504E9366@best.com> I'm trying to build an app with embedded Python that can parse XML. Module xml loads module pyexpat, which is a DLL. I'm trying to use MFC 5 in Debug mode. I downloaded and installed Python 2.1. Then I downloaded the debug build and stashed all the files in a directory (...python21/libs). pyexpat wouldn't load when I did a debug build. It said a required DLL was missing but didn't say which one. It would load fine under release build, and under IDLE. This is the point where I posted a message to the list recently. Then I figured out the next step. I used regedit to add ...python21/libs to the Python path. Now when I try to load pyexpat under debug, I get a massive system crash. I get a dialog box about "program has caused an error in kernel32.dll and will now close." When you click the close box the dialog pops back up. I can't quit MFC or stop debugging. Frequently I can't even shut down the system and have to power-cycle it. The last time this happened the system didn't reboot correctly, so I'm not going to try it again just to tell you what the dialog box said. I think it was kernel32.dll but I'm not sure of that; but it crashed somewhere in the guts of the system, not in the Python stuff. sys.version for release build or IDLE: 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] For debug build: 2.1 (#15, Apr 16 2001, 18:26:26) [MSC 32 bit (Intel)] Any ideas? Thanks, Chris -- Chris Phoenix cphoenix@best.com http://www.best.com/~cphoenix Interests: nanotechnology, dyslexia, caving, filk, SF, patent reform, stained glass, hang gliding From praveen.patil@silver-software.com Thu Sep 19 14:43:11 2002 From: praveen.patil@silver-software.com (Praveen Patil) Date: Thu, 19 Sep 2002 14:43:11 +0100 Subject: [python-win32] How to pass array from C to python function In-Reply-To: Message-ID: Hi , I have problem in passing array to python function. Please help me passing array to python function. Here is my 'C' program ----------------------- void RECEIVE_IL_STATE_S( int Instance , int vital_data[5]) { PyObject*arglist; PyObject* ret; PyObject* mylist; int count; mylist = PyList_New(5); for (count=0; count< 5; count++) { myint = PyInt_FromLong(vital_data[count]); PyList_Append(mylist,myint); } arglist = Py_BuildValue("O", mylist); ret = PyEval_CallObject(my_callback , arglist); Py_DECREF(arglist); Py_DECREF(ret); } Here is my Python program ------------------------- G_Logfile = None def TestFunction(a): G_Logfile = open('Pytestfile.txt', 'w') G_Logfile.write("%d \n"% a[0]) G_Logfile.write("%d \n"% a[1]) G_Logfile.close Cheers, Praveen. [ The information contained in this e-mail is confidential and is intended for the named recipient only. If you are not the named recipient, please notify us by telephone on +44 (0)1249 442 430 immediately, destroy the message and delete it from your computer. Silver Software has taken every reasonable precaution to ensure that any attachment to this e-mail has been checked for viruses. However, we cannot accept liability for any damage sustained as a result of any such software viruses and advise you to carry out your own virus check before opening any attachment. Furthermore, we do not accept responsibility for any change made to this message after it was sent by the sender.] From jens.jorgensen@tallan.com Thu Sep 19 20:26:47 2002 From: jens.jorgensen@tallan.com (Jens B. Jorgensen) Date: Thu, 19 Sep 2002 14:26:47 -0500 Subject: [python-win32] How to pass array from C to python function References: Message-ID: <3D8A24F7.4080601@tallan.com> This is a cryptographically signed message in MIME format. --------------ms060600010905070202000002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Why are you appending to your list after you already made it 5 elements long? You are adding to the end of it by appending just as .append('something') adds a new element to the end of a list in Python. What you want to be doing is PyList_SetItem rather than PyList_Append. Also, I haven't actually tried calling Python from C(++) though I've written a number of Python extensions in C++. Do you really need to Py_BuildValue to pass the list to the function? I think this is not necessary. I believe in this case it actually will just return the object you pass it. If you need it to create a tuple then put parens around the "O". Praveen Patil wrote: >Hi , > >I have problem in passing array to python function. >Please help me passing array to python function. > >Here is my 'C' program >----------------------- > >void RECEIVE_IL_STATE_S( int Instance , int vital_data[5]) >{ > PyObject*arglist; > PyObject* ret; > PyObject* mylist; > int count; > > mylist = PyList_New(5); > for (count=0; count< 5; count++) { > myint = PyInt_FromLong(vital_data[count]); > PyList_Append(mylist,myint); > } > arglist = Py_BuildValue("O", mylist); > ret = PyEval_CallObject(my_callback , arglist); > Py_DECREF(arglist); > Py_DECREF(ret); >} > >Here is my Python program >------------------------- > >G_Logfile = None > >def TestFunction(a): > G_Logfile = open('Pytestfile.txt', 'w') > G_Logfile.write("%d \n"% a[0]) > G_Logfile.write("%d \n"% a[1]) > G_Logfile.close > > >Cheers, > >Praveen. > > > > > > > > > > > > > > > > > >[ The information contained in this e-mail is confidential and is intended for the named recipient only. If you are not the named recipient, please notify us by telephone on +44 (0)1249 442 430 immediately, destroy the message and delete it from your computer. Silver Software has taken every reasonable precaution to ensure that any attachment to this e-mail has been checked for viruses. However, we cannot accept liability for any damage sustained as a result of any such software viruses and advise you to carry out your own virus check before opening any attachment. Furthermore, we do not accept responsibility for any change made to this message after it was sent by the sender.] > >_______________________________________________ >Python-win32 mailing list >Python-win32@python.org >http://mail.python.org/mailman/listinfo/python-win32 > > -- Jens B. Jorgensen jens.jorgensen@tallan.com "With a focused commitment to our clients and our people, we deliver value through customized technology solutions" --------------ms060600010905070202000002 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJmjCC AyswggKUoAMCAQICAwdmRzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDUwNjE0NDQ0MVoXDTAzMDUwNjE0NDQ0MVowZjES MBAGA1UEBBMJSm9yZ2Vuc2VuMQ0wCwYDVQQqEwRKZW5zMRcwFQYDVQQDEw5KZW5zIEpvcmdl bnNlbjEoMCYGCSqGSIb3DQEJARYZamVucy5qb3JnZW5zZW5AdGFsbGFuLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALpRu41RjbKdgKkVQ4+0r38pZjxYFENSvBSQDup8 NBBC1Dj9oUkuEHuwJYg0jjYO4GdOT2QBhozGP+MUuxqYXQv2Kd0gP9lkSMhCkn+XggvEnWb/ nbs8J8bYV2Od5juy5i+qXvkyTJ1F7wRACInEMyHZIOR5/z0OPycnhxOxLpzHf0bqjJQj5GVj vig+42VGFM3/p/pialli3DXQWJnkcFIy5sTZKK4ussztU1wBCXyMm0SdXjXTcxXjGnRRBO4D j+ACe4jn6NsEMvJF+89iA8pyWNQQYch9QiC3gfwxtauUvJPFnPfmYAknQSMpgAuUl1ORUz6p hHN/R143i5AIeIkCAwEAAaM2MDQwJAYDVR0RBB0wG4EZamVucy5qb3JnZW5zZW5AdGFsbGFu LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAEEPvKr3A9pLwIHD08Jx+SzY l3fWSOz92+hiHTIfgY0MkdPgzd59BylMiXcbsW0h/TGKpJgColgwsMvL8D5REMvtqlccPyRv hOvP1Mi5mDt+9wJt2+Upd3sTp5KyxPSPVTRk4y43byrGDnEch0t2dD1Z5eaKSOrAc0InpUFo F3sRMIIDKzCCApSgAwIBAgIDB2ZHMA0GCSqGSIb3DQEBBAUAMIGSMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRo YXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFs IEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwHhcNMDIwNTA2MTQ0NDQxWhcNMDMwNTA2MTQ0NDQx WjBmMRIwEAYDVQQEEwlKb3JnZW5zZW4xDTALBgNVBCoTBEplbnMxFzAVBgNVBAMTDkplbnMg Sm9yZ2Vuc2VuMSgwJgYJKoZIhvcNAQkBFhlqZW5zLmpvcmdlbnNlbkB0YWxsYW4uY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAulG7jVGNsp2AqRVDj7SvfylmPFgUQ1K8 FJAO6nw0EELUOP2hSS4Qe7AliDSONg7gZ05PZAGGjMY/4xS7GphdC/Yp3SA/2WRIyEKSf5eC C8SdZv+duzwnxthXY53mO7LmL6pe+TJMnUXvBEAIicQzIdkg5Hn/PQ4/JyeHE7EunMd/RuqM lCPkZWO+KD7jZUYUzf+n+mJqWWLcNdBYmeRwUjLmxNkori6yzO1TXAEJfIybRJ1eNdNzFeMa dFEE7gOP4AJ7iOfo2wQy8kX7z2IDynJY1BBhyH1CILeB/DG1q5S8k8Wc9+ZgCSdBIymAC5SX U5FTPqmEc39HXjeLkAh4iQIDAQABozYwNDAkBgNVHREEHTAbgRlqZW5zLmpvcmdlbnNlbkB0 YWxsYW4uY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAQQ+8qvcD2kvAgcPT wnH5LNiXd9ZI7P3b6GIdMh+BjQyR0+DN3n0HKUyJdxuxbSH9MYqkmAKiWDCwy8vwPlEQy+2q Vxw/JG+E68/UyLmYO373Am3b5Sl3exOnkrLE9I9VNGTjLjdvKsYOcRyHS3Z0PVnl5opI6sBz QielQWgXexEwggM4MIICoaADAgECAhBmRXK3zHT1z2N2RYTQLpEBMA0GCSqGSIb3DQEBBAUA MIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBl IFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN MDAwODMwMDAwMDAwWhcNMDQwODI3MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAb BgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFp bCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+ 0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbd YaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlm AC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEE BQADgYEAMbFLR135AXHl9VNsXXnWPZjAJhNigSKnEvgilegbSbcnewQ5uvzm8iTrkfq97A0q OPdQVahs9w2tTBu8A/S166JHn2yiDFiNMUIJEWywGmnRKxKyQF1q+XnQ6i4l3Yrk/NsNH50C 81rbyjz2ROomaYd/SJ7OpZ/nhNjJYmKtBcYxggMnMIIDIwIBATCBmjCBkjELMAkGA1UEBhMC WkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQK EwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJz b25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMHZkcwCQYFKw4DAhoFAKCCAWEwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwOTE5MTkyNjQ3WjAjBgkq hkiG9w0BCQQxFgQULNL3yyM66UEVNnnGiyxf8Nqt7oswUgYJKoZIhvcNAQkPMUUwQzAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwga0GCyqGSIb3DQEJEAILMYGdoIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UE CBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAyMDAwLjguMzACAwdmRzANBgkqhkiG9w0BAQEFAASCAQB4mbitH0YVOx4Jf79y fymDhUFEcL5nbgSb8gWi2xvVnTrOYFJe8feBirhk+iS8ajsgqjqToZNw4QqM3ivtnBtvL7Zb fdGk5lEtkjpo/+YaCW00YOrQgFRbI9iUf/E3+GlvSKZ7PU2ySXTiqUWt5SXaLRWIPrBkvhdk HvlGVD3RV/B6PSGREj/c9UCYFXliJrte27h4YLHlMc19yDyaoLof8NUgQu4KaREnCpI21fcn zt6ZzZ5dzzPyRUBXjUzyg9kaGdW9JLIZBhcKVIZrLdAF0wBey+kdkAAabbDhbskTNTZ67efU AE/9PkYXTFFSkxmL8Asxpb7tYosteH6lZ31sAAAAAAAA --------------ms060600010905070202000002-- From Paul.Moore@atosorigin.com Wed Sep 25 14:08:11 2002 From: Paul.Moore@atosorigin.com (Moore, Paul) Date: Wed, 25 Sep 2002 14:08:11 +0100 Subject: [python-win32] Win32com events, multithreading, and re-entrancy Message-ID: <16E1010E4581B049ABC51D4975CEDB886198FE@UKDCX001.uk.int.atosorigin.com> I'm getting in a muddle trying to understand what's going on here... from win32com.client import DispatchWithEvents, constants import sys # sys.coinit_flags =3D 0 import pythoncom finished =3D 0 class ADOEvents: def OnWillConnect(self, str, user, pw, opt, sts, cn): # Must have this event, as if it is not handled, ADO assumes the # operation is cancelled, and raises an error (Operation = cancelled # by the user) pass def OnConnectComplete(self, error, status, connection): # print "Connected to", connection.Properties("Data Source") global finished finished =3D 1 c =3D DispatchWithEvents("ADODB.Connection", ADOEvents) str =3D "Provider=3Dmsdaora;Data Source=3DOEM.UKRUR053" c.Open(str, "system", "manager", constants.adAsyncConnect) while not finished: pythoncom.PumpWaitingMessages() print ".", This is an ADO program, trying to catch the ADO connection events. The = program works fine, *as long as* the print statement in = OnConnectComplete is commented out. Any attempt to access the connection = object from within the event handler causes Python to jump back into the = main busy wait loop, pumping messages and printing dots. I assume that this is somehow related to the internal multithreading and = serialisation that goes on in COM, but I don't know enough about that to = understand it. Trying to make the code free-threaded (assigning to = sys.coinit_flags - BTW, there's a bug in the documentation for = pythoncom.CoInitializeEx, which gives 2 variations on this name) didn't = seem to help. How do I do this? Is there any sample code which shows how to do this? = Mark Hammond's book doesn't cover ADO events, and I've read the = threading appendix and am still no wiser... Actually, on a more general note, is there any sample win32com code = around anywhere? The samples and tests included with the package are = useful, but they only go so far. Also some of them are out of date (I = was looking at the universal gateway stuff yesterday, and testuniv.py = doesn't even load, as "import univgw" no longer works :-() Thanks for any suggestions, Paul. From Paul.Moore@atosorigin.com Wed Sep 25 14:40:52 2002 From: Paul.Moore@atosorigin.com (Moore, Paul) Date: Wed, 25 Sep 2002 14:40:52 +0100 Subject: [python-win32] Another ADO question Message-ID: <16E1010E4581B049ABC51D4975CEDB885E2CC0@UKDCX001.uk.int.atosorigin.com> The ADO Recordset Field object seems to lose type information. No matter = what type of value I select from the database, RS.Fields(x).Value always = has unicode string type. Is this a limitation in ADO? Something not = getting passed back correctly? I have used makepy... It's not the end of the world for numbers (I can always convert back = from strings using int() or float() - although float() could lose = precision, I guess) but it's a real pain for dates. Why isn't the field = coming back as a VARIANT or the appropriate type? Can I make it do so? Sample code: # Set up c as an ADO connection rs =3D c.Execute("SELECT 1 FROM DUAL") print `rs.Fields(0).Value` # Gives u'1' rather than 1... Thanks, Paul. From jens.jorgensen@tallan.com Wed Sep 25 17:11:52 2002 From: jens.jorgensen@tallan.com (Jens B. Jorgensen) Date: Wed, 25 Sep 2002 11:11:52 -0500 Subject: [python-win32] Another ADO question References: <16E1010E4581B049ABC51D4975CEDB885E2CC0@UKDCX001.uk.int.atosorigin.com> Message-ID: <3D91E048.30902@tallan.com> Paul, Your code below is a little strange. First of all the Execute method of Connection returns a 2-tuple, not just a recordset. But anyhow. I do notice that from Oracle integer types seem to come back as a string but this doesn't seem to be the case for me for dates. On my system I observe: >>> rs, recs = cn.Execute('select sysdate from dual') >>> rs.Fields(0).Type == win32com.client.constants.adDBTimeStamp 1 >>> rs.Fields(0).Value >>> type(rs.Fields(0).Value) I do see the other behavior: >>> rs, recs = cn.Execute('select 1 from dual') >>> rs.Fields(0).Value u'1' However do not assume this behavior you're seeing is because of Python or ADO. For comparison's sake here's what I get talking to SQL Server 7: >>> rs, recs = sqls.Execute('select 1') >>> rs.Fields(0).Value 1 >>> type(rs.Fields(0).Value) I checked out the Provider-specific notes for my Oracle installation and it says that NUMBER types are returned as DBTYPE_VARNUMERIC. ADO maps this (if possible: the Oracle type supports greater precision than the underlying VARIANT type so if the number is bigger you get an exception) to VT_DECIMAL according the the KB article (http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q327557&). Looking at the source for the Python win32 extensions I can clearly see that VT_DECIMAL is simply converted to a string (see the function PyCom_PyObjectFromVariant in the source: http://www.pythonpros.com/cgi-bin/viewcvs.cgi/PyWin32/com/win32com/src/oleargs.cpp?rev=1.18&content-type=text/vnd.viewcvs-markup). So, this is the unfortunate state of things. A real source of the problem is that the VT_DECIMAL type is one which has no equivalent in Python with the requisite range. Probably the best solution is to create a new python class that would handle the values and support addition, subtraction, multiplication, etc. Minimally it should support conversion to float, int, and long integer types. Moore, Paul wrote: >The ADO Recordset Field object seems to lose type information. No matter what type of value I select from the database, RS.Fields(x).Value always has unicode string type. Is this a limitation in ADO? Something not getting passed back correctly? I have used makepy... > >It's not the end of the world for numbers (I can always convert back from strings using int() or float() - although float() could lose precision, I guess) but it's a real pain for dates. Why isn't the field coming back as a VARIANT or the appropriate type? Can I make it do so? > >Sample code: > > # Set up c as an ADO connection > rs = c.Execute("SELECT 1 FROM DUAL") > print `rs.Fields(0).Value` # Gives u'1' rather than 1... > >Thanks, >Paul. > >_______________________________________________ >Python-win32 mailing list >Python-win32@python.org >http://mail.python.org/mailman/listinfo/python-win32 > > -- Jens B. Jorgensen jens.jorgensen@tallan.com "With a focused commitment to our clients and our people, we deliver value through customized technology solutions" From mhammond@skippinet.com.au Thu Sep 26 03:29:14 2002 From: mhammond@skippinet.com.au (Mark Hammond) Date: Thu, 26 Sep 2002 12:29:14 +1000 Subject: [python-win32] Another ADO question In-Reply-To: <3D91E048.30902@tallan.com> Message-ID: Yes, this was my intent - to use one of Tim's number classes. I just wish there was a clear candidate ;) Mark. > -----Original Message----- > From: python-win32-admin@python.org > [mailto:python-win32-admin@python.org]On Behalf Of Jens B. Jorgensen > Sent: Thursday, 26 September 2002 2:12 AM > To: Moore, Paul > Cc: Python Win32 (E-mail) > Subject: Re: [python-win32] Another ADO question ... So, this is the unfortunate state of things. A real source of the problem is that the VT_DECIMAL type is one which has no equivalent in Python with the requisite range. Probably the best solution is to create a new python class that would handle the values and support addition, subtraction, multiplication, etc. Minimally it should support conversion to float, int, and long integer types. From mhammond@skippinet.com.au Thu Sep 26 03:29:13 2002 From: mhammond@skippinet.com.au (Mark Hammond) Date: Thu, 26 Sep 2002 12:29:13 +1000 Subject: [python-win32] Win32com events, multithreading, and re-entrancy In-Reply-To: <16E1010E4581B049ABC51D4975CEDB886198FE@UKDCX001.uk.int.atosorigin.com> Message-ID: > This is an ADO program, trying to catch the ADO connection > events. The program works fine, *as long as* the print statement > in OnConnectComplete is commented out. Any attempt to access the > connection object from within the event handler causes Python to > jump back into the main busy wait loop, pumping messages and > printing dots. It's not clear what the problem is. Accessing the connection object may well cause the main loop to trigger, but it should still work. What exactly is the problem? > I assume that this is somehow related to the internal > multithreading and serialisation that goes on in COM, but I don't > know enough about that to understand it. Trying to make the code > free-threaded (assigning to sys.coinit_flags - BTW, there's a bug > in the documentation for pythoncom.CoInitializeEx, which gives 2 > variations on this name) didn't seem to help. OVe fixed the doc. ADO is probably single or apartment threaded, thus it will not depend on your sys.coinit_flags. > How do I do this? Is there any sample code which shows how to do > this? Mark Hammond's book doesn't cover ADO events, and I've read > the threading appendix and am still no wiser... I'm not exactly clear what you are trying to do! Mark. From Paul.Moore@atosorigin.com Thu Sep 26 10:07:41 2002 From: Paul.Moore@atosorigin.com (Moore, Paul) Date: Thu, 26 Sep 2002 10:07:41 +0100 Subject: [python-win32] Another ADO question Message-ID: <16E1010E4581B049ABC51D4975CEDB88619901@UKDCX001.uk.int.atosorigin.com> From: Jens B. Jorgensen [mailto:jens.jorgensen@tallan.com] > Your code below is a little strange. First of all the > Execute method of Connection returns a 2-tuple, not just a > recordset. Yes, that was a bug in my code (fixed in the one I tested, but missed in = the cut & paste). Sorry. > But anyhow. I do notice that from Oracle integer > types seem to come back as a string but this doesn't seem to > be the case for me for dates. That's good news. I didn't try (this time) to generate an example with = dates - I'd had problems with dates previously and never fully = understood them. When I got this problem with numbers, I mistakenly = assumed the two were the same problem. > However do not assume this behavior you're seeing is > because of Python or ADO. For comparison's sake here's > what I get talking to SQL Server 7: That's good news. I didn't have a non-Oracle database to test against... > I checked out the Provider-specific notes for my Oracle > installation and it says that NUMBER types are returned > as DBTYPE_VARNUMERIC. ADO maps this (if possible: the > Oracle type supports greater precision than the underlying > VARIANT type so if the number is bigger you get an > exception) to VT_DECIMAL according the the KB article > (http://support.microsoft.com/default.aspx?scid=3DKB;EN-US;Q32>7557&). > Looking at the source for the Python win32 > extensions I can clearly see that VT_DECIMAL is > simply converted to a string (see the function > PyCom_PyObjectFromVariant in the source: > So, this is the unfortunate state of things. A real source > of the problem is that the VT_DECIMAL type is one which has > no equivalent in Python with the requisite range. Probably > the best solution is to create a new python class that > would handle the values and support addition, subtraction, > multiplication, etc. Minimally it should support conversion > to float, int, and long integer types. Agreed, this is unfortunate. And yes, I can see that we don't want to = end up losing information by "guessing" a less-precise type. However, = the DECIMAL->BSTR conversion is dependent on locale information, whereas = the conversion in float() is not. Hence in a locale where the decimal = separator is ",", float(rs(0).Value) may fail where the value is = something like 1.2... I don't see a useful way round this, short of some sort of DECIMAL type = in Python. However, if the DECIMAL value is a whole number (you can = check the bit pattern) would it be worth converting to a Python long? I = don't know how problematic it would be having a VARIANT converted to = different Python types depending on its *value* rather than just its = *type* - but it is true that for most of my work I deal with integral = values, and getting a Python integer (or long) would save 2 conversions, = and some of my time (forgetting and fixing the problem...) Nevertheless, thanks for the analysis of the problem. I hope my thoughts = on the matter are of some value... Paul. From Paul.Moore@atosorigin.com Thu Sep 26 10:38:27 2002 From: Paul.Moore@atosorigin.com (Moore, Paul) Date: Thu, 26 Sep 2002 10:38:27 +0100 Subject: [python-win32] Win32com events, multithreading, and re-entrancy Message-ID: <16E1010E4581B049ABC51D4975CEDB88619902@UKDCX001.uk.int.atosorigin.com> From: Mark Hammond [mailto:mhammond@skippinet.com.au] > > This is an ADO program, trying to catch the ADO connection > > events. The program works fine, *as long as* the print > > statement in OnConnectComplete is commented out. Any > > attempt to access the connection object from within the > > event handler causes Python to jump back into the main > > busy wait loop, pumping messages and printing dots. >=20 > It's not clear what the problem is. Accessing the connection > object may well cause the main loop to trigger, but it > should still work. What exactly is the problem? I can't follow the logic for the flow of control though my code. Worse, = in this particular (toy) example, the whole thing locks up, when it = should run to completion. I'll try to explain better below. >=20 > > I assume that this is somehow related to the internal > > multithreading and serialisation that goes on in COM, > > but I don't know enough about that to understand it. > > Trying to make the code free-threaded (assigning to > > sys.coinit_flags - BTW, there's a bug in the documentation > > for pythoncom.CoInitializeEx, which gives 2 variations on > > this name) didn't seem to help. >=20 > OVe fixed the doc. ADO is probably single or apartment > threaded, thus it will not depend on your sys.coinit_flags. OK, that's one possibility cleared up. > > How do I do this? Is there any sample code which shows > > how to do this? Mark Hammond's book doesn't cover ADO > > events, and I've read the threading appendix and am still > > no wiser... >=20 > I'm not exactly clear what you are trying to do! Sorry, I'll try to clarify. This specific code is "toy" code where I am = trying to understand how to use the ADO event model, specifically to try = to open a number of database connections in parallel (to minimise = application startup time - I'm ultimately looking at writing something = which opens connections to tens, if not hundreds, of separate databases, = and I'd rather the startup time didn't scale *too* linearly :-) I don't = know if this is a practical solution to my requirements, but I want to = understand how it works before giving up on it... OK, Given that, I'm trying to write some code which: 1. Initialises an ADO asynchronous connection. 2. Has an event handler which fires when the connection is made, and does "something" with the connection. In the long run, "something" could include firing off a separate thread to run some tasks[1] or setting an asynchronous query going, or whatever. For now, I'm just printing off the connection's data source. 3. Wait in some sort of loop until the work on the connection is complete (ultimately, this is my "wait for all the asynchronous tasks to finish" loop, but let's keep it simple for now). [1] I'm aware that when I start firing off threads, I have to worry a = lot harder about marshalling, apartments and the like. Save that until I = understand the basics (or find the whole thing so complex that I give up = :-)) So, my code goes something like this: --- cut here --- from win32com.client import DispatchWithEvents, constants import pythoncom finished =3D 0 # Flag for the wait loop from (3) to test class ADOEvents: # event handler class def OnWillConnect(self, str, user, pw, opt, sts, cn): # Must have this event, as if it is not handled, ADO assumes the # operation is cancelled, and raises an error (Operation = cancelled # by the user) pass def OnConnectComplete(self, error, status, connection): # Assume no errors, until we have the basic stuff # working. Now, "connection" should be an open # connection to my data source # Do the "something" from (2). For now, just # print the connection data source print "Connected to", connection.Properties("Data Source") # OK, our work is done. Let the main loop know global finished finished =3D 1 # Create the ADO connection object, and link the event # handlers into it c =3D DispatchWithEvents("ADODB.Connection", ADOEvents) # Initiate the asynchronous open str =3D "Provider=3Dmsdaora;Data Source=3DXXXX" user =3D "system" pw =3D "manager" c.Open(str, user, pw, constants.adAsyncConnect) # Sit in a loop, until our event handler (above) sets the # "finished" flag while not finished: # Pump messages so that COM gets a look in pythoncom.PumpWaitingMessages() # Print something on the screen, so I can see progress print ".", --- cut here --- Now, when I run this, I would expect to see a string of dots, = terminating with "Connected to XXXX". What I actually get is a string of = dots, then "Connected to", then the string of dots resumes indefinitely. The only explanation that I can see for this is that the access to = connection.Properties in the event, causes PumpWaitingMessages() in the = main loop to return, and restart the main loop (with "finished" not = set). Such flow of control makes no sense unless multiple threads are = present behind the scenes (which could easily be true with ADO/COM), but = if they are, I have no idea what the call to connection.Properties is = waiting on, or how to free it up. Ultimately, my event handler function appears not to be acting as an = atomic operation, but is somehow interfering with the main processing = loop. I am assuming that what is missing is in my understanding of how to code = this, rather than it being any sort of bug or problem. But I don't have = any idea where to go next. I've experimented in VB and VBScript. VB does = too much magic "behind the scenes" and I can't deduce why it works when = the Python code above does not. And VBScript appears to single-thread = everything, so that the whole event architecture becomes useless :-( As a last resort, I could try coding it in Perl, but I'm not sure what I = would learn from that (beyond that I don't like coding this sort of = thing in Perl :-)) At the moment, I'm close to thinking that I should just give up on COM, = ADO and events as a solution, and go with threads and the DB API, as if = I can't even get a simple test program working, I'm never going to get a = full application doing what I want, but that feels defeatist :-) Thanks for any help, Paul. From mhammond@skippinet.com.au Mon Sep 30 15:03:56 2002 From: mhammond@skippinet.com.au (Mark Hammond) Date: Tue, 1 Oct 2002 00:03:56 +1000 Subject: [python-win32] Win32com events, multithreading, and re-entrancy In-Reply-To: <16E1010E4581B049ABC51D4975CEDB88619902@UKDCX001.uk.int.atosorigin.com> Message-ID: ... > Now, when I run this, I would expect to see a string of dots, > terminating with "Connected to XXXX". What I actually get is a > string of dots, then "Connected to", then the string of dots > resumes indefinitely. > > The only explanation that I can see for this is that the access > to connection.Properties in the event, causes > PumpWaitingMessages() in the main loop to return, and restart the > main loop (with "finished" not set). Such flow of control makes > no sense unless multiple threads are present behind the scenes > (which could easily be true with ADO/COM), but if they are, I > have no idea what the call to connection.Properties is waiting > on, or how to free it up. Or, it is possible that the access to Properties() is raising an exception. Try a "finally" clause that prints after the call, or even a full-blown try/except clause using the traceback module. The next version of win32all should print these exceptions to stderr by default. > Ultimately, my event handler function appears not to be acting as > an atomic operation, but is somehow interfering with the main > processing loop. It is not clear what you expect by "atomic" here. The call could certainly trigger any number of "dots" before returning. I agree infinite dots is not expected ;) Ultimately though, what you are trying to do should work, assuming you don't expect the main thread to do much other than run an event loop as it is now. *dig dig* - I managed to get a test case working. There are a couple of problems, both of which would have shown up with printing the traceback as I mentioned above. def OnConnectComplete(self, error, status, connection): In this case, connection is a PyIUnknown object - this is strange, and VB obviously handles this better. I am fixing win32com so it does too. For now, you can use the code: connection = Dispatch(connection.QueryInterface(pythoncom.IID_IDispatch)) And everything will work. Mark. From Paul.Moore@atosorigin.com Mon Sep 30 15:20:04 2002 From: Paul.Moore@atosorigin.com (Moore, Paul) Date: Mon, 30 Sep 2002 15:20:04 +0100 Subject: [python-win32] Win32com events, multithreading, and re-entrancy Message-ID: <16E1010E4581B049ABC51D4975CEDB88619906@UKDCX001.uk.int.atosorigin.com> From: Mark Hammond [mailto:mhammond@skippinet.com.au] > Or, it is possible that the access to Properties() is raising > an exception. Try a "finally" clause that prints after the call, > or even a full-blown try/except clause using the traceback module. Ow! It never occurred to me that an exception could disappear = completely, even if it occurred in a thread. That is indeed exactly what = was happening. > The next version of win32all should print these exceptions to stderr > by default. That will be good. I don't know enough about Python's internals, clearly = - is this something specific to win32all, or could "normal" Python = thread code do the same? I notice that raising SystemExit from a = callback procedure doesn't exit the program either, something that the = Python thread documentation states will work, so I guess there's = something specific to win32all going on here. > It is not clear what you expect by "atomic" here. What I meant is that I don't understand what's going on clearly enough = :-) On rethinking, it becomes obvious that all I really meant was "I = don't understand why my code doesn't get past the access to = Properties()", to which the appropriate answer is "because it raised an = exception" :-) > *dig dig* - I managed to get a test case working. There are a > couple of problems, both of which would have shown up with > printing the traceback as I mentioned above. And they did, when I checked for myself. > def OnConnectComplete(self, error, status, connection): > > In this case, connection is a PyIUnknown object - this is strange, > and VB obviously handles this better. That's not particularly surprising to me :-( ADO appears to be the most = anything-other-than-VB-hostile interface I have ever seen. I've also had = trouble setting properties on a connection, but as there are about 10 = different ways of doing the same thing in ADO, I used one of the other = ones and ignored the problem... > I am fixing win32com so it does too. Thank you. > For now, you can use the code: > > connection =3D = Dispatch(connection.QueryInterface(pythoncom.IID_IDispatch)) > > And everything will work. And indeed it does. Thank you for looking into this for me. Paul. From olson@mcs.anl.gov Mon Sep 30 15:23:00 2002 From: olson@mcs.anl.gov (Robert Olson) Date: Mon, 30 Sep 2002 09:23:00 -0500 Subject: [python-win32] COM question Message-ID: <5.1.1.6.2.20020930092115.02658018@pop.mcs.anl.gov> I've tried on and off to use pythonCOM to access the control software for a Gentner AP device (cf www.clearone.com). I ran into problems, and ended up getting the following response from the vendor: >We have looked at the problem and and it relates to how automation works >with late binding languages such as VB. APServe was not written to be >friendly with these languages. The call "Unit.CreateMeter(CHANNEL_1, >METERTYPE_LVL, GRP_I, Meter)" last argument (meter) is passed in "ByVal". >VB's code completion sees this APServe COM interface method as ByVal because >VB does not allow the Interface pointer, Meter, to be "Set" through the >argument list via instantiation of the COM object, COMAPMeter. > >The call will work fine with launguges such as Visual C++ or Delphi. We did >not intend to have users writing software utilizing that interface and >therefore did not add the support in APServe. Unfortunutly, I do not know >of a work around for this problem. I am not familiar enough with Python to >make any recomendations there either. I'm wondering if that explanation makes sense, and if there's a way python could still be used (I'm pretty shaky on the actual details of COM under the covers). thanks, --bob From jens.jorgensen@tallan.com Mon Sep 30 17:19:30 2002 From: jens.jorgensen@tallan.com (Jens B. Jorgensen) Date: Mon, 30 Sep 2002 11:19:30 -0500 Subject: [python-win32] COM question References: <5.1.1.6.2.20020930092115.02658018@pop.mcs.anl.gov> Message-ID: <3D987992.5090604@tallan.com> Robert Olson wrote: > I've tried on and off to use pythonCOM to access the control software > for a Gentner AP device (cf www.clearone.com). I ran into problems, > and ended up getting the following response from the vendor: > >> We have looked at the problem and and it relates to how automation works >> with late binding languages such as VB. APServe was not written to be >> friendly with these languages. The call "Unit.CreateMeter(CHANNEL_1, >> METERTYPE_LVL, GRP_I, Meter)" last argument (meter) is passed in >> "ByVal". >> VB's code completion sees this APServe COM interface method as ByVal >> because >> VB does not allow the Interface pointer, Meter, to be "Set" through the >> argument list via instantiation of the COM object, COMAPMeter. >> >> The call will work fine with launguges such as Visual C++ or Delphi. >> We did >> not intend to have users writing software utilizing that interface and >> therefore did not add the support in APServe. Unfortunutly, I do not >> know >> of a work around for this problem. I am not familiar enough with >> Python to >> make any recomendations there either. > > > I'm wondering if that explanation makes sense, and if there's a way > python could still be used (I'm pretty shaky on the actual details of > COM under the covers). Python could certainly still be used. I'm pretty COM-savvy and I'm not sure I understand at all the explanation above. However if you want to get it working in Python you could always write a C++ extension module. That should work just dandy. Naturally the problem is that if the interface above is complex (and I'm guessing it is) you'll have a lot of code to write although none of it should be that difficult. > > thanks, > --bob > > > _______________________________________________ > Python-win32 mailing list > Python-win32@python.org > http://mail.python.org/mailman/listinfo/python-win32 -- Jens B. Jorgensen jens.jorgensen@tallan.com "With a focused commitment to our clients and our people, we deliver value through customized technology solutions"