From dlenski at gmail.com  Wed Oct  1 19:17:19 2014
From: dlenski at gmail.com (Dan Lenski)
Date: Wed, 1 Oct 2014 17:17:19 +0000 (UTC)
Subject: [python-win32] getting underlying OLE object identity for win32com
	objects
Message-ID: <loom.20141001T191306-556@post.gmane.org>

Hi all,
I'm trying to figure out if there is a canonical way to get the identity 
of an object that has been wrapped by the win32com module, so that it 
can be compared to other objects.

For example, I can use this code to get a handle to the same object 
twice in the JMP application, but the two tables do not have the same 
"object identity" at the Python level:

    from win32com.client import gencache
    mod = gencache.GetModuleForProgID("JMP.Application")
    app = mod.Application()
    table = app.GetTableHandleFromName("Table1")
    same_table = app.GetTableHandleFromName("Table1")
    print table
    print same_table
    print table is same_table
    # <win32com.gen_py.DCD36DE0-78F8-11CF-9E68-
0020AF24E9FEx0x1x0.IAutoDataTable instance at 0x54418504>
    # <win32com.gen_py.DCD36DE0-78F8-11CF-9E68-
0020AF24E9FEx0x1x0.IAutoDataTable instance at 0x54432456>
    # False

It appears that all win32com OLE automation objects also have an 
_oleobj_ property. _oleobj_ is a PyIDispatch object 
(http://docs.activestate.com/activepython/3.1/pywin32/PyIDispatch.html), 
which only has a few methods, none of which seem pertinent to the 
question of object identity. However, the repr() of _oleobj_ seems to 
point to the underlying OLE automation object:

    print table._oleobj_
    print same_table._oleobj_
    # <PyIDispatch at 0x0000000003459530 with obj at 0x00000000003E2928>
    # <PyIDispatch at 0x0000000003459620 with obj at 0x00000000003E2928>

In order to confirm that two objects refer to the same underlying OLE 
object, I've resorted to parsing the `repr()` strings and comparing the 
hexadecimal addresses ("`obj at 0x...`").

Is there a better way to do this?

Thanks,
Dan Lenski

ps- I also posted this on StackOverflow 
(http://stackoverflow.com/questions/26068864) but it doesn't seem to 
have gotten many eyeballs there.


From timr at probo.com  Wed Oct  1 19:55:42 2014
From: timr at probo.com (Tim Roberts)
Date: Wed, 1 Oct 2014 10:55:42 -0700
Subject: [python-win32] getting underlying OLE object identity for
 win32com objects
In-Reply-To: <loom.20141001T191306-556@post.gmane.org>
References: <loom.20141001T191306-556@post.gmane.org>
Message-ID: <542C401E.5010508@probo.com>

Dan Lenski wrote:
> I'm trying to figure out if there is a canonical way to get the identity 
> of an object that has been wrapped by the win32com module, so that it 
> can be compared to other objects.
>
> For example, I can use this code to get a handle to the same object 
> twice in the JMP application, but the two tables do not have the same 
> "object identity" at the Python level:

Right.  They are two separate Python objects.

    print table
    print same_table
    print table is same_table

"is" will obviously fail, because it is checking for two identical
Python objects.  However, did you try the == operator?  The source code
seems to imply that the __eq__ operator is delegated to the _oleobj_
properties, which do know about COM object identity.


> In order to confirm that two objects refer to the same underlying OLE 
> object, I've resorted to parsing the `repr()` strings and comparing the 
> hexadecimal addresses ("`obj at 0x...`").
>
> Is there a better way to do this?

Assuming the straight "==" didn't work, I would think a better way would
be simply to compare the _oleobj_:

    if table._oleobj_ == same_table._oleobj_:

The source code in dynamic.py says the _oleobj_ members know how to
compare themselves.

-- 
Tim Roberts, timr at probo.com
Providenza & Boekelheide, Inc.


From dlenski at gmail.com  Wed Oct  1 20:06:43 2014
From: dlenski at gmail.com (Dan Lenski)
Date: Wed, 1 Oct 2014 18:06:43 +0000 (UTC)
Subject: [python-win32] getting underlying OLE object identity for
	win32com objects
References: <loom.20141001T191306-556@post.gmane.org>
 <542C401E.5010508@probo.com>
Message-ID: <loom.20141001T200355-647@post.gmane.org>

Tim Roberts <timr <at> probo.com> writes:
> Right.  They are two separate Python objects.
> 
>     print table
>     print same_table
>     print table is same_table
> 
> "is" will obviously fail, because it is checking for two identical
> Python objects.  However, did you try the == operator?  The source code
> seems to imply that the __eq__ operator is delegated to the _oleobj_
> properties, which do know about COM object identity.
> 

> Assuming the straight "==" didn't work, I would think a better way would
> be simply to compare the _oleobj_:
> 
>     if table._oleobj_ == same_table._oleobj_:
> 
> The source code in dynamic.py says the _oleobj_ members know how to
> compare themselves.

Thanks very much, Tim. I feel quite sheepish but didn't consider the == 
operator since I'm so used to using "is" for this purpose with Python 
objects.

Both versions that you suggested do the trick: table==same_table and 
table._oleobj_==same_table._oleobj_

Thanks,
Dan


From zturner at google.com  Fri Oct  3 19:07:00 2014
From: zturner at google.com (Zachary Turner)
Date: Fri, 3 Oct 2014 10:07:00 -0700
Subject: [python-win32] Embedding python in a Win32 application
Message-ID: <CAAErz9jdrGkybJUys2Bk46EJ4ccS1CPD+Y42uNfuSwG=fJn0Fw@mail.gmail.com>

Hi,

I'm trying to embed python 2.7 in a Win32 application and I'm running into
a host of problems.

Originally, my problem was that when compiling a debug version of my
application and linking against the python27.lib that I installed via the
packaged installer, I would just get strange behavior and memory corruption
and random crashes.  I finally determined that this was basically just
impossible, and if I want to use embedded python in a debug version of my
application, I need to build my own debug version of python.

This leads me to my first question: Was my original determination
accurate?  I think all of my problems would be solved automatically if I
could just embed release python in a debug version of my application.


Fast forward a bit.  I now have a custom debug build of python.  My debug
build of application links against it, and release build links against
release python.  So far so good, until I try to run "import ctypes".  Then
I get this:

Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> import ctypes
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "d:\python_src\Python-2.7.8\Lib\ctypes\__init__.py", line 10, in
<module>
    from _ctypes import Union, Structure, Array
ImportError: No module named _ctypes

Anybody have any idea what is going on here or how I might diagnose this?
It's obviously located the ctypes module that came with the source
distribution, so what error could it be running into?

For reference, the way I've built this is to download Python 2.7 source
distribution, open up the solution in Visual Studio, and build it, then
have my application link against the binaries that are put into the build's
output directories.  Is there a different way?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20141003/e08a0190/attachment.html>

From zachary.ware+pydev at gmail.com  Fri Oct  3 20:02:16 2014
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Fri, 3 Oct 2014 13:02:16 -0500
Subject: [python-win32] Embedding python in a Win32 application
In-Reply-To: <CAAErz9jdrGkybJUys2Bk46EJ4ccS1CPD+Y42uNfuSwG=fJn0Fw@mail.gmail.com>
References: <CAAErz9jdrGkybJUys2Bk46EJ4ccS1CPD+Y42uNfuSwG=fJn0Fw@mail.gmail.com>
Message-ID: <CAKJDb-OGN-YCQiPtDa8eTzbgHjZHR61iG25bOHhJ7x3qh8Ttog@mail.gmail.com>

On Fri, Oct 3, 2014 at 12:07 PM, Zachary Turner <zturner at google.com> wrote:
> Hi,
>
> I'm trying to embed python 2.7 in a Win32 application and I'm running into a
> host of problems.
>
> Originally, my problem was that when compiling a debug version of my
> application and linking against the python27.lib that I installed via the
> packaged installer, I would just get strange behavior and memory corruption
> and random crashes.  I finally determined that this was basically just
> impossible, and if I want to use embedded python in a debug version of my
> application, I need to build my own debug version of python.
>
> This leads me to my first question: Was my original determination accurate?
> I think all of my problems would be solved automatically if I could just
> embed release python in a debug version of my application.

I believe you're correct.  It is a somewhat unfortunate limitation;
it's on my radar to see if it can be relaxed, but I haven't had time
to look into it very closely yet.

> Fast forward a bit.  I now have a custom debug build of python.  My debug
> build of application links against it, and release build links against
> release python.  So far so good, until I try to run "import ctypes".  Then I
> get this:
>
> Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>>> import ctypes
> Traceback (most recent call last):
>   File "<console>", line 1, in <module>
>   File "d:\python_src\Python-2.7.8\Lib\ctypes\__init__.py", line 10, in
> <module>
>     from _ctypes import Union, Structure, Array
> ImportError: No module named _ctypes
>
> Anybody have any idea what is going on here or how I might diagnose this?
> It's obviously located the ctypes module that came with the source
> distribution, so what error could it be running into?

What do you get if you do 'import sys; print sys.path'?  Is the
directory that holds _ctypes.pyd included in sys.path?

> For reference, the way I've built this is to download Python 2.7 source
> distribution, open up the solution in Visual Studio, and build it, then have
> my application link against the binaries that are put into the build's
> output directories.  Is there a different way?

That ought to be about right.

-- 
Zach

From zturner at google.com  Fri Oct  3 22:45:17 2014
From: zturner at google.com (Zachary Turner)
Date: Fri, 3 Oct 2014 13:45:17 -0700
Subject: [python-win32] Embedding python in a Win32 application
In-Reply-To: <CAAErz9jdrGkybJUys2Bk46EJ4ccS1CPD+Y42uNfuSwG=fJn0Fw@mail.gmail.com>
References: <CAAErz9jdrGkybJUys2Bk46EJ4ccS1CPD+Y42uNfuSwG=fJn0Fw@mail.gmail.com>
Message-ID: <CAAErz9icO9V+1JZbh+31LFKEZ_9wc7Sc6k7kSVWiyqfRF=8rww@mail.gmail.com>

Apologies if this message appears incorrectly threaded.  Initially I didn't
subscribe to the list, so I'm replying to my own post instead of Zachary
Ware's.  Will do my best to keep the quoting intact though:

On Fri, Oct 3, 2014 at 1:02 PM, Zachary Ware
<zachary.ware+pydev at gmail.com> wrote:
>> On Fri, Oct 3, 2014 at 12:07 PM, Zachary Turner <zturner at google.com> wrote:

>> Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>>> import ctypes
>> Traceback (most recent call last):
>>   File "<console>", line 1, in <module>
>>   File "d:\python_src\Python-2.7.8\Lib\ctypes\__init__.py", line 10, in
>> <module>
>>     from _ctypes import Union, Structure, Array
>> ImportError: No module named _ctypes
>>
>> Anybody have any idea what is going on here or how I might diagnose this?
>> It's obviously located the ctypes module that came with the source
>> distribution, so what error could it be running into?
>
> What do you get if you do 'import sys; print sys.path'?  Is the
> directory that holds _ctypes.pyd included in sys.path?
>
>> For reference, the way I've built this is to download Python 2.7 source
>> distribution, open up the solution in Visual Studio, and build it, then have
>> my application link against the binaries that are put into the build's
>> output directories.  Is there a different way?
>
> That ought to be about right.

I did some more digging, and I think it's because ctypes is built as an
extension module, so _ctypes_d.pyd is in my build output directory
alongside python_d.exe and python27_d.dll, and not in my libs directory.  I
managed to get it working if I add my build output directory to my
PYTHONPATH.  Is there some way to package up my build and then install it
so that the directory structure is the same as if I had downloaded a
pre-packaged installer and installed it?  I don't think PYTHONPATH is set
by a default install, so something about the way it installs itself (maybe
python.exe is hardcoded to look in the DLLs subfolder?) allows an installed
build of python to work without PYTHONPATH.  I'd like to achieve the same
thing with my custom build.


On Fri, Oct 3, 2014 at 10:07 AM, Zachary Turner <zturner at google.com> wrote:

> Hi,
>
> I'm trying to embed python 2.7 in a Win32 application and I'm running into
> a host of problems.
>
> Originally, my problem was that when compiling a debug version of my
> application and linking against the python27.lib that I installed via the
> packaged installer, I would just get strange behavior and memory corruption
> and random crashes.  I finally determined that this was basically just
> impossible, and if I want to use embedded python in a debug version of my
> application, I need to build my own debug version of python.
>
> This leads me to my first question: Was my original determination
> accurate?  I think all of my problems would be solved automatically if I
> could just embed release python in a debug version of my application.
>
>
> Fast forward a bit.  I now have a custom debug build of python.  My debug
> build of application links against it, and release build links against
> release python.  So far so good, until I try to run "import ctypes".  Then
> I get this:
>
> Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
> >>> import ctypes
> Traceback (most recent call last):
>   File "<console>", line 1, in <module>
>   File "d:\python_src\Python-2.7.8\Lib\ctypes\__init__.py", line 10, in
> <module>
>     from _ctypes import Union, Structure, Array
> ImportError: No module named _ctypes
>
> Anybody have any idea what is going on here or how I might diagnose this?
> It's obviously located the ctypes module that came with the source
> distribution, so what error could it be running into?
>
> For reference, the way I've built this is to download Python 2.7 source
> distribution, open up the solution in Visual Studio, and build it, then
> have my application link against the binaries that are put into the build's
> output directories.  Is there a different way?
>
> Thanks
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20141003/d45739c5/attachment-0001.html>

From zturner at google.com  Sat Oct  4 00:33:21 2014
From: zturner at google.com (Zachary Turner)
Date: Fri, 3 Oct 2014 15:33:21 -0700
Subject: [python-win32] Embedding python in a Win32 application
In-Reply-To: <CAAErz9icO9V+1JZbh+31LFKEZ_9wc7Sc6k7kSVWiyqfRF=8rww@mail.gmail.com>
References: <CAAErz9jdrGkybJUys2Bk46EJ4ccS1CPD+Y42uNfuSwG=fJn0Fw@mail.gmail.com>
 <CAAErz9icO9V+1JZbh+31LFKEZ_9wc7Sc6k7kSVWiyqfRF=8rww@mail.gmail.com>
Message-ID: <CAAErz9hN7Q5+6E297M=tw9Zgnwu4MgRStuSNns_Zvj0Uj2hEiw@mail.gmail.com>

Also, to answer your the question more specifically about sys.path, when I
run my debug build of python_d.exe from the commandl ine and print sys.path
I get this:

>>> sys.path
['', 'D:\\python_src\\Python-2.7.8\\Lib',
'D:\\src\\llvm\\build\\ninja\\lib\\site-packages',
'd:\\python_src\\Python-2.7.8\\pcbuild\\python27_d.zip',
'd:\\python_src\\Python-2.7.8\\DLLs',
'd:\\python_src\\Python-2.7.8\\lib\\plat-win',
'd:\\python_src\\Python-2.7.8\\lib\\lib-tk',
'd:\\python_src\\Python-2.7.8\\pcbuild', 'd:\\python_src\\Python-2.7.8',
'd:\\python_src\\Python-2.7.8\\lib\\site-packages']
[43489 refs]

When I do the same thing from my embedded interpreter, I get this:
['D:\\src\\llvm\x08uild\ninja\x08in',
'D:\\src\\llvm\x08uild\ninja\x08in\\..\\lib\\site-packages',
'D:\\python_src\\Python-2.7.8\\Lib',
'D:\\src\\llvm\\build\\ninja\\lib\\site-packages',
'D:\\python_src\\Python-2.7.8\\PCbuild\\python27_d.zip',
'C:\\Python27\\Lib', 'C:\\Python27\\DLLs', 'C:\\Python27\\Lib\\lib-tk',
'D:\\src\\llvm\\build\\ninja', 'D:\\src\\llvm\\build\\ninja\\bin',
'C:\\Python27', 'C:\\Python27\\lib\\site-packages', '.']

The first two junked up entries are bugs I need to fix, but not relevant
really to this.  It's worth noting that
d:\\python_src\\Python-2.7.8\\pcbuild is not included.  That's probably
where the problem lies.  Both of these were run with the same system
environment, so there's no difference there.  Someone running python_d.exe
gets d:\\python_src\\Python-2.7.8\\pcbuild in sys.path, but linking against
the DLL doesn't.

One more thing that i find very strange is the presence of C:\Python27\* in
my sys.path here.  None of this is in my PATH environment variable or my
PYTHONPATH.  Where is it picking this up from?  It's where I have installed
a pre-packaged version of Python, but since it's not in my path or in any
global setting that I'm aware of, I'm not sure where this would be coming
from.


On Fri, Oct 3, 2014 at 1:45 PM, Zachary Turner <zturner at google.com> wrote:

> Apologies if this message appears incorrectly threaded.  Initially I
> didn't subscribe to the list, so I'm replying to my own post instead of
> Zachary Ware's.  Will do my best to keep the quoting intact though:
>
> On Fri, Oct 3, 2014 at 1:02 PM, Zachary Ware <zachary.ware+pydev at gmail.com> wrote:
> >> On Fri, Oct 3, 2014 at 12:07 PM, Zachary Turner <zturner at google.com> wrote:
>
> >> Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
> >>>> import ctypes
> >> Traceback (most recent call last):
> >>   File "<console>", line 1, in <module>
> >>   File "d:\python_src\Python-2.7.8\Lib\ctypes\__init__.py", line 10, in
> >> <module>
> >>     from _ctypes import Union, Structure, Array
> >> ImportError: No module named _ctypes
> >>
> >> Anybody have any idea what is going on here or how I might diagnose this?
> >> It's obviously located the ctypes module that came with the source
> >> distribution, so what error could it be running into?
> >
> > What do you get if you do 'import sys; print sys.path'?  Is the
> > directory that holds _ctypes.pyd included in sys.path?
> >
> >> For reference, the way I've built this is to download Python 2.7 source
> >> distribution, open up the solution in Visual Studio, and build it, then have
> >> my application link against the binaries that are put into the build's
> >> output directories.  Is there a different way?
> >
> > That ought to be about right.
>
> I did some more digging, and I think it's because ctypes is built as an
> extension module, so _ctypes_d.pyd is in my build output directory
> alongside python_d.exe and python27_d.dll, and not in my libs directory.  I
> managed to get it working if I add my build output directory to my
> PYTHONPATH.  Is there some way to package up my build and then install it
> so that the directory structure is the same as if I had downloaded a
> pre-packaged installer and installed it?  I don't think PYTHONPATH is set
> by a default install, so something about the way it installs itself (maybe
> python.exe is hardcoded to look in the DLLs subfolder?) allows an installed
> build of python to work without PYTHONPATH.  I'd like to achieve the same
> thing with my custom build.
>
>
> On Fri, Oct 3, 2014 at 10:07 AM, Zachary Turner <zturner at google.com>
> wrote:
>
>> Hi,
>>
>> I'm trying to embed python 2.7 in a Win32 application and I'm running
>> into a host of problems.
>>
>> Originally, my problem was that when compiling a debug version of my
>> application and linking against the python27.lib that I installed via the
>> packaged installer, I would just get strange behavior and memory corruption
>> and random crashes.  I finally determined that this was basically just
>> impossible, and if I want to use embedded python in a debug version of my
>> application, I need to build my own debug version of python.
>>
>> This leads me to my first question: Was my original determination
>> accurate?  I think all of my problems would be solved automatically if I
>> could just embed release python in a debug version of my application.
>>
>>
>> Fast forward a bit.  I now have a custom debug build of python.  My debug
>> build of application links against it, and release build links against
>> release python.  So far so good, until I try to run "import ctypes".  Then
>> I get this:
>>
>> Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or
>> Ctrl-D.
>> >>> import ctypes
>> Traceback (most recent call last):
>>   File "<console>", line 1, in <module>
>>   File "d:\python_src\Python-2.7.8\Lib\ctypes\__init__.py", line 10, in
>> <module>
>>     from _ctypes import Union, Structure, Array
>> ImportError: No module named _ctypes
>>
>> Anybody have any idea what is going on here or how I might diagnose
>> this?  It's obviously located the ctypes module that came with the source
>> distribution, so what error could it be running into?
>>
>> For reference, the way I've built this is to download Python 2.7 source
>> distribution, open up the solution in Visual Studio, and build it, then
>> have my application link against the binaries that are put into the build's
>> output directories.  Is there a different way?
>>
>> Thanks
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20141003/1a0d3210/attachment.html>

From zachary.ware+pydev at gmail.com  Sat Oct  4 08:45:34 2014
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Sat, 4 Oct 2014 01:45:34 -0500
Subject: [python-win32] Embedding python in a Win32 application
In-Reply-To: <CAAErz9hN7Q5+6E297M=tw9Zgnwu4MgRStuSNns_Zvj0Uj2hEiw@mail.gmail.com>
References: <CAAErz9jdrGkybJUys2Bk46EJ4ccS1CPD+Y42uNfuSwG=fJn0Fw@mail.gmail.com>
 <CAAErz9icO9V+1JZbh+31LFKEZ_9wc7Sc6k7kSVWiyqfRF=8rww@mail.gmail.com>
 <CAAErz9hN7Q5+6E297M=tw9Zgnwu4MgRStuSNns_Zvj0Uj2hEiw@mail.gmail.com>
Message-ID: <CAKJDb-NEcHtqpxjtzgVk6jZN1z=0wBnTHGqvSk=A=Fdczb6w+w@mail.gmail.com>

On Fri, Oct 3, 2014 at 5:33 PM, Zachary Turner <zturner at google.com> wrote:
> Also, to answer your the question more specifically about sys.path, when I
> run my debug build of python_d.exe from the commandl ine and print sys.path
> I get this:
>
>>>> sys.path
> ['', 'D:\\python_src\\Python-2.7.8\\Lib',
> 'D:\\src\\llvm\\build\\ninja\\lib\\site-packages',
> 'd:\\python_src\\Python-2.7.8\\pcbuild\\python27_d.zip',
> 'd:\\python_src\\Python-2.7.8\\DLLs',
> 'd:\\python_src\\Python-2.7.8\\lib\\plat-win',
> 'd:\\python_src\\Python-2.7.8\\lib\\lib-tk',
> 'd:\\python_src\\Python-2.7.8\\pcbuild', 'd:\\python_src\\Python-2.7.8',
> 'd:\\python_src\\Python-2.7.8\\lib\\site-packages']
> [43489 refs]
>
> When I do the same thing from my embedded interpreter, I get this:
> ['D:\\src\\llvm\x08uild\ninja\x08in',
> 'D:\\src\\llvm\x08uild\ninja\x08in\\..\\lib\\site-packages',
> 'D:\\python_src\\Python-2.7.8\\Lib',
> 'D:\\src\\llvm\\build\\ninja\\lib\\site-packages',
> 'D:\\python_src\\Python-2.7.8\\PCbuild\\python27_d.zip',
> 'C:\\Python27\\Lib', 'C:\\Python27\\DLLs', 'C:\\Python27\\Lib\\lib-tk',
> 'D:\\src\\llvm\\build\\ninja', 'D:\\src\\llvm\\build\\ninja\\bin',
> 'C:\\Python27', 'C:\\Python27\\lib\\site-packages', '.']
>
> The first two junked up entries are bugs I need to fix, but not relevant
> really to this.  It's worth noting that
> d:\\python_src\\Python-2.7.8\\pcbuild is not included.  That's probably
> where the problem lies.  Both of these were run with the same system
> environment, so there's no difference there.  Someone running python_d.exe
> gets d:\\python_src\\Python-2.7.8\\pcbuild in sys.path, but linking against
> the DLL doesn't.

I will note that I haven't done any embedding of Python myself, so I'm
shooting in the dark a little bit here.  From what I've read trying to
figure this out (and from other background information picked up over
the past few years), the default setting of sys.path is an unholy
mess.  Some values are defaults based on the value of sys.prefix (or
sys.exec_prefix, both of which are based on sys.executable, set by
Py_SetProgramName), values can come from the environment (PYTHONPATH),
and on Windows, values can even come from the registry (which is where
C:\Python27\* came from in your embedded interpreter).  sys.path is
manipulated by Py_Initialize, PySys_SetArgv, and site.py (usually in
that order, I think).   And the rules also change on Windows when
python(_d).exe detects that it's in a build directory rather than an
installed location.

I think your best solution here might be to just set sys.path yourself
(https://docs.python.org/2/c-api/sys.html#c.PySys_SetPath) just after
Py_Initialize, overwriting the default values.  This also gives you
the added benefit of being able to put the Python libraries (Lib/**.py
and PCbuild/*.pyd) wherever you want them (even in the same folder, or
even a zipfile), rather than trying to fit them into where Python
expects them to be, and you don't run the risk of running Python code
that really probably shouldn't have been findable anyway.

Hope this is of some help,
-- 
Zach

From ajay.kanade at autodesk.com  Mon Oct  6 17:53:59 2014
From: ajay.kanade at autodesk.com (Ajay Kanade)
Date: Mon, 6 Oct 2014 15:53:59 +0000
Subject: [python-win32] Embedding python in a Win32 application
In-Reply-To: <CAKJDb-NEcHtqpxjtzgVk6jZN1z=0wBnTHGqvSk=A=Fdczb6w+w@mail.gmail.com>
References: <CAAErz9jdrGkybJUys2Bk46EJ4ccS1CPD+Y42uNfuSwG=fJn0Fw@mail.gmail.com>
 <CAAErz9icO9V+1JZbh+31LFKEZ_9wc7Sc6k7kSVWiyqfRF=8rww@mail.gmail.com>
 <CAAErz9hN7Q5+6E297M=tw9Zgnwu4MgRStuSNns_Zvj0Uj2hEiw@mail.gmail.com>
 <CAKJDb-NEcHtqpxjtzgVk6jZN1z=0wBnTHGqvSk=A=Fdczb6w+w@mail.gmail.com>
Message-ID: <4A92B97165B91948BDF683A2E3F4D7352D7BE159@005-TK5MPN1-002.MGDADSK.autodesk.com>

Zachary,

Python embedding in another application (win32) is done quite a bit by many (me too). My suggestion to you is:
-	Build both release & debug
-	After the builds, do the "Install Python" steps at https://wiki.python.org/moin/VS2012 for *both* release & debug builds. Note: I had to modify manual_install.py because I did not build tcl (something like that)
-	If above step become too much, do a proper installation of python (.msi) & replace all .pyds & dlls & exes with your built ones
-	Idea is to keep both *.pyd and *_d.pyd (& *.dll & *_d.dll) in the same folders. This way both release & debug of your app will execute
-	Link release/debug python libs with your release/debug exe respectively
-	Take a look at http://stackoverflow.com/questions/1387906/c-with-python-embedding-crash-if-python-not-installed/2970407#2970407 to see how you can package python with your exe. Also it shows how you can set PythonHome in your C code
-	If you are going to create .pyds of your own (using swig or boost), note that you must have xyz.pyd & xyz_d.pyd for release & debug respectively
-	Python27.dll, Python27_d.dll & the Python27/DLLs & Python27/Lib are the only things needed at runtime

My suggestion for you would be to make it work for a pure python installation (you just have to build the python27.dll) before building the whole python thing yourself.

Hope it helps. I may have missed something. But that should give you an idea.

Ajay

-----Original Message-----
From: python-win32 [mailto:python-win32-bounces+ajay.kanade=autodesk.com at python.org] On Behalf Of Zachary Ware
Sent: Saturday, October 04, 2014 2:46 AM
To: python-win32 at python.org
Subject: Re: [python-win32] Embedding python in a Win32 application

On Fri, Oct 3, 2014 at 5:33 PM, Zachary Turner <zturner at google.com> wrote:
> Also, to answer your the question more specifically about sys.path, 
> when I run my debug build of python_d.exe from the commandl ine and 
> print sys.path I get this:
>
>>>> sys.path
> ['', 'D:\\python_src\\Python-2.7.8\\Lib',
> 'D:\\src\\llvm\\build\\ninja\\lib\\site-packages',
> 'd:\\python_src\\Python-2.7.8\\pcbuild\\python27_d.zip',
> 'd:\\python_src\\Python-2.7.8\\DLLs',
> 'd:\\python_src\\Python-2.7.8\\lib\\plat-win',
> 'd:\\python_src\\Python-2.7.8\\lib\\lib-tk',
> 'd:\\python_src\\Python-2.7.8\\pcbuild', 
> 'd:\\python_src\\Python-2.7.8', 
> 'd:\\python_src\\Python-2.7.8\\lib\\site-packages']
> [43489 refs]
>
> When I do the same thing from my embedded interpreter, I get this:
> ['D:\\src\\llvm\x08uild\ninja\x08in',
> 'D:\\src\\llvm\x08uild\ninja\x08in\\..\\lib\\site-packages',
> 'D:\\python_src\\Python-2.7.8\\Lib',
> 'D:\\src\\llvm\\build\\ninja\\lib\\site-packages',
> 'D:\\python_src\\Python-2.7.8\\PCbuild\\python27_d.zip',
> 'C:\\Python27\\Lib', 'C:\\Python27\\DLLs', 
> 'C:\\Python27\\Lib\\lib-tk', 'D:\\src\\llvm\\build\\ninja', 
> 'D:\\src\\llvm\\build\\ninja\\bin',
> 'C:\\Python27', 'C:\\Python27\\lib\\site-packages', '.']
>
> The first two junked up entries are bugs I need to fix, but not 
> relevant really to this.  It's worth noting that 
> d:\\python_src\\Python-2.7.8\\pcbuild is not included.  That's 
> probably where the problem lies.  Both of these were run with the same 
> system environment, so there's no difference there.  Someone running 
> python_d.exe gets d:\\python_src\\Python-2.7.8\\pcbuild in sys.path, 
> but linking against the DLL doesn't.

I will note that I haven't done any embedding of Python myself, so I'm shooting in the dark a little bit here.  From what I've read trying to figure this out (and from other background information picked up over the past few years), the default setting of sys.path is an unholy mess.  Some values are defaults based on the value of sys.prefix (or sys.exec_prefix, both of which are based on sys.executable, set by Py_SetProgramName), values can come from the environment (PYTHONPATH), and on Windows, values can even come from the registry (which is where
C:\Python27\* came from in your embedded interpreter).  sys.path is manipulated by Py_Initialize, PySys_SetArgv, and site.py (usually in
that order, I think).   And the rules also change on Windows when
python(_d).exe detects that it's in a build directory rather than an installed location.

I think your best solution here might be to just set sys.path yourself
(https://docs.python.org/2/c-api/sys.html#c.PySys_SetPath) just after Py_Initialize, overwriting the default values.  This also gives you the added benefit of being able to put the Python libraries (Lib/**.py and PCbuild/*.pyd) wherever you want them (even in the same folder, or even a zipfile), rather than trying to fit them into where Python expects them to be, and you don't run the risk of running Python code that really probably shouldn't have been findable anyway.

Hope this is of some help,
--
Zach
_______________________________________________
python-win32 mailing list
python-win32 at python.org
https://mail.python.org/mailman/listinfo/python-win32

From bramesh.vt at gmail.com  Tue Oct  7 19:44:13 2014
From: bramesh.vt at gmail.com (Bharath Ramesh)
Date: Tue, 7 Oct 2014 10:44:13 -0700
Subject: [python-win32] Issues building pywin32 from source
Message-ID: <CAFUX4q9nE=TGSrF9KQxO7_OEg=XL7QCS6aMmSiiQgc-WqMvLMA@mail.gmail.com>

I cloned the pywin32 repository and I am trying to build version 219
locally on my windows setup so that I can then use it in our project.
I am hitting an issue where during the install step I get the
following error as pop up window

"Python for Win32
The application can not locate win32ui.pyd (or Python) (126)
The specified module could not be found."

If I dismiss the window I get another error after a little bit

"pythonservice.exe
The program can't start because pywintypes34.dll is missing from your computer.
Try reinstall the program to fix this problem."

The way I am building pywin32 is as follows

1) Set the path to MSSdk and set DISTUTILS_USE_SDK=1
2) Our automated build server using mingw so
env -u MAKE python setup3.py build
3) My install step is
python setup3.py --no-compile --skip-build --prefix d:\\build\\pywin32\\staging

I am trying to figure out why I am getting the error about unable to
locate win32ui.pyd and missing pywintypes34.dll.

Ideally, what I am would like to achive is after I build pywin32. I
would want to place all the files required for pywin32 in a staging
location that I can later package as part of my deliverables. Once I
cx_Freeze my application.

From mc at mclaveau.com  Wed Oct  8 08:33:58 2014
From: mc at mclaveau.com (mc@mclaveau)
Date: Wed, 08 Oct 2014 08:33:58 +0200
Subject: [python-win32] Win7 + P27 ; very tiny thingy
Message-ID: <5434DAD6.9020801@mclaveau.com>

Hi!

Not really a problem, instead a (very tiny) thingy.

Under Windows (7/64), and working-DIR "C:\mescripts", with this very big 
script (named "test.py"):
      import os,os.path
      temp=os.path.dirname(__file__)

How I launch, and result:
     C:\python27\python.exe  C:\mescripts\test.py        => temp OK
     C:\python27\python.exe  test.py        => temp is empty
     test.py        => temp OK

OK, it's no linked to Pywin32, but "?a fait avancer le smilblick"
and... sorry for my bad english.

@-salutations
-- 
Michel Claveau




-- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20141008/d2a6efd0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sign-styloplume.GIF
Type: image/gif
Size: 9129 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-win32/attachments/20141008/d2a6efd0/attachment.gif>

From skippy.hammond at gmail.com  Fri Oct 10 07:00:24 2014
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Fri, 10 Oct 2014 16:00:24 +1100
Subject: [python-win32] Issues building pywin32 from source
In-Reply-To: <CAFUX4q9nE=TGSrF9KQxO7_OEg=XL7QCS6aMmSiiQgc-WqMvLMA@mail.gmail.com>
References: <CAFUX4q9nE=TGSrF9KQxO7_OEg=XL7QCS6aMmSiiQgc-WqMvLMA@mail.gmail.com>
Message-ID: <543767E8.7070601@gmail.com>

You probably need to run "pywin32_postinstall.py -install" as many of 
the .pyd etc files don't know how to locate pywintypesxx.dll when it is 
just in the build dir.

HTH,

MArk

On 8/10/2014 4:44 AM, Bharath Ramesh wrote:
> I cloned the pywin32 repository and I am trying to build version 219
> locally on my windows setup so that I can then use it in our project.
> I am hitting an issue where during the install step I get the
> following error as pop up window
>
> "Python for Win32
> The application can not locate win32ui.pyd (or Python) (126)
> The specified module could not be found."
>
> If I dismiss the window I get another error after a little bit
>
> "pythonservice.exe
> The program can't start because pywintypes34.dll is missing from your computer.
> Try reinstall the program to fix this problem."
>
> The way I am building pywin32 is as follows
>
> 1) Set the path to MSSdk and set DISTUTILS_USE_SDK=1
> 2) Our automated build server using mingw so
> env -u MAKE python setup3.py build
> 3) My install step is
> python setup3.py --no-compile --skip-build --prefix d:\\build\\pywin32\\staging
>
> I am trying to figure out why I am getting the error about unable to
> locate win32ui.pyd and missing pywintypes34.dll.
>
> Ideally, what I am would like to achive is after I build pywin32. I
> would want to place all the files required for pywin32 in a staging
> location that I can later package as part of my deliverables. Once I
> cx_Freeze my application.
> _______________________________________________
> python-win32 mailing list
> python-win32 at python.org
> https://mail.python.org/mailman/listinfo/python-win32
>


From jrs.idx at ntlworld.com  Tue Oct 14 15:37:32 2014
From: jrs.idx at ntlworld.com (John Sampson)
Date: Tue, 14 Oct 2014 14:37:32 +0100
Subject: [python-win32] pythoncom
Message-ID: <543D271C.90902@ntlworld.com>

I have a proprietary program with a command interface implemented as an 
ActiveX DLL. Importing win32com.client and pythoncom, I can call 
functions from Python scripts. Some of these work properly in 32-bit 
Windows 7, but others only in 64-bit Windows. Is this because pythoncom 
is designed to work with Windows 64-bit only? Is there a version that 
works with 32-bit Windows?

Regards

John Sampson

From timr at probo.com  Tue Oct 14 19:15:09 2014
From: timr at probo.com (Tim Roberts)
Date: Tue, 14 Oct 2014 10:15:09 -0700
Subject: [python-win32] pythoncom
In-Reply-To: <543D271C.90902@ntlworld.com>
References: <543D271C.90902@ntlworld.com>
Message-ID: <543D5A1D.7040506@probo.com>

John Sampson wrote:
> I have a proprietary program with a command interface implemented as an 
> ActiveX DLL. Importing win32com.client and pythoncom, I can call 
> functions from Python scripts. Some of these work properly in 32-bit 
> Windows 7, but others only in 64-bit Windows. Is this because pythoncom 
> is designed to work with Windows 64-bit only? Is there a version that 
> works with 32-bit Windows?

Python is available is both 32-bit and 64-bit forms.  You can use either
one on a 64-bit operating system.

However, a 64-bit process cannot call a 32-bit DLL, nor the reverse.  If
your proprietary program is a 32-bit application, then you need to
install and use a 32-bit Python in order to use it.

You can't install 64-bit product on a 32-bit Windows system, so if you
are having trouble on a 32-bit Windows system, then there is something
else going on.

-- 
Tim Roberts, timr at probo.com
Providenza & Boekelheide, Inc.


From jrs.idx at ntlworld.com  Wed Oct 15 15:50:04 2014
From: jrs.idx at ntlworld.com (John Sampson)
Date: Wed, 15 Oct 2014 14:50:04 +0100
Subject: [python-win32]  pythoncom
In-Reply-To: <543D5A1D.7040506@probo.com>
References: <543D271C.90902@ntlworld.com> <543D5A1D.7040506@probo.com>
Message-ID: <543E7B8C.6020805@ntlworld.com>

On 14/10/2014 18:15, Tim Roberts wrote:
> John Sampson wrote:
>> I have a proprietary program with a command interface implemented as an
>> ActiveX DLL. Importing win32com.client and pythoncom, I can call
>> functions from Python scripts. Some of these work properly in 32-bit
>> Windows 7, but others only in 64-bit Windows. Is this because pythoncom
>> is designed to work with Windows 64-bit only? Is there a version that
>> works with 32-bit Windows?
> Python is available is both 32-bit and 64-bit forms.  You can use either
> one on a 64-bit operating system.
>
> However, a 64-bit process cannot call a 32-bit DLL, nor the reverse.  If
> your proprietary program is a 32-bit application, then you need to
> install and use a 32-bit Python in order to use it.
>
> You can't install 64-bit product on a 32-bit Windows system, so if you
> are having trouble on a 32-bit Windows system, then there is something
> else going on.
>

The interface has a function which returns a string from an array of 
strings as it is supposed to
in Windows 64-bit, or if called from VBA.
In 32-bit Windows Python it returns the number of the item in the array 
instead.

Regards

John Sampson

From skippy.hammond at gmail.com  Thu Oct 16 08:48:44 2014
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Thu, 16 Oct 2014 17:48:44 +1100
Subject: [python-win32] pythoncom
In-Reply-To: <543E7B8C.6020805@ntlworld.com>
References: <543D271C.90902@ntlworld.com> <543D5A1D.7040506@probo.com>
 <543E7B8C.6020805@ntlworld.com>
Message-ID: <543F6A4C.6050001@gmail.com>

On 16/10/2014 12:50 AM, John Sampson wrote:
> The interface has a function which returns a string from an array of
> strings as it is supposed to
> in Windows 64-bit, or if called from VBA.
> In 32-bit Windows Python it returns the number of the item in the array
> instead.

So to be clear - you have a 64bit version of Windows, and you've 
installed python and pywin32 in both 32 and 64bit variants, *and* you've 
installed the COM object in both 64 and 32bit variants - is that correct?

If so, I suspect the problem might be that you've run makepy (or 
previously called EnsureDispatch etc) in the 64bit version but not in 
the 32bit version - check the lib\site-packages\win32com\gen_py 
directory and you might find the generated support in the 64bit version 
and not the other.

HTH,

Mark


From jrs.idx at ntlworld.com  Thu Oct 16 11:25:10 2014
From: jrs.idx at ntlworld.com (John Sampson)
Date: Thu, 16 Oct 2014 10:25:10 +0100
Subject: [python-win32]  pythoncom
In-Reply-To: <543F6A4C.6050001@gmail.com>
References: <543D271C.90902@ntlworld.com> <543D5A1D.7040506@probo.com>
 <543E7B8C.6020805@ntlworld.com> <543F6A4C.6050001@gmail.com>
Message-ID: <543F8EF6.4070105@ntlworld.com>

On 16/10/2014 07:48, Mark Hammond wrote:
> On 16/10/2014 12:50 AM, John Sampson wrote:
>> The interface has a function which returns a string from an array of
>> strings as it is supposed to
>> in Windows 64-bit, or if called from VBA.
>> In 32-bit Windows Python it returns the number of the item in the array
>> instead.
>
> So to be clear - you have a 64bit version of Windows, and you've 
> installed python and pywin32 in both 32 and 64bit variants, *and* 
> you've installed the COM object in both 64 and 32bit variants - is 
> that correct?
>
> If so, I suspect the problem might be that you've run makepy (or 
> previously called EnsureDispatch etc) in the 64bit version but not in 
> the 32bit version - check the lib\site-packages\win32com\gen_py 
> directory and you might find the generated support in the 64bit 
> version and not the other.
>
> HTH,
>
> Mark
>
>
I have the 32-bit version of Python on both computers (64-bit Windows 
and 32-bit Windows), installed from the MSI file, so I have not 
personally run makepy on either.
The COM object is part of the same software package, installed on both 
computers. They are different versions, but I thought I had excluded 
that this was where the problem lay. I will have to review this. Looking 
at lib\site-packages\win32com\gen_py I see more files in the version 
causing trouble than in the version that works OK.
How would I recognise the generated support you mention?

Regards

John Sampson

From blairdhall at gmail.com  Fri Oct 17 03:47:51 2014
From: blairdhall at gmail.com (Blair Hall)
Date: Fri, 17 Oct 2014 14:47:51 +1300
Subject: [python-win32] Error R6034 when I import uuid
Message-ID: <CAJeTVArsN8Vp_e6cnF3yUf6cUC4uHUJ6ggmsKUeDCzcKA_=uKw@mail.gmail.com>

I have a small python COM server that worked fine with Excel until I
decided to import the standard Python 'uuid' module.

Now I get the Windows Runtime error R6034 "An application has made an
attempt to load the C runtime library incorrectly"

I there anything that I can do to fix this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20141017/902c26c9/attachment.html>

From vernondcole at gmail.com  Fri Oct 17 09:18:51 2014
From: vernondcole at gmail.com (Vernon D. Cole)
Date: Fri, 17 Oct 2014 01:18:51 -0600
Subject: [python-win32] Error R6034 when I import uuid
In-Reply-To: <CAJeTVArsN8Vp_e6cnF3yUf6cUC4uHUJ6ggmsKUeDCzcKA_=uKw@mail.gmail.com>
References: <CAJeTVArsN8Vp_e6cnF3yUf6cUC4uHUJ6ggmsKUeDCzcKA_=uKw@mail.gmail.com>
Message-ID: <CAH-ZgAdAjxrn9OUtNAvNe4T=AP7w3Et3bc6UaNMPos3sh1-hRQ@mail.gmail.com>

Which version of Python are you running?
32 or 64 bit?
Which version of pywin32?
Which version of Windows?
Can you make a small test case that will demonstrate the error?


On Thu, Oct 16, 2014 at 7:47 PM, Blair Hall <blairdhall at gmail.com> wrote:

> I have a small python COM server that worked fine with Excel until I
> decided to import the standard Python 'uuid' module.
>
> Now I get the Windows Runtime error R6034 "An application has made an
> attempt to load the C runtime library incorrectly"
>
> I there anything that I can do to fix this?
>
> _______________________________________________
> python-win32 mailing list
> python-win32 at python.org
> https://mail.python.org/mailman/listinfo/python-win32
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20141017/606d828f/attachment.html>

From bramesh.vt at gmail.com  Sat Oct 18 00:19:32 2014
From: bramesh.vt at gmail.com (Bharath Ramesh)
Date: Fri, 17 Oct 2014 15:19:32 -0700
Subject: [python-win32] Error while building pywin32
Message-ID: <CAFUX4q_f8AvL=8zEki8_iatGSSB+_3A1FdPEg+_G0LYGzUqQyQ@mail.gmail.com>

Hi,
I am trying to build 64-bit pywin32 locally. While building I come
across this error when the shell extension is being built

com\win32comext\shell\src\PyIAsyncOperation.h(11) : error C2143:
syntax error : missing ';' before '*'

I am trying to figure out what could be possibly wrong that could be
causing this issue.

From blairdhall at gmail.com  Sat Oct 18 02:24:05 2014
From: blairdhall at gmail.com (Blair Hall)
Date: Sat, 18 Oct 2014 13:24:05 +1300
Subject: [python-win32] Error R6034 when I import uuid
In-Reply-To: <CAH-ZgAdAjxrn9OUtNAvNe4T=AP7w3Et3bc6UaNMPos3sh1-hRQ@mail.gmail.com>
References: <CAJeTVArsN8Vp_e6cnF3yUf6cUC4uHUJ6ggmsKUeDCzcKA_=uKw@mail.gmail.com>
 <CAH-ZgAdAjxrn9OUtNAvNe4T=AP7w3Et3bc6UaNMPos3sh1-hRQ@mail.gmail.com>
Message-ID: <CAJeTVAqZfD9cxHgikJs+4vVLkwc02rOakbR324BV3MrBbRD78w@mail.gmail.com>

OK, sorry, here are some more details.

I have Python 2.7.8, win32, running on a Windows7 64-bit home machine (not
professional).

Here is my python script:

#---------------------------------------
import pythoncom

#import uuid

class Bug:

    _reg_clsid_ = '{E3D5F332-F080-47B3-A319-A3A0E287E466}'
    _reg_progid_ = "BugServer"
    _public_methods_ = ['hello']

    def __init__(self):
        pass

#------------------------------------------------------------------------
    def hello(self,who):
        return "Hello {}".format(who)

#============================================================================
if __name__=='__main__':

    # cmd options: --register --debug and --unregister
    import win32com.server.register
    win32com.server.register.UseCommandLine(Bug)
#---------------------------------------------


As it is, this works fine. I just run the script with an Admin command
window to register the server. But when I uncomment the 'import uuid' line
the error occurs as Excel opens.

In my VBA code I have (in ThisWorkbook)

Private Sub Workbook_Open()
    ' When the workbook opens we create the object
    Set Bug = CreateObject("BugServer")
    Debug.Print "open"
End Sub

and in a separate module I have defined the UDF

Public Bug As Object
Function hello(ByVal expr As String) As Variant
    '
    '
    hello = Bug.hello(expr)

End Function

Thanks for the help.



On Fri, Oct 17, 2014 at 8:18 PM, Vernon D. Cole <vernondcole at gmail.com>
wrote:

> Which version of Python are you running?
> 32 or 64 bit?
> Which version of pywin32?
> Which version of Windows?
> Can you make a small test case that will demonstrate the error?
>
>
> On Thu, Oct 16, 2014 at 7:47 PM, Blair Hall <blairdhall at gmail.com> wrote:
>
>> I have a small python COM server that worked fine with Excel until I
>> decided to import the standard Python 'uuid' module.
>>
>> Now I get the Windows Runtime error R6034 "An application has made an
>> attempt to load the C runtime library incorrectly"
>>
>> I there anything that I can do to fix this?
>>
>> _______________________________________________
>> python-win32 mailing list
>> python-win32 at python.org
>> https://mail.python.org/mailman/listinfo/python-win32
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20141018/a8d26b5d/attachment.html>

From mc at mclaveau.com  Sun Oct 19 23:14:13 2014
From: mc at mclaveau.com (mc@mclaveau)
Date: Sun, 19 Oct 2014 23:14:13 +0200
Subject: [python-win32] Error R6034 when I import uuid
In-Reply-To: <CAJeTVAqZfD9cxHgikJs+4vVLkwc02rOakbR324BV3MrBbRD78w@mail.gmail.com>
References: <CAJeTVArsN8Vp_e6cnF3yUf6cUC4uHUJ6ggmsKUeDCzcKA_=uKw@mail.gmail.com>
 <CAH-ZgAdAjxrn9OUtNAvNe4T=AP7w3Et3bc6UaNMPos3sh1-hRQ@mail.gmail.com>
 <CAJeTVAqZfD9cxHgikJs+4vVLkwc02rOakbR324BV3MrBbRD78w@mail.gmail.com>
Message-ID: <544429A5.70903@mclaveau.com>

Hi!

I test with my own Python-COM-server (Ponx), and I have also an error:

---------------------------------------------------------------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Runtime Error!

Program: D:\Dev\Python\PonxTest101.exe

R6034

An application has made an attempt to load the C runtime library 
incorrectly.
Please contact the application's support team for more information.
---------------------------------------------------------------------------------


I use Python 2.7.3 and Pywin32.218 on Win-7-64 bits.
If I comment the line, like:       #import uuid        the problem 
disappears

@-salutations
-- 
Michel Claveau





Le 18.10.14 02:24, Blair Hall a ?crit :
> OK, sorry, here are some more details.
>
> I have Python 2.7.8, win32, running on a Windows7 64-bit home machine 
> (not professional).
>
> Here is my python script:
>
> #---------------------------------------
> import pythoncom
>
> #import uuid
>
> class Bug:
>
>     _reg_clsid_ = '{E3D5F332-F080-47B3-A319-A3A0E287E466}'
>     _reg_progid_ = "BugServer"
>     _public_methods_ = ['hello']
>
>     def __init__(self):
>         pass
> #------------------------------------------------------------------------
>     def hello(self,who):
>         return "Hello {}".format(who)
>
> #============================================================================
> if __name__=='__main__':
>
>     # cmd options: --register --debug and --unregister
>     import win32com.server.register
>     win32com.server.register.UseCommandLine(Bug)
> #---------------------------------------------
>
>
> As it is, this works fine. I just run the script with an Admin command 
> window to register the server. But when I uncomment the 'import uuid' 
> line the error occurs as Excel opens.
>
> In my VBA code I have (in ThisWorkbook)
>
> Private Sub Workbook_Open()
>     ' When the workbook opens we create the object
>     Set Bug = CreateObject("BugServer")
>     Debug.Print "open"
> End Sub
>
> and in a separate module I have defined the UDF
>
> Public Bug As Object
> Function hello(ByVal expr As String) As Variant
>     '
>     '
>     hello = Bug.hello(expr)
>
> End Function
>
> Thanks for the help.
>
>
>
> On Fri, Oct 17, 2014 at 8:18 PM, Vernon D. Cole <vernondcole at gmail.com 
> <mailto:vernondcole at gmail.com>> wrote:
>
>     Which version of Python are you running?
>     32 or 64 bit?
>     Which version of pywin32?
>     Which version of Windows?
>     Can you make a small test case that will demonstrate the error?
>
>
>     On Thu, Oct 16, 2014 at 7:47 PM, Blair Hall <blairdhall at gmail.com
>     <mailto:blairdhall at gmail.com>> wrote:
>
>         I have a small python COM server that worked fine with Excel
>         until I decided to import the standard Python 'uuid' module.
>
>         Now I get the Windows Runtime error R6034 "An application has
>         made an attempt to load the C runtime library incorrectly"
>
>         I there anything that I can do to fix this?
>
>         _______________________________________________
>         python-win32 mailing list
>         python-win32 at python.org <mailto:python-win32 at python.org>
>         https://mail.python.org/mailman/listinfo/python-win32
>
>
>
>
>
> _______________________________________________
> python-win32 mailing list
> python-win32 at python.org
> https://mail.python.org/mailman/listinfo/python-win32


-- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20141019/d7625f0f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sign-styloplume.GIF
Type: image/gif
Size: 9129 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-win32/attachments/20141019/d7625f0f/attachment.gif>

From skippy.hammond at gmail.com  Mon Oct 20 12:27:40 2014
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Mon, 20 Oct 2014 21:27:40 +1100
Subject: [python-win32] pythoncom
In-Reply-To: <543F8EF6.4070105@ntlworld.com>
References: <543D271C.90902@ntlworld.com> <543D5A1D.7040506@probo.com>
 <543E7B8C.6020805@ntlworld.com> <543F6A4C.6050001@gmail.com>
 <543F8EF6.4070105@ntlworld.com>
Message-ID: <5444E39C.2080406@gmail.com>

On 16/10/2014 8:25 pm, John Sampson wrote:
> at lib\site-packages\win32com\gen_py I see more files in the version
> causing trouble than in the version that works OK.
> How would I recognise the generated support you mention?

Those files *are* the generated support.  Try removing all files in that 
dir.

Mark

From jrs.idx at ntlworld.com  Mon Oct 20 22:17:41 2014
From: jrs.idx at ntlworld.com (John Sampson)
Date: Mon, 20 Oct 2014 21:17:41 +0100
Subject: [python-win32]  pythoncom
In-Reply-To: <5444E39C.2080406@gmail.com>
References: <543D271C.90902@ntlworld.com> <543D5A1D.7040506@probo.com>
 <543E7B8C.6020805@ntlworld.com> <543F6A4C.6050001@gmail.com>
 <543F8EF6.4070105@ntlworld.com> <5444E39C.2080406@gmail.com>
Message-ID: <54456DE5.7080405@ntlworld.com>

On 20/10/2014 11:27, Mark Hammond wrote:
> On 16/10/2014 8:25 pm, John Sampson wrote:
>> at lib\site-packages\win32com\gen_py I see more files in the version
>> causing trouble than in the version that works OK.
>> How would I recognise the generated support you mention?
>
> Those files *are* the generated support.  Try removing all files in 
> that dir.
>
> Mark
>

Many thanks - yes, removing these files seems to have enabled the 
functions that were not working.

Regards

John

From skippy.hammond at gmail.com  Tue Oct 21 06:59:28 2014
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Tue, 21 Oct 2014 15:59:28 +1100
Subject: [python-win32] Error while building pywin32
In-Reply-To: <CAFUX4q_f8AvL=8zEki8_iatGSSB+_3A1FdPEg+_G0LYGzUqQyQ@mail.gmail.com>
References: <CAFUX4q_f8AvL=8zEki8_iatGSSB+_3A1FdPEg+_G0LYGzUqQyQ@mail.gmail.com>
Message-ID: <5445E830.50701@gmail.com>

Works OK for me here - that line is:

	static IAsyncOperation *GetI(PyObject *self);

So I can only guess that the Windows SDK you are using means 
IAsyncOperation isn't declared yet - you might need to grep the SDK dirs 
to see where that lives and why it isn't already included.

HTH,

Mark

On 18/10/2014 9:19 AM, Bharath Ramesh wrote:
> Hi,
> I am trying to build 64-bit pywin32 locally. While building I come
> across this error when the shell extension is being built
>
> com\win32comext\shell\src\PyIAsyncOperation.h(11) : error C2143:
> syntax error : missing ';' before '*'
>
> I am trying to figure out what could be possibly wrong that could be
> causing this issue.
> _______________________________________________
> python-win32 mailing list
> python-win32 at python.org
> https://mail.python.org/mailman/listinfo/python-win32
>


From blairdhall at gmail.com  Tue Oct 21 22:24:35 2014
From: blairdhall at gmail.com (Blair Hall)
Date: Wed, 22 Oct 2014 09:24:35 +1300
Subject: [python-win32] Error R6034 when I import uuid
In-Reply-To: <CAJeTVAqZfD9cxHgikJs+4vVLkwc02rOakbR324BV3MrBbRD78w@mail.gmail.com>
References: <CAJeTVArsN8Vp_e6cnF3yUf6cUC4uHUJ6ggmsKUeDCzcKA_=uKw@mail.gmail.com>
 <CAH-ZgAdAjxrn9OUtNAvNe4T=AP7w3Et3bc6UaNMPos3sh1-hRQ@mail.gmail.com>
 <CAJeTVAqZfD9cxHgikJs+4vVLkwc02rOakbR324BV3MrBbRD78w@mail.gmail.com>
Message-ID: <CAJeTVAp+VrUTMSKsiwOAS67+6Owpg-19_XWn-5Xfqe3TRNp1JA@mail.gmail.com>

I have just tried this same project on a computer with Win7-64 Professional
and MS Office 2010 (but with the same 2.7.8 32-bit Python installation).

The error does NOT occur.

So, is it the difference between Win7 for Home users and professional, or
is it something to do with MS Office (the bug occurred with MS Office 2007
on Win7-64 Home edition)?

On Sat, Oct 18, 2014 at 1:24 PM, Blair Hall <blairdhall at gmail.com> wrote:

> OK, sorry, here are some more details.
>
> I have Python 2.7.8, win32, running on a Windows7 64-bit home machine (not
> professional).
>
> Here is my python script:
>
> #---------------------------------------
> import pythoncom
>
> #import uuid
>
> class Bug:
>
>     _reg_clsid_ = '{E3D5F332-F080-47B3-A319-A3A0E287E466}'
>     _reg_progid_ = "BugServer"
>     _public_methods_ = ['hello']
>
>     def __init__(self):
>         pass
>
> #------------------------------------------------------------------------
>     def hello(self,who):
>         return "Hello {}".format(who)
>
>
> #============================================================================
> if __name__=='__main__':
>
>     # cmd options: --register --debug and --unregister
>     import win32com.server.register
>     win32com.server.register.UseCommandLine(Bug)
> #---------------------------------------------
>
>
> As it is, this works fine. I just run the script with an Admin command
> window to register the server. But when I uncomment the 'import uuid' line
> the error occurs as Excel opens.
>
> In my VBA code I have (in ThisWorkbook)
>
> Private Sub Workbook_Open()
>     ' When the workbook opens we create the object
>     Set Bug = CreateObject("BugServer")
>     Debug.Print "open"
> End Sub
>
> and in a separate module I have defined the UDF
>
> Public Bug As Object
> Function hello(ByVal expr As String) As Variant
>     '
>     '
>     hello = Bug.hello(expr)
>
> End Function
>
> Thanks for the help.
>
>
>
> On Fri, Oct 17, 2014 at 8:18 PM, Vernon D. Cole <vernondcole at gmail.com>
> wrote:
>
>> Which version of Python are you running?
>> 32 or 64 bit?
>> Which version of pywin32?
>> Which version of Windows?
>> Can you make a small test case that will demonstrate the error?
>>
>>
>> On Thu, Oct 16, 2014 at 7:47 PM, Blair Hall <blairdhall at gmail.com> wrote:
>>
>>> I have a small python COM server that worked fine with Excel until I
>>> decided to import the standard Python 'uuid' module.
>>>
>>> Now I get the Windows Runtime error R6034 "An application has made an
>>> attempt to load the C runtime library incorrectly"
>>>
>>> I there anything that I can do to fix this?
>>>
>>> _______________________________________________
>>> python-win32 mailing list
>>> python-win32 at python.org
>>> https://mail.python.org/mailman/listinfo/python-win32
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20141022/a6707473/attachment.html>

From bramesh.vt at gmail.com  Tue Oct 21 23:58:01 2014
From: bramesh.vt at gmail.com (Bharath Ramesh)
Date: Tue, 21 Oct 2014 14:58:01 -0700
Subject: [python-win32] Error while building pywin32
In-Reply-To: <5445E830.50701@gmail.com>
References: <CAFUX4q_f8AvL=8zEki8_iatGSSB+_3A1FdPEg+_G0LYGzUqQyQ@mail.gmail.com>
 <5445E830.50701@gmail.com>
Message-ID: <CAFUX4q8iipBZy+7UKkSSkxFr3t3k9duE0Gndk6NTKc=+7BDjcA@mail.gmail.com>

Hi Mark,
Thank you for the pointer. For some reason I had the Windows 8 SDK in
the include path, this was causing compiler to somehow pick up those
header files ahead of Vista SDK.

For what it is worth, seems like in the newer SDK Microsoft has
decided to rename IAsyncOperation to IDataObjectAsyncCapability in
shldisp.h.

On Mon, Oct 20, 2014 at 9:59 PM, Mark Hammond <skippy.hammond at gmail.com> wrote:
> Works OK for me here - that line is:
>
>         static IAsyncOperation *GetI(PyObject *self);
>
> So I can only guess that the Windows SDK you are using means IAsyncOperation
> isn't declared yet - you might need to grep the SDK dirs to see where that
> lives and why it isn't already included.
>
> HTH,
>
> Mark
>
>
> On 18/10/2014 9:19 AM, Bharath Ramesh wrote:
>>
>> Hi,
>> I am trying to build 64-bit pywin32 locally. While building I come
>> across this error when the shell extension is being built
>>
>> com\win32comext\shell\src\PyIAsyncOperation.h(11) : error C2143:
>> syntax error : missing ';' before '*'
>>
>> I am trying to figure out what could be possibly wrong that could be
>> causing this issue.
>> _______________________________________________
>> python-win32 mailing list
>> python-win32 at python.org
>> https://mail.python.org/mailman/listinfo/python-win32
>>
>