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"