From ckkart at hoc.net  Mon Jun  9 15:07:55 2014
From: ckkart at hoc.net (Christian K.)
Date: Mon, 9 Jun 2014 13:07:55 +0000 (UTC)
Subject: [python-win32] python3 and extended mapi
Message-ID: <loom.20140609T144550-810@post.gmane.org>

Hi,

I was very pleased to see that retrieving properties of a MAPI object yields
either a <str> or <bytes> type depending on whether the _A or _W property
was queried and entryids are always returned as bytes types. Very nice! This
makes a lot of bin2str2bin conversion and encoding/decoding code obsolete.
Nevertheless now it seems that mapi.BinFromHex has a problem (needed to
convert entryids retrieved from the Outlook Object Model) with the input
type. It says it needs unicode input but I think it rather expects a 8-bit
string although it rejects bytes types. I replaced it by binascii.unhexlify
and do not need it anymore but for completeness I thought it should be reported.

Christian


From Paul_Koning at Dell.com  Mon Jun  9 20:09:59 2014
From: Paul_Koning at Dell.com (Paul_Koning at Dell.com)
Date: Mon, 9 Jun 2014 18:09:59 +0000
Subject: [python-win32] python3 and extended mapi
In-Reply-To: <loom.20140609T144550-810@post.gmane.org>
References: <loom.20140609T144550-810@post.gmane.org>
Message-ID: <1B582A04-F12A-4B35-9ABD-1178A6C4D0A9@dell.com>


On Jun 9, 2014, at 9:07 AM, Christian K. <ckkart at hoc.net> wrote:

> Hi,
> 
> I was very pleased to see that retrieving properties of a MAPI object yields
> either a <str> or <bytes> type depending on whether the _A or _W property
> was queried ?

Really?  That seems strange.  As I recall, the *_W APIs are ?wide character? ones.  So in Python 3, they should both map to <str> type.  <bytes> applies only to non-text data.

	paul

From ckkart at hoc.net  Mon Jun  9 20:53:48 2014
From: ckkart at hoc.net (Christian K.)
Date: Mon, 9 Jun 2014 18:53:48 +0000 (UTC)
Subject: [python-win32] python3 and extended mapi
References: <loom.20140609T144550-810@post.gmane.org>
 <1B582A04-F12A-4B35-9ABD-1178A6C4D0A9@dell.com>
Message-ID: <loom.20140609T204951-734@post.gmane.org>

 <Paul_Koning <at> Dell.com> writes:

> 
> 
> On Jun 9, 2014, at 9:07 AM, Christian K. <ckkart <at> hoc.net> wrote:
> 
> > Hi,
> > 
> > I was very pleased to see that retrieving properties of a MAPI object yields
> > either a <str> or <bytes> type depending on whether the _A or _W property
> > was queried ?
> 
> Really?  That seems strange.  As I recall, the *_W APIs are ?wide
character? ones.  So in Python 3, they
> should both map to <str> type.  <bytes> applies only to non-text data.

At least for text properties like e.g. PR_SUBJECT_A / _W the former returns
a mbcs encoded "string", i.e. of bytes type and the latter a 2-byte unicode
string. Binary properties are always returned as bytes in contrast to
earlier when using pyrhon2.

Chrisrian





From Paul_Koning at Dell.com  Mon Jun  9 21:00:58 2014
From: Paul_Koning at Dell.com (Paul_Koning at Dell.com)
Date: Mon, 9 Jun 2014 19:00:58 +0000
Subject: [python-win32] python3 and extended mapi
In-Reply-To: <loom.20140609T204951-734@post.gmane.org>
References: <loom.20140609T144550-810@post.gmane.org>
 <1B582A04-F12A-4B35-9ABD-1178A6C4D0A9@dell.com>
 <loom.20140609T204951-734@post.gmane.org>
Message-ID: <359A340B-B770-4065-9524-A3BB4A86B8DC@dell.com>


On Jun 9, 2014, at 2:53 PM, Christian K. <ckkart at hoc.net> wrote:

> <Paul_Koning <at> Dell.com> writes:
> 
>> 
>> 
>> On Jun 9, 2014, at 9:07 AM, Christian K. <ckkart <at> hoc.net> wrote:
>> 
>>> Hi,
>>> 
>>> I was very pleased to see that retrieving properties of a MAPI object yields
>>> either a <str> or <bytes> type depending on whether the _A or _W property
>>> was queried ?
>> 
>> Really?  That seems strange.  As I recall, the *_W APIs are ?wide
> character? ones.  So in Python 3, they
>> should both map to <str> type.  <bytes> applies only to non-text data.
> 
> At least for text properties like e.g. PR_SUBJECT_A / _W the former returns
> a mbcs encoded "string", i.e. of bytes type and the latter a 2-byte unicode
> string. Binary properties are always returned as bytes in contrast to
> earlier when using pyrhon2.

Yes, ?bytes? for binary values is clearly correct.  But MBCS and ?2 byte Unicode? (more accurately called either UCS-2 or UCS-2 BMP subset, not sure which) are both text strings.  The different encoding in the API doesn?t mean they should be different datatypes in Python 3; both cases are properly mapped to ?str?.

	paul

From ckkart at hoc.net  Tue Jun 10 03:40:02 2014
From: ckkart at hoc.net (Christian K.)
Date: Mon, 09 Jun 2014 22:40:02 -0300
Subject: [python-win32] python3 and extended mapi
In-Reply-To: <359A340B-B770-4065-9524-A3BB4A86B8DC@dell.com>
References: <loom.20140609T144550-810@post.gmane.org>
 <1B582A04-F12A-4B35-9ABD-1178A6C4D0A9@dell.com>
 <loom.20140609T204951-734@post.gmane.org>
 <359A340B-B770-4065-9524-A3BB4A86B8DC@dell.com>
Message-ID: <539661F2.1070307@hoc.net>

Am 09.06.14 16:00, schrieb Paul_Koning at Dell.com:
>
> On Jun 9, 2014, at 2:53 PM, Christian K. <ckkart at hoc.net> wrote:
>
>> <Paul_Koning <at> Dell.com> writes:
>>
>>>
>>>
>>> On Jun 9, 2014, at 9:07 AM, Christian K. <ckkart <at> hoc.net> wrote:
>>>
>>>> Hi,
>>>>
>>>> I was very pleased to see that retrieving properties of a MAPI object yields
>>>> either a <str> or <bytes> type depending on whether the _A or _W property
>>>> was queried ?
>>>
>>> Really?  That seems strange.  As I recall, the *_W APIs are ?wide
>> character? ones.  So in Python 3, they
>>> should both map to <str> type.  <bytes> applies only to non-text data.
>>
>> At least for text properties like e.g. PR_SUBJECT_A / _W the former returns
>> a mbcs encoded "string", i.e. of bytes type and the latter a 2-byte unicode
>> string. Binary properties are always returned as bytes in contrast to
>> earlier when using pyrhon2.
>
> Yes, ?bytes? for binary values is clearly correct.  But MBCS and ?2 byte Unicode? (more accurately called either UCS-2 or UCS-2 BMP subset, not sure which) are both text strings.  The different encoding in the API doesn?t mean they should be different datatypes in Python 3; both cases are properly mapped to ?str?.

No, this is not what I am seeing. MBCS encoded properties, i.e. those 
terminating with _A are mapped to 'bytes' and the _W ones to 'str' which 
is consistent with the handling of unicode and encoded information in 
python3. And this is great indeed because having to distinguish between 
strings which can be encoded or not while having the same type is really 
painful.

Christian





From ckkart at hoc.net  Tue Jun 10 03:40:02 2014
From: ckkart at hoc.net (Christian K.)
Date: Mon, 09 Jun 2014 22:40:02 -0300
Subject: [python-win32] python3 and extended mapi
In-Reply-To: <359A340B-B770-4065-9524-A3BB4A86B8DC@dell.com>
References: <loom.20140609T144550-810@post.gmane.org>
 <1B582A04-F12A-4B35-9ABD-1178A6C4D0A9@dell.com>
 <loom.20140609T204951-734@post.gmane.org>
 <359A340B-B770-4065-9524-A3BB4A86B8DC@dell.com>
Message-ID: <539661F2.1070307@hoc.net>

Am 09.06.14 16:00, schrieb Paul_Koning at Dell.com:
>
> On Jun 9, 2014, at 2:53 PM, Christian K. <ckkart at hoc.net> wrote:
>
>> <Paul_Koning <at> Dell.com> writes:
>>
>>>
>>>
>>> On Jun 9, 2014, at 9:07 AM, Christian K. <ckkart <at> hoc.net> wrote:
>>>
>>>> Hi,
>>>>
>>>> I was very pleased to see that retrieving properties of a MAPI object yields
>>>> either a <str> or <bytes> type depending on whether the _A or _W property
>>>> was queried ?
>>>
>>> Really?  That seems strange.  As I recall, the *_W APIs are ?wide
>> character? ones.  So in Python 3, they
>>> should both map to <str> type.  <bytes> applies only to non-text data.
>>
>> At least for text properties like e.g. PR_SUBJECT_A / _W the former returns
>> a mbcs encoded "string", i.e. of bytes type and the latter a 2-byte unicode
>> string. Binary properties are always returned as bytes in contrast to
>> earlier when using pyrhon2.
>
> Yes, ?bytes? for binary values is clearly correct.  But MBCS and ?2 byte Unicode? (more accurately called either UCS-2 or UCS-2 BMP subset, not sure which) are both text strings.  The different encoding in the API doesn?t mean they should be different datatypes in Python 3; both cases are properly mapped to ?str?.

No, this is not what I am seeing. MBCS encoded properties, i.e. those 
terminating with _A are mapped to 'bytes' and the _W ones to 'str' which 
is consistent with the handling of unicode and encoded information in 
python3. And this is great indeed because having to distinguish between 
strings which can be encoded or not while having the same type is really 
painful.

Christian




From skippy.hammond at gmail.com  Tue Jun 10 15:11:14 2014
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Tue, 10 Jun 2014 23:11:14 +1000
Subject: [python-win32] python3 and extended mapi
In-Reply-To: <loom.20140609T144550-810@post.gmane.org>
References: <loom.20140609T144550-810@post.gmane.org>
Message-ID: <539703F2.9080109@gmail.com>

It would be great if you could open a bug at sourceforge...

Mark

On 9/06/2014 11:07 PM, Christian K. wrote:
> Hi,
>
> I was very pleased to see that retrieving properties of a MAPI object yields
> either a <str> or <bytes> type depending on whether the _A or _W property
> was queried and entryids are always returned as bytes types. Very nice! This
> makes a lot of bin2str2bin conversion and encoding/decoding code obsolete.
> Nevertheless now it seems that mapi.BinFromHex has a problem (needed to
> convert entryids retrieved from the Outlook Object Model) with the input
> type. It says it needs unicode input but I think it rather expects a 8-bit
> string although it rejects bytes types. I replaced it by binascii.unhexlify
> and do not need it anymore but for completeness I thought it should be reported.
>
> Christian
>
> _______________________________________________
> python-win32 mailing list
> python-win32 at python.org
> https://mail.python.org/mailman/listinfo/python-win32
>


From Paul_Koning at Dell.com  Tue Jun 10 17:22:03 2014
From: Paul_Koning at Dell.com (Paul_Koning at Dell.com)
Date: Tue, 10 Jun 2014 15:22:03 +0000
Subject: [python-win32] python3 and extended mapi
In-Reply-To: <539661F2.1070307@hoc.net>
References: <loom.20140609T144550-810@post.gmane.org>
 <1B582A04-F12A-4B35-9ABD-1178A6C4D0A9@dell.com>
 <loom.20140609T204951-734@post.gmane.org>
 <359A340B-B770-4065-9524-A3BB4A86B8DC@dell.com> <539661F2.1070307@hoc.net>
Message-ID: <477FA935-E489-45CC-8D57-89521245768A@dell.com>


On Jun 9, 2014, at 9:40 PM, Christian K. <ckkart at hoc.net> wrote:

> Am 09.06.14 16:00, schrieb Paul_Koning at Dell.com:
>> 
>> On Jun 9, 2014, at 2:53 PM, Christian K. <ckkart at hoc.net> wrote:
>> 
>>> <Paul_Koning <at> Dell.com> writes:
>>> 
>>>> 
>>>> 
>>>> On Jun 9, 2014, at 9:07 AM, Christian K. <ckkart <at> hoc.net> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> I was very pleased to see that retrieving properties of a MAPI object yields
>>>>> either a <str> or <bytes> type depending on whether the _A or _W property
>>>>> was queried ?
>>>> 
>>>> Really?  That seems strange.  As I recall, the *_W APIs are ?wide
>>> character? ones.  So in Python 3, they
>>>> should both map to <str> type.  <bytes> applies only to non-text data.
>>> 
>>> At least for text properties like e.g. PR_SUBJECT_A / _W the former returns
>>> a mbcs encoded "string", i.e. of bytes type and the latter a 2-byte unicode
>>> string. Binary properties are always returned as bytes in contrast to
>>> earlier when using pyrhon2.
>> 
>> Yes, ?bytes? for binary values is clearly correct.  But MBCS and ?2 byte Unicode? (more accurately called either UCS-2 or UCS-2 BMP subset, not sure which) are both text strings.  The different encoding in the API doesn?t mean they should be different datatypes in Python 3; both cases are properly mapped to ?str?.
> 
> No, this is not what I am seeing. MBCS encoded properties, i.e. those terminating with _A are mapped to 'bytes' and the _W ones to 'str' which is consistent with the handling of unicode and encoded information in python3. And this is great indeed because having to distinguish between strings which can be encoded or not while having the same type is really painful.

Perhaps I?m missing something.

I?m used to Windows API calls that come in a foo_A and foo_W flavor, the only difference being that the _A flavor has ASCII arguments and the _W flavor has Unicode arguments (for those arguments that are, abstractly, strings).

In Python 3, the ?str? type is an abstract string; its character repertoire is Unicode but it doesn?t have an encoding.  Instead, encoding and decoding is done when it is converted to/from external interfaces ? files, external API calls, etc.

So... I would expect foo_A and foo_W to have ?str? arguments, and the interface machinery between Python3 and those functions would run the appropriate encoding to generate the string representation expected.

For example, if a given API wants strings in ASCII form, it would be str.encode (?ascii?) or perhaps str.encode (?latin1?).  If it wants MBCS data, it would be encode to that encoding.  If 2-byte Unicode, it would be encode to ucs-2.  And so on.  Ditto in the reverse direction, when strings are delivered by an external function.

I would only want/expect to see ?bytes? types when the values in question are binary data streams, or unknown format.  But anytime we?re dealing with text strings, the Python 3 approach is that the Python code sees ?str? type, and questions of encoding have been handled at the edge.  This is where Python 3 gets it right and Python 2 was a big muddle.

Mark, could you clarify how you would expect this to work?

	paul


From timr at probo.com  Tue Jun 10 19:01:00 2014
From: timr at probo.com (Tim Roberts)
Date: Tue, 10 Jun 2014 10:01:00 -0700
Subject: [python-win32] python3 and extended mapi
In-Reply-To: <477FA935-E489-45CC-8D57-89521245768A@dell.com>
References: <loom.20140609T144550-810@post.gmane.org>
 <1B582A04-F12A-4B35-9ABD-1178A6C4D0A9@dell.com>
 <loom.20140609T204951-734@post.gmane.org>
 <359A340B-B770-4065-9524-A3BB4A86B8DC@dell.com> <539661F2.1070307@hoc.net>
 <477FA935-E489-45CC-8D57-89521245768A@dell.com>
Message-ID: <539739CC.6040209@probo.com>

Paul_Koning at Dell.com wrote:
> Perhaps I?m missing something.

I'm not sure you're missing anything.  You're simply describing another
implementation choice that could have been made.  Both your scheme and
the actual scheme have their merits.


> I?m used to Windows API calls that come in a foo_A and foo_W flavor, the only difference being that the _A flavor has ASCII arguments and the _W flavor has Unicode arguments (for those arguments that are, abstractly, strings).

Technically speaking, the _A flavor is MBCS.  8-bit entities, with an
unknown encoding, where a single character can span multiple bytes.


> In Python 3, the ?str? type is an abstract string; its character repertoire is Unicode but it doesn?t have an encoding.  Instead, encoding and decoding is done when it is converted to/from external interfaces ? files, external API calls, etc.

It doesn't have an encoding because it doesn't NEED an encoding.


> So... I would expect foo_A and foo_W to have ?str? arguments, and the interface machinery between Python3 and those functions would run the appropriate encoding to generate the string representation expected.

The big problem here is determining what is "the appropriate encoding". 
I'm not convinced there is any way for the Python COM machinery to know
that definitively.  It could make a guess, but you're always going to be
wrong sometimes.  Absent that confidence, it seems to me that the
correct solution is to deliver the MBCS string exactly as it arrived,
and that's what the current implementation does.  Leave it to the
application to figure out how to decode it.


> For example, if a given API wants strings in ASCII form, it would be str.encode (?ascii?) or perhaps str.encode (?latin1?).

Assuming the API wants Latin-1.  Does it?  You don't know that.  It
varies from machine to machine, and even from run to run.  That's the
problem.


> If it wants MBCS data, it would be encode to that encoding.

I assume you understand that all 8-bit strings in Windows are MBCS. 
Latin-1 is just another MBCS.


> If 2-byte Unicode, it would be encode to ucs-2.

UTF-16; that's what the Windows Unicode encoding is.


> I would only want/expect to see ?bytes? types when the values in question are binary data streams, or unknown format.  But anytime we?re dealing with text strings, the Python 3 approach is that the Python code sees ?str? type, and questions of encoding have been handled at the edge.  This is where Python 3 gets it right and Python 2 was a big muddle.

The muddle is not the fault of Python.  It is the fault of the character
encoding decisions made by Microsoft in the mists of antiquity.  When
you get an 8-bit string that includes the byte 0x9F, there is absolutely
no way for you answer the question "what character is that?"  If that
question cannot be answered, middleware should not be making a guess.

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


From ckkart at hoc.net  Tue Jun 10 19:08:41 2014
From: ckkart at hoc.net (Christian K.)
Date: Tue, 10 Jun 2014 17:08:41 +0000 (UTC)
Subject: [python-win32] python3 and extended mapi
References: <loom.20140609T144550-810@post.gmane.org>
 <1B582A04-F12A-4B35-9ABD-1178A6C4D0A9@dell.com>
 <loom.20140609T204951-734@post.gmane.org>
 <359A340B-B770-4065-9524-A3BB4A86B8DC@dell.com> <539661F2.1070307@hoc.net>
 <477FA935-E489-45CC-8D57-89521245768A@dell.com>
Message-ID: <loom.20140610T185531-739@post.gmane.org>

 <Paul_Koning <at> Dell.com> writes:

> 
> 
> On Jun 9, 2014, at 9:40 PM, Christian K. <ckkart <at> hoc.net> wrote:
> 
> > Am 09.06.14 16:00, schrieb Paul_Koning <at> Dell.com:
> >> 
> >> On Jun 9, 2014, at 2:53 PM, Christian K. <ckkart <at> hoc.net> wrote:
> >> 
> >>> <Paul_Koning <at> Dell.com> writes:
> >>> 
> >>>> 
> >>>> 
> >>>> On Jun 9, 2014, at 9:07 AM, Christian K. <ckkart <at> hoc.net> wrote:
> >>>> 
> >>>>> Hi,
> >>>>> 
> >>>>> I was very pleased to see that retrieving properties of a MAPI
object yields
> >>>>> either a <str> or <bytes> type depending on whether the _A or _W
property
> >>>>> was queried ?
> >>>> 
> >>>> Really?  That seems strange.  As I recall, the *_W APIs are ?wide
> >>> character? ones.  So in Python 3, they
> >>>> should both map to <str> type.  <bytes> applies only to non-text data.
> >>> 
> >>> At least for text properties like e.g. PR_SUBJECT_A / _W the former
returns
> >>> a mbcs encoded "string", i.e. of bytes type and the latter a 2-byte
unicode
> >>> string. Binary properties are always returned as bytes in contrast to
> >>> earlier when using pyrhon2.
> >> 
> >> Yes, ?bytes? for binary values is clearly correct.  But MBCS and ?2
byte Unicode? (more
> accurately called either UCS-2 or UCS-2 BMP subset, not sure which) are
both text strings.  The different
> encoding in the API doesn?t mean they should be different datatypes in
Python 3; both cases are properly
> mapped to ?str?.
> > 
> > No, this is not what I am seeing. MBCS encoded properties, i.e. those
terminating with _A are mapped to
> 'bytes' and the _W ones to 'str' which is consistent with the handling of
unicode and encoded information
> in python3. And this is great indeed because having to distinguish between
strings which can be encoded or
> not while having the same type is really painful.
> 
> Perhaps I?m missing something.
> 
> I?m used to Windows API calls that come in a foo_A and foo_W flavor, the
only difference being that the _A
> flavor has ASCII arguments and the _W flavor has Unicode arguments (for
those arguments that are,
> abstractly, strings).
> 
> In Python 3, the ?str? type is an abstract string; its character
repertoire is Unicode but it doesn?t
> have an encoding.  Instead, encoding and decoding is done when it is
converted to/from external
> interfaces ? files, external API calls, etc.

True, and the type which handles that data is called "str". In contrast to
what I said before more than two bytes have to be used internally since
unicode defines more than 100000 characters.

> So... I would expect foo_A and foo_W to have ?str? arguments, and the
interface machinery between
> Python3 and those functions would run the appropriate encoding to generate
the string representation expected.
> 
> For example, if a given API wants strings in ASCII form, it would be
str.encode (?ascii?) or perhaps
> str.encode (?latin1?).  If it wants MBCS data, it would be encode to that
encoding.  If 2-byte Unicode,
> it would be encode to ucs-2.  And so on.  Ditto in the reverse direction,
when strings are delivered by an
> external function.

Whenever you encode a "str" object in python3, i.e. call its encode() method
you will end up with a "bytes" object. And vice versa only a "bytes" object
does have a decode method. So the concept of having a unicode character pool
and its printable representation is reflected by two differnt types in
python. unicode:"str", any encoded string:"bytes"
For that reason, if a function returns an encoded string, the return type
has to be "bytes" and this is what is happening when retrieving the _A
properties.
Try it yourself: type('a') yields "unicode", type('a'.encode('asci''))
yields "bytes"

> I would only want/expect to see ?bytes? types when the values in question
are binary data streams, or
> unknown format.  But anytime we?re dealing with text strings, the Python 3
approach is that the Python
> code sees ?str? type, and questions of encoding have been handled at the
edge.  This is where Python 3

This is not true, see above.

Christian




From ckkart at hoc.net  Tue Jun 10 19:10:15 2014
From: ckkart at hoc.net (Christian K.)
Date: Tue, 10 Jun 2014 17:10:15 +0000 (UTC)
Subject: [python-win32] python3 and extended mapi
References: <loom.20140609T144550-810@post.gmane.org>
 <539703F2.9080109@gmail.com>
Message-ID: <loom.20140610T190953-272@post.gmane.org>

Mark Hammond <skippy.hammond <at> gmail.com> writes:

> 
> It would be great if you could open a bug at sourceforge...

Done.


From ckkart at hoc.net  Tue Jun 10 19:17:56 2014
From: ckkart at hoc.net (Christian K.)
Date: Tue, 10 Jun 2014 17:17:56 +0000 (UTC)
Subject: [python-win32] python3 and extended mapi
References: <loom.20140609T144550-810@post.gmane.org>
 <1B582A04-F12A-4B35-9ABD-1178A6C4D0A9@dell.com>
 <loom.20140609T204951-734@post.gmane.org>
 <359A340B-B770-4065-9524-A3BB4A86B8DC@dell.com> <539661F2.1070307@hoc.net>
 <477FA935-E489-45CC-8D57-89521245768A@dell.com>
 <loom.20140610T185531-739@post.gmane.org>
Message-ID: <loom.20140610T191222-788@post.gmane.org>

Christian K. <ckkart <at> hoc.net> writes:

> 
>  <Paul_Koning <at> Dell.com> writes:

> > I would only want/expect to see ?bytes? types when the values in question
> are binary data streams, or
> > unknown format.  But anytime we?re dealing with text strings, the Python 3
> approach is that the Python
> > code sees ?str? type, and questions of encoding have been handled at the
> edge.  This is where Python 3
> 
> This is not true, see above.

What I mean is that you cannot leave it to the application. Once a "str"
type is returned is has to be assumed that it contains unicode data. "str"
classes do not have a decode method or is there a way to decode the data
hold by a "str" object assuming that is encoded and not unicode? 

Christian


From joss at jossgray.net  Thu Jun 12 20:52:17 2014
From: joss at jossgray.net (Joss Gray)
Date: Thu, 12 Jun 2014 13:52:17 -0500
Subject: [python-win32] Visual Studio Project
Message-ID: <CA+aNgSx5MkOHZ0dp+Y5hv7X1OgpXVmqv0wM97kpb=JRJkbf9tg@mail.gmail.com>

Is there a visual studio project for pywin32?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20140612/e3926201/attachment.html>

From ckkart at hoc.net  Sat Jun 14 16:10:03 2014
From: ckkart at hoc.net (Christian K.)
Date: Sat, 14 Jun 2014 11:10:03 -0300
Subject: [python-win32] python3 and extended mapi
In-Reply-To: <loom.20140610T191222-788@post.gmane.org>
References: <loom.20140609T144550-810@post.gmane.org>
 <1B582A04-F12A-4B35-9ABD-1178A6C4D0A9@dell.com>
 <loom.20140609T204951-734@post.gmane.org>
 <359A340B-B770-4065-9524-A3BB4A86B8DC@dell.com> <539661F2.1070307@hoc.net>
 <477FA935-E489-45CC-8D57-89521245768A@dell.com>
 <loom.20140610T185531-739@post.gmane.org>
 <loom.20140610T191222-788@post.gmane.org>
Message-ID: <lnhl3r$92n$1@ger.gmane.org>

>>   <Paul_Koning <at> Dell.com> writes:
>
>>> I would only want/expect to see ?bytes? types when the values in question
>> are binary data streams, or
>>> unknown format.  But anytime we?re dealing with text strings, the Python 3
>> approach is that the Python
>>> code sees ?str? type, and questions of encoding have been handled at the
>> edge.  This is where Python 3
>>
>> This is not true, see above.
>
> What I mean is that you cannot leave it to the application. Once a "str"
> type is returned is has to be assumed that it contains unicode data. "str"
> classes do not have a decode method or is there a way to decode the data
> hold by a "str" object assuming that is encoded and not unicode?

No objections here? I am not an expert to be without doubts on what I 
said myself. So please tell me if I am wrong.

Christian



From skippy.hammond at gmail.com  Mon Jun 16 06:21:50 2014
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Mon, 16 Jun 2014 14:21:50 +1000
Subject: [python-win32] Visual Studio Project
In-Reply-To: <CA+aNgSx5MkOHZ0dp+Y5hv7X1OgpXVmqv0wM97kpb=JRJkbf9tg@mail.gmail.com>
References: <CA+aNgSx5MkOHZ0dp+Y5hv7X1OgpXVmqv0wM97kpb=JRJkbf9tg@mail.gmail.com>
Message-ID: <539E70DE.1050707@gmail.com>

On 13/06/2014 4:52 AM, Joss Gray wrote:
> Is there a visual studio project for pywin32?

Nope - it must be built using setup.py in the root of the source distro.

Mark


From joss at jossgray.net  Mon Jun 16 13:18:23 2014
From: joss at jossgray.net (Joss Gray)
Date: Mon, 16 Jun 2014 12:18:23 +0100
Subject: [python-win32] Visual Studio Project
In-Reply-To: <539E70DE.1050707@gmail.com>
References: <CA+aNgSx5MkOHZ0dp+Y5hv7X1OgpXVmqv0wM97kpb=JRJkbf9tg@mail.gmail.com>
 <539E70DE.1050707@gmail.com>
Message-ID: <CA+aNgSwpSRg9qii5dPw+LDCyB1Uh6rUEou0RMN1=OamcSvcFhA@mail.gmail.com>

How do you debug pywin32


On Mon, Jun 16, 2014 at 5:21 AM, Mark Hammond <skippy.hammond at gmail.com>
wrote:

> On 13/06/2014 4:52 AM, Joss Gray wrote:
>
>> Is there a visual studio project for pywin32?
>>
>
> Nope - it must be built using setup.py in the root of the source distro.
>
> Mark
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20140616/0995e6a9/attachment.html>

From timr at probo.com  Mon Jun 16 19:38:43 2014
From: timr at probo.com (Tim Roberts)
Date: Mon, 16 Jun 2014 10:38:43 -0700
Subject: [python-win32] Visual Studio Project
In-Reply-To: <CA+aNgSwpSRg9qii5dPw+LDCyB1Uh6rUEou0RMN1=OamcSvcFhA@mail.gmail.com>
References: <CA+aNgSx5MkOHZ0dp+Y5hv7X1OgpXVmqv0wM97kpb=JRJkbf9tg@mail.gmail.com>
 <539E70DE.1050707@gmail.com>
 <CA+aNgSwpSRg9qii5dPw+LDCyB1Uh6rUEou0RMN1=OamcSvcFhA@mail.gmail.com>
Message-ID: <539F2BA3.9070108@probo.com>

Joss Gray wrote:
> How do you debug pywin32

As long as you have the symbol files, you can attach the Visual Studio
debugger to a currently running process and get symbolic debugging.

That's generally how you'd have to do it anyway, since PyWin32 is a
collection of DLLs, rather than a single executable.

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


From mhammond at skippinet.com.au  Tue Jun 17 00:58:32 2014
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 17 Jun 2014 08:58:32 +1000
Subject: [python-win32] Visual Studio Project
In-Reply-To: <CA+aNgSwpSRg9qii5dPw+LDCyB1Uh6rUEou0RMN1=OamcSvcFhA@mail.gmail.com>
References: <CA+aNgSx5MkOHZ0dp+Y5hv7X1OgpXVmqv0wM97kpb=JRJkbf9tg@mail.gmail.com>	<539E70DE.1050707@gmail.com>
 <CA+aNgSwpSRg9qii5dPw+LDCyB1Uh6rUEou0RMN1=OamcSvcFhA@mail.gmail.com>
Message-ID: <539F7698.8090508@skippinet.com.au>

On 16/06/2014 9:18 PM, Joss Gray wrote:
> How do you debug pywin32

Using Visual Studio - there's no need to build under VS to use it as a 
debugger.

Mark.

>
>
> On Mon, Jun 16, 2014 at 5:21 AM, Mark Hammond <skippy.hammond at gmail.com
> <mailto:skippy.hammond at gmail.com>> wrote:
>
>     On 13/06/2014 4:52 AM, Joss Gray wrote:
>
>         Is there a visual studio project for pywin32?
>
>
>     Nope - it must be built using setup.py in the root of the source distro.
>
>     Mark
>
>


From weijwu at cisco.com  Fri Jun 20 09:23:20 2014
From: weijwu at cisco.com (Weijie Wu -X (weijwu - YI JIN XIN XI FU WU(SU ZHOU)YOU XIAN GONG SI at
 Cisco))
Date: Fri, 20 Jun 2014 07:23:20 +0000
Subject: [python-win32] save chart from an existing xlsx as an image
Message-ID: <A7002F36DDC5FE4B8DFC85494E1E544A45F335FF@xmb-aln-x03.cisco.com>

Hi, guys

I know win32com is working on windows for python, and I've question:
I want to save chart from demo.xlsx as an image.  I also found some code as below:

from win32com.client import Dispatch
xlsApp = Dispatch("Excel.Application")
xlsWB = xlsApp.Workbooks.Open(r'/tmp/test/demo.xlsx')
xlsSheet = xlsWB.Sheets("sheet1")
mychart = XlsSheet.Charts(1)  #'1' is the index of the chart object in the wb
mychart.Export(Filename=r'/tmp/test/MyExportedChart.png')


is there anyway I can run this code on linux ?

or is there anyway I can save chart from an existing xlsx as an image?

It drives me crazy.


Thanks
Wiley


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20140620/665ede49/attachment.html>

From vernondcole at gmail.com  Fri Jun 20 12:23:25 2014
From: vernondcole at gmail.com (Vernon D. Cole)
Date: Fri, 20 Jun 2014 11:23:25 +0100
Subject: [python-win32] save chart from an existing xlsx as an image
In-Reply-To: <A7002F36DDC5FE4B8DFC85494E1E544A45F335FF@xmb-aln-x03.cisco.com>
References: <A7002F36DDC5FE4B8DFC85494E1E544A45F335FF@xmb-aln-x03.cisco.com>
Message-ID: <CAH-ZgAd-eZDSbe-FzmhLhYytgWrUmjvETxcvkjSRk4k3yQ4XEA@mail.gmail.com>

It might be possible to run some older versions of Excel on Linux using wine
<https://winehq.org/> or crossover <https://codeweavers.com/products/>, but
I do not think that you will be able to control them using COM.  Python 2.7
(32 bit) for Windows and pywin32 can be installed using Wine, but many
features do not work. (I tried using Ubuntu 14.04).

It might be better to try opening your spreadsheet using libreoffice
<http://www.libreoffice.org/>, which has the ability to export .pdf files
(and works on both Linux and Windows).

Otherwise, you might only be able to make screen shots of your Excel window
using a Windows computer.



On Fri, Jun 20, 2014 at 8:23 AM, Weijie Wu -X (weijwu - YI JIN XIN XI FU
WU(SU ZHOU)YOU XIAN GONG SI at Cisco) <weijwu at cisco.com> wrote:

>  Hi, guys
>
>
>
> I know win32com is working on windows for python, and I?ve question:
>
> I want to save chart from demo.xlsx as an image.  I also found some code
> as below:
>
>
>
> *from win32com.client import Dispatch*
>
> *xlsApp = Dispatch("Excel.Application") *
>
> *xlsWB = xlsApp.Workbooks.Open(r'/tmp/test/demo.xlsx') *
>
> *xlsSheet = xlsWB.Sheets("sheet1") *
>
> *mychart = XlsSheet.Charts(1)  #'1' is the index of the chart object in
> the wb*
>
> *mychart.Export(Filename=r'/tmp/test/MyExportedChart.png')*
>
>
>
>
>
> is there anyway I can run this code on linux ?
>
>
>
> or is there anyway I can save chart from an existing xlsx as an image?
>
>
>
> It drives me crazy.
>
>
>
>
>
> Thanks
>
> Wiley
>
>
>
>
>
> _______________________________________________
> 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/20140620/cc50ce40/attachment.html>

From calderon.christian760 at gmail.com  Fri Jun 20 16:23:33 2014
From: calderon.christian760 at gmail.com (Christian Calderon)
Date: Fri, 20 Jun 2014 07:23:33 -0700
Subject: [python-win32] save chart from an existing xlsx as an image
In-Reply-To: <A7002F36DDC5FE4B8DFC85494E1E544A45F335FF@xmb-aln-x03.cisco.com>
References: <A7002F36DDC5FE4B8DFC85494E1E544A45F335FF@xmb-aln-x03.cisco.com>
Message-ID: <CA+9L8FytiQWmD8Y1y78KiH_LC3ruQK_1Gb9EnFd4XvKfXJ9tow@mail.gmail.com>

Are you trying to extract data from the file to make a graph? This is
possible.
On Jun 20, 2014 1:09 AM, "Weijie Wu -X (weijwu - YI JIN XIN XI FU WU(SU
ZHOU)YOU XIAN GONG SI at Cisco)" <weijwu at cisco.com> wrote:

>  Hi, guys
>
>
>
> I know win32com is working on windows for python, and I?ve question:
>
> I want to save chart from demo.xlsx as an image.  I also found some code
> as below:
>
>
>
> *from win32com.client import Dispatch*
>
> *xlsApp = Dispatch("Excel.Application") *
>
> *xlsWB = xlsApp.Workbooks.Open(r'/tmp/test/demo.xlsx') *
>
> *xlsSheet = xlsWB.Sheets("sheet1") *
>
> *mychart = XlsSheet.Charts(1)  #'1' is the index of the chart object in
> the wb*
>
> *mychart.Export(Filename=r'/tmp/test/MyExportedChart.png')*
>
>
>
>
>
> is there anyway I can run this code on linux ?
>
>
>
> or is there anyway I can save chart from an existing xlsx as an image?
>
>
>
> It drives me crazy.
>
>
>
>
>
> Thanks
>
> Wiley
>
>
>
>
>
> _______________________________________________
> 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/20140620/0bb7f883/attachment.html>

From timr at probo.com  Fri Jun 20 18:33:35 2014
From: timr at probo.com (Tim Roberts)
Date: Fri, 20 Jun 2014 09:33:35 -0700
Subject: [python-win32] save chart from an existing xlsx as an image
In-Reply-To: <A7002F36DDC5FE4B8DFC85494E1E544A45F335FF@xmb-aln-x03.cisco.com>
References: <A7002F36DDC5FE4B8DFC85494E1E544A45F335FF@xmb-aln-x03.cisco.com>
Message-ID: <FAFF33FC4E0690489FDA7838EAB2677E01420217F4B3@ECHO.probo.local>

<quote>
I know win32com is working on windows for python, and I?ve question:
I want to save chart from demo.xlsx as an image.  I also found some code as below:
</quote>

Allow me to summarize the other responses.
1. Excel does not run on Linux.
2. It can be made to run in a Windows emulator, but you can't get COM access.
3. It is possible to read data from Excel files without using Excel.
4. There are many excellent plotting packages for Python that do not involve Excel.
--
Tim Roberts, timr at probo.com
Providenza & Boekelheide, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20140620/96e7f07a/attachment.html>

From cappy2112 at gmail.com  Sat Jun 21 01:01:35 2014
From: cappy2112 at gmail.com (Tony Cappellini)
Date: Fri, 20 Jun 2014 16:01:35 -0700
Subject: [python-win32] win32ui.CreateFileDialog() hangs on Windows 7
Message-ID: <CABRXM4=y4UVu4+XvazrQjFt4fzEhGq4gnQ=Z5ogmQ45jYAp6TQ@mail.gmail.com>

I'm running Python 2.7.6, PythonWin build 218 on Windows 7 Pro, 32-Bit

The code below hangs after the browse() function returns to the caller.
I do see "After" displayed in the console window.

Is anyone else seeing this problem on Windows?
Thanks

import win32ui
import os


def browse(startingDirectory=None,defaultFilespec="*.*"):

   if startingDirectory is not None:
      startingDirectory = os.getcwd()
   FILE_OPEN = 1
   dlg = win32ui.CreateFileDialog( FILE_OPEN, defaultFilespec )
   fn  = None
   try:
      if dlg:
         dlg.SetOFNInitialDir( startingDirectory )
         dlg.DoModal()
         fn = dlg.GetPathName()
   finally:
      del dlg

   return fn

print"\nBefore"
browse()
print"\nAfter\n"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20140620/d1ce73b5/attachment.html>

From balazovic.peter at gmail.com  Sun Jun 22 20:05:37 2014
From: balazovic.peter at gmail.com (Peter Balazovic)
Date: Sun, 22 Jun 2014 20:05:37 +0200
Subject: [python-win32] Event handling on COM object
Message-ID: <CAFq4t4g7qeC12viuVpERtX8KUGe6ZohVNTK-xG+SRu9nnR7eyw@mail.gmail.com>

Dears,

I have a problem with firing Events and event handling on COM object.

This code works on python console but there is no event fired.

>>> class fmstrEvents(object):
    ...     def OnRecorderDone(self):
    ...         print "Hello OnRecroderDone"

>>> import win32com.client
>>> fm = win32com.client.Dispatch("MCB.PCM")
>>> fm_events = win32com.client.WithEvents(fm,fmstrEvents)

The application fmstr with COM Object "MCB.PCM" is freezing by events
handling within python by pywin32.

Do I miss something in code or incorrectly handling the events or COM
Object?

Thank you very much.
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20140622/4b1d41b2/attachment.html>

From Paul_Koning at Dell.com  Mon Jun 23 16:39:38 2014
From: Paul_Koning at Dell.com (Paul_Koning at Dell.com)
Date: Mon, 23 Jun 2014 14:39:38 +0000
Subject: [python-win32] python3 and extended mapi
In-Reply-To: <lnhl3r$92n$1@ger.gmane.org>
References: <loom.20140609T144550-810@post.gmane.org>
 <1B582A04-F12A-4B35-9ABD-1178A6C4D0A9@dell.com>
 <loom.20140609T204951-734@post.gmane.org>
 <359A340B-B770-4065-9524-A3BB4A86B8DC@dell.com> <539661F2.1070307@hoc.net>
 <477FA935-E489-45CC-8D57-89521245768A@dell.com>
 <loom.20140610T185531-739@post.gmane.org>
 <loom.20140610T191222-788@post.gmane.org> <lnhl3r$92n$1@ger.gmane.org>
Message-ID: <2DA3C8A9-23A3-47DC-BBD8-21E1DBCB5500@dell.com>


On Jun 14, 2014, at 10:10 AM, Christian K. <ckkart at hoc.net> wrote:

>>>  <Paul_Koning <at> Dell.com> writes:
>> 
>>>> I would only want/expect to see ?bytes? types when the values in question
>>> are binary data streams, or
>>>> unknown format.  But anytime we?re dealing with text strings, the Python 3
>>> approach is that the Python
>>>> code sees ?str? type, and questions of encoding have been handled at the
>>> edge.  This is where Python 3
>>> 
>>> This is not true, see above.
>> 
>> What I mean is that you cannot leave it to the application. Once a "str"
>> type is returned is has to be assumed that it contains unicode data. "str"
>> classes do not have a decode method or is there a way to decode the data
>> hold by a "str" object assuming that is encoded and not unicode?
> 
> No objections here? I am not an expert to be without doubts on what I said myself. So please tell me if I am wrong.

A ?str? contains Unicode text, always.

If you have an object that contains encoded text, in some encoding (UTF-8, Latin-1, Win-314159, KOI-8, whatever), then that object *must* be ?bytes?.  You can then obtain the corresponding ?str? by performing a decode operation, running it through the correct Codec for the encoding that was used.  The notion of ?a str object that is encoded? is incorrect.

I suspect you?re still dealing with the damage done by how this was mishandled in Python 2.  Python 3 completely redesigned string handling, and got it right.  It?s helpful to spend some time reading the documentation so you can see what the new scheme is.

The key point is that ?str? is an abstract type (it is ?text? but the concept of encoding is simply not applicable).  You can perform operations on ?str? but it cannot be used in I/O, or any other operation that needs a concrete type (something with a defined representation, say as a  pile of bytes).

Conversely, ?bytes? is concrete ? you can find it in a file, or send it across the network.  ?bytes? can represent all kinds of data.  One of the options is to represent text in some encoding.  To know what a given sequence of bytes means as text, you have to know what the encoding is.  The same sequence of bytes, interpreted as Latin-1 text, is different text than that sequence of bytes interpreted as KOI-8 text.  Both are potentially valid; which (if any) is ?correct? depends on what the creator of that byte string intended.

	paul


From jh_wang2004 at 163.com  Thu Jun 26 12:00:11 2014
From: jh_wang2004 at 163.com (wjh)
Date: Thu, 26 Jun 2014 18:00:11 +0800
Subject: [python-win32] How to pass "out" parameter  to win32com
Message-ID: <000001cf9125$70005080$5000f180$@com>

Dears,

I have a problem with passing out type parameter to win32com function. In C#
envirement one of the COM's function  prototype is:

        int  ActEasyIF.ReadDeviceBlock(string szDevice,   int Isize,  out
int IpIdata);

when calling the function ,it passes a first element of a int array to the
third parameter, like this:

        ACTMULTILib.ActEasyIF aa = new ACTMULTILib.ActEasyIF();

        aa.ReadDeviceBlock("D0",  10,   out da[0]))

The function read 10 integer value from device's register D0 to D9,and write
those integer value to the array da, from 0 to 10 . The function run success
in C#.

I call this COM function by win32comclient in python

>>> from win32com.client import Dispatch

>>> import pythoncom

>>> parser = Dispatch("ActMulti.ActEasyIF")

>>> parser.ActLogicalStationNumber = 1

>>> parser.Open()

0  #Open device success

>>> da = [0] *10

>>> parser.ReadDeviceBlock("D0", 10, da[0])

(0, 256)  #read data success

>>> da   #but.

[0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

After call the function, it returns a tuple,the first element means read
success, second is value read from device's D0 register, but the value don't
write to list da .

I think the problem is the method of calling the third parameter,but how to
pass "out" parameter  to win32com, is there anything hint? 

Thank you very much.
Jianhua

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20140626/012725a1/attachment.html>

From jh_wang2004 at 163.com  Fri Jun 27 04:08:32 2014
From: jh_wang2004 at 163.com (wjh)
Date: Fri, 27 Jun 2014 10:08:32 +0800 (CST)
Subject: [python-win32] How to pass "out" parameter  to win32com
Message-ID: <1f59644c.3c4e.146db14cdce.Coremail.jh_wang2004@163.com>

Dears,

I have a problem with passing out type parameter to win32com function. In C# envirement one of the COM?s function  prototype is:

        int  ActEasyIF.ReadDeviceBlock(string szDevice,   int Isize,  out int IpIdata);

when calling the function ,it passes a first element of a int array to the third parameter, like this:

        ACTMULTILib.ActEasyIF aa = new ACTMULTILib.ActEasyIF();

        aa.ReadDeviceBlock(?D0?,  10,   out da[0]))

The function read 10 integer value from device?s register D0 to D9,and write those integer value to the array da, from 0 to 9 . The function run success in C#.

I call this COM function by win32comclient in python

>>> from win32com.client import Dispatch

>>> import pythoncom

>>> parser = Dispatch("ActMulti.ActEasyIF")

>>> parser.ActLogicalStationNumber = 1

>>> parser.Open()

0  #Open device success

>>> da = [0] *10

>>> parser.ReadDeviceBlock("D0", 10, da[0])

(0, 256)  #read data success

>>> da   #but?

[0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

After call the function, it returns a tuple,the first element means read success, second is value read from device?s D0 register, but the value don?t write to list da .

I think the problem is the method of passing the third parameter,but how to pass "out" parameter  to win32com, is there anything hint?

Thank you very much.
Jianhua

 

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20140627/5fc5f14b/attachment.html>

From timr at probo.com  Fri Jun 27 19:10:42 2014
From: timr at probo.com (Tim Roberts)
Date: Fri, 27 Jun 2014 10:10:42 -0700
Subject: [python-win32] How to pass "out" parameter  to win32com
In-Reply-To: <000001cf9125$70005080$5000f180$@com>
References: <000001cf9125$70005080$5000f180$@com>
Message-ID: <53ADA592.7090306@probo.com>

wjh wrote:
>
> Dears,
>
> I have a problem with passing out type parameter to win32com function.
> In C# envirement one of the COM?s function  prototype is:
>
>         int  ActEasyIF.ReadDeviceBlock(string szDevice,   int Isize, 
> out int IpIdata);
>
> when calling the function ,it passes a first element of a int array to
> the third parameter, like this:
>
>         ACTMULTILib.ActEasyIF aa = new ACTMULTILib.ActEasyIF();
>
>         aa.ReadDeviceBlock(?D0?,  10,   out da[0]))
>
> The function read 10 integer value from device?s register D0 to D9,and
> write those integer value to the array da, from 0 to 10 . The function
> run success in C#.
>

If this actually works, it's an accident, because your declaration is
completely wrong.  The declaration "out int IpData" says you will be
returning exactly ONE int.  It doesn't allow the called function to
return an array of ints, and C# makes no guarantees that consecutive
elements actually follow each other in memory.  This should have been
declared as something like "ref int[] IpData".

What does the function declaration look like in C++ or in the original IDL?


> I call this COM function by win32comclient in python
>
> >>> from win32com.client import Dispatch
>
> >>> import pythoncom
>
> >>> parser = Dispatch("ActMulti.ActEasyIF")
>
> >>> parser.ActLogicalStationNumber = 1
>
> >>> parser.Open()
>
> 0  #Open device success
>
> >>> da = [0] *10
>
> >>> parser.ReadDeviceBlock("D0", 10, da[0])
>
> (0, 256)  #read data success
>

You need to remember that Python always does pass by value.  What this
statement will do is pass the integer value of the first element of
"da", literally 0.  It does not pass the "address" of the "da" array.

For an "out" parameter, you don't usually pass anything at all.  So:
    hr, da = parser.ReadDeviceBlock("DO", 10)

I believe that the (0, 256) represents a successful return (0), and the
value of the first returned element (256).  If your C++ declaration
looks like your C# declaration, then this is exactly what I would
expect, because you are saying that the function returns one integer. 
That's what you got here.


> After call the function, it returns a tuple,the first element means
> read success, second is value read from device?s D0 register, but the
> value don?t write to list da .
>
> I think the problem is the method of calling the third parameter,but
> how to pass "out" parameter  to win32com, is there anything hint?
>

The problem is the way you have declared the function.  Right now, it is
doing exactly what you asked: you said the function has one integer as
output, and that's exactly what you got back.  If you need this to
return an array, then you need to change your IDL so that it returns an
array.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20140627/1f16f229/attachment.html>

From gamz4sale at gmail.com  Sat Jun 28 07:51:49 2014
From: gamz4sale at gmail.com (game4 sale)
Date: Sat, 28 Jun 2014 13:51:49 +0800
Subject: [python-win32] Not able to paste file in windows explorer using
	SetClipboardData
In-Reply-To: <537D95F4.90208@gmail.com>
References: <CAAYb+FWNA3LHyEtw5nBLxrkw=kzdyX5aqvA=rGjUtNi0kjw9CQ@mail.gmail.com>
 <537CD45F.3080204@probo.com>
 <CAAYb+FUB199R4cxvTHxPPx7WKx7y+inXO_4j43HFB1UGgrVj9Q@mail.gmail.com>
 <CAAYb+FVBWS5vusYeay8JCidDpWK6UN3_mJDGR7Tc=D7E4Rf4KA@mail.gmail.com>
 <537D95F4.90208@gmail.com>
Message-ID: <CAAYb+FXFGJuSGdUhpqymnLWowPBU3OJmDsdfkkL1woUcQ2jfGA@mail.gmail.com>

Hi Mark,

Thank you for your suggestion. I made it to work by following the sequence
below:
1) EmptyClipboard()
2) SetClipboardData(CF_UNICODETEXT)
3) SetClipboardData(CF_HDROP, ret_stg.data)

Now am able to paste the images in all supported applications in Windows
7/8.
I am happy with this for now:)


On Thu, May 22, 2014 at 2:15 PM, Mark Hammond <skippy.hammond at gmail.com>
wrote:

> I'd suggest you experiment with EnumClipboardFormats() and see all the
> formats actually in the clipboard - I'm guessing there is another format
> preferred over CF_HDROP.  Similarly, you probably want to call
> EmptyClipboard so the other formats which refer to the initial image are
> removed (and if you do this, you might find it unnecessary to use a
> different format for your replacement image)
>
> HTH,
>
> Mark
>
>
> On 22/05/2014 1:21 PM, game4 sale wrote:
>
>> I tested my code today on Win 7 64 bit, and it worked almost perfect
>> like Tim said.
>>
>> If the previous clipboard content was Text, my code works perfectly.
>>
>> The failure part is:
>> 1) Copy *Image1* from Explorer
>> 2) Run my code to update clipboard with *Image2*
>>
>> 3) Paste operation in Wordpad application or Explorer ends up with only
>> *Image1*
>>
>>
>> Any clues please?Am i missing something?
>> Also how about the OleSetClipboard()? Do you guys think it will improve
>> my case?
>> *
>>
>> *
>>
>>
>> On Thu, May 22, 2014 at 1:02 AM, game4 sale <gamz4sale at gmail.com
>> <mailto:gamz4sale at gmail.com>> wrote:
>>
>>     Thank you very much for your time.
>>
>>     Thats strange. For the login user, i think its same. In my
>>     Taskmanager, under User tab, both the processes are running under
>>     same user.
>>
>>     I also tried to run my script from command prompt with Admin
>>     previlege. Still same, i cannot paste the file in Explorer.
>>
>>     Also, i found out another problem in my code. I can paste the image
>>     in Wordpad application only if the last clipboard content was text.
>>     If the last one was image, i cannot paste my new image. It pastes
>>     only the old image.
>>
>>
>>
>>
>>     On Thu, May 22, 2014 at 12:29 AM, Tim Roberts <timr at probo.com
>>     <mailto:timr at probo.com>> wrote:
>>
>>         game4 sale wrote:
>>
>>>
>>>
>>>         I am trying to copy an image file to windows clipboard using
>>>         my code and paste it manually in any folder in windows
>>>         explorer. I am using *Windows 8* *64bit *laptop, running
>>>         *Python 2.7 *and*pywin32-218* for win32 APIs
>>>
>>>
>>>         I managed to paste my file in Wordpad application. But, i
>>>         cannot paste inside windows explorer. The Paste menu is
>>>         disabled. Any help/suggestions would be much appreciated.
>>>
>>>
>>         I'm confused.  I just ran your exact code on Win 7 64 with
>>         Python 2.7.5 32, unchanged except for the file name, and it
>>         worked perfectly.
>>
>>         Is the script running as the same login user as Explorer?
>>
>>         --
>>         Tim Roberts,timr at probo.com  <mailto:timr at probo.com>
>>
>>         Providenza & Boekelheide, Inc.
>>
>>
>>         _______________________________________________
>>         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/20140628/eec8a027/attachment-0001.html>

From gamz4sale at gmail.com  Sat Jun 28 08:14:37 2014
From: gamz4sale at gmail.com (game4 sale)
Date: Sat, 28 Jun 2014 14:14:37 +0800
Subject: [python-win32] get bitmapbits string from PyBITMAP pointer value
Message-ID: <CAAYb+FWNVUQF6QVnK=-M9mqHWb32VgDzxc=FDwTafhNKP5SJHA@mail.gmail.com>

Hi guys,

I am trying to get BitmapBits from PyBITMAP object. As per the pywin32 doc,
i guess i managed to unpack the PyBITMAP structure to get the pointer to
bitmap bits. But when i use that pointer in PyGetMemory() i get
"ValueError: The value is not a valid address for reading"

Any clues please? How to get those bitmapbits as string from the pointer
value?

Please find my attached code below. I used print screen/Copy image before
running my code.

PS: I used win32ui API GetBitmapBits() successfully, but when i package my
application using py2exe it causes problems loading win32ui.pyd even after
adding MFC related DLLs. So now i am trying to avoid win32ui APIs in my
code (if possible) since i used win32ui only for BMP image handling
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20140628/1862e780/attachment.html>
-------------- next part --------------
from win32api import *
from win32clipboard import *
from win32gui import *
import struct

def get_clipboard():
    try:
        OpenClipboard()
    except:
        print "open clipboard failed"
    else:   
        if(IsClipboardFormatAvailable(CF_BITMAP)):
            print "CF_BITMAP content"
            hbitmap = GetClipboardDataHandle(CF_BITMAP)
            bminfo = GetObject(hbitmap)
            print "bmTy,bmW,bmH,bmWB,bmCP=",bminfo.bmType, bminfo.bmWidth, bminfo.bmHeight, bminfo.bmWidthBytes, bminfo.bmPlanes
            bminfo_list = []
            bminfo_list.append(bminfo.bmType)
            bminfo_list.append(bminfo.bmWidth)
            bminfo_list.append(bminfo.bmHeight)
            bminfo_list.append(bminfo.bmWidthBytes)
            bminfo_list.append(bminfo.bmPlanes)
            addr = id(bminfo)
            fmt="llllll"
            bminfo_buf = PyGetMemory(addr, struct.calcsize(fmt))
            unpacked_list = struct.unpack_from(fmt, bminfo_buf)
            print unpacked_list
            for item in unpacked_list:
                if item not in bminfo_list:
                    bits_addr = item
                    break
            print 'bits_addr =',bits_addr
            bpp = bminfo.bmWidthBytes/bminfo.bmWidth
            tot_bytes = bminfo.bmWidth * bminfo.bmHeight * bpp
            bits_str = PyGetMemory(bits_addr, tot_bytes)
            print 'len of pystr =',len(bits_str)     
        else:
            print "unsupported clipboard format"
    finally:
            CloseClipboard()

if __name__ == '__main__':
    get_clipboard()