pywin32-bugs — Automated tracker notifications (not for bug reports!)

[pywin32-bugs] [ pywin32-Feature Requests-2211970 ] Allow conversion of PyTime to datetime.datetime

[SourceForge.net <no...@so...>]

Feature Requests item #2211970, was opened at 2008-10-31 10:05
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=2211970&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Fraser (davidfraser)
>Assigned to: Roger Upole (rupole)
Summary: Allow conversion of PyTime to datetime.datetime

Initial Comment:
It would be great if you could convert PyTimes directly to datetime objects.

It would be even nicer if they *were* datetime objects, but that's a big change...

----------------------------------------------------------------------

>Comment By: Roger Upole (rupole)
Date: 2008-10-31 11:51

Message:
I'm currently working on allowing datetime.datetime objects to be used
in place of PyTime.  I've also run into the issue noted in bug #2209864
with fractional second truncation when converting variant DATEs.

There's also a large performance hit, since PyTime stores the value
internally as a DATE (really a double), meaning it doesn't have to be
converted back to a float.  However, passing a datetime to/from COM
becomes
really expensive, since it will have to be converted not only
on output, but each and every time it's passed to a function that
needs a DATE.

I'm considering trying to subclass datedate.datetime so we can also store
the variant DATE with it, but haven't looked at it too deeply yet.
In Python 2.3 datetime is pure python, but in 2.4 and up it's a
builtin implemented in C, which may or may not support subclassing.

       Roger


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=2211970&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2211970 ] Allow conversion of PyTime to datetime.datetime

[SourceForge.net <no...@so...>]

Bugs item #2211970, was opened at 2008-10-31 17:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2211970&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Fraser (davidfraser)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow conversion of PyTime to datetime.datetime

Initial Comment:
It would be great if you could convert PyTimes directly to datetime objects.

It would be even nicer if they *were* datetime objects, but that's a big change...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2211970&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2209864 ] PyTime's .msec method always returns 0

[SourceForge.net <no...@so...>]

Bugs item #2209864, was opened at 2008-10-30 16:36
Message generated for change (Comment added) made by davidfraser
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2209864&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Fraser (davidfraser)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyTime's .msec method always returns 0

Initial Comment:
PyTime stores times internally as DATE objects, which support fractional second resolution (since they are just a double number of days).

However the method to retrieve attributes including msec uses the Win32 VariantTimeToSystemTime function to convert the m_time to a SYSTEMTIME.

This function is known not to convert the fractional part of seconds (see http://support.microsoft.com/kb/297463, and http://www.codeproject.com/KB/datetime/SysTimeToVarTimeWMillisec.aspx for some example workaround code).

So although the fractional part is actually stored in the PyTime object, it cannot be retrieved.

----------------------------------------------------------------------

>Comment By: David Fraser (davidfraser)
Date: 2008-10-30 17:06

Message:
I've attached a very simple patch that calculates the .msec value on
request.
Note that since .msec has never returned anything but 0, and the builtin
datetime object has a microsecond attribute, it may be worthwhile to
repurpose this .msec attribute to mean "microseconds" rather than
"seconds"

It would also be worthwhile to patch the various Time constructors to
ensure that they preserve sub-second resolution if given (e.g.
pywintypes.Time(time.time()) currently discards it)
File Added: pywin32-pytime-calc-msec.patch

----------------------------------------------------------------------

Comment By: David Fraser (davidfraser)
Date: 2008-10-30 16:47

Message:
A fairly simple workaround is to convert the PyTime directly to a float.
For example, the following code converts to datetime:

def WinPyTimeToDate(pytime):
  """Converts a pywintypes.PyTime object into a date object"""
  microseconds = int(((float(pytime)*24*60*60) % 1)*1000000)
  return date(pytime.year, pytime.month, pytime.day, pytime.hour,
pytime.minute, pytime.second, microseconds)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2209864&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2209864 ] PyTime's .msec method always returns 0

[SourceForge.net <no...@so...>]

Bugs item #2209864, was opened at 2008-10-30 16:36
Message generated for change (Comment added) made by davidfraser
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2209864&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Fraser (davidfraser)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyTime's .msec method always returns 0

Initial Comment:
PyTime stores times internally as DATE objects, which support fractional second resolution (since they are just a double number of days).

However the method to retrieve attributes including msec uses the Win32 VariantTimeToSystemTime function to convert the m_time to a SYSTEMTIME.

This function is known not to convert the fractional part of seconds (see http://support.microsoft.com/kb/297463, and http://www.codeproject.com/KB/datetime/SysTimeToVarTimeWMillisec.aspx for some example workaround code).

So although the fractional part is actually stored in the PyTime object, it cannot be retrieved.

----------------------------------------------------------------------

>Comment By: David Fraser (davidfraser)
Date: 2008-10-30 16:47

Message:
A fairly simple workaround is to convert the PyTime directly to a float.
For example, the following code converts to datetime:

def WinPyTimeToDate(pytime):
  """Converts a pywintypes.PyTime object into a date object"""
  microseconds = int(((float(pytime)*24*60*60) % 1)*1000000)
  return date(pytime.year, pytime.month, pytime.day, pytime.hour,
pytime.minute, pytime.second, microseconds)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2209864&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2209864 ] PyTime's .msec method always returns 0

[SourceForge.net <no...@so...>]

Bugs item #2209864, was opened at 2008-10-30 16:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2209864&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Fraser (davidfraser)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyTime's .msec method always returns 0

Initial Comment:
PyTime stores times internally as DATE objects, which support fractional second resolution (since they are just a double number of days).

However the method to retrieve attributes including msec uses the Win32 VariantTimeToSystemTime function to convert the m_time to a SYSTEMTIME.

This function is known not to convert the fractional part of seconds (see http://support.microsoft.com/kb/297463, and http://www.codeproject.com/KB/datetime/SysTimeToVarTimeWMillisec.aspx for some example workaround code).

So although the fractional part is actually stored in the PyTime object, it cannot be retrieved.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2209864&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1869586 ] win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6

[SourceForge.net <no...@so...>]

Bugs item #1869586, was opened at 2008-01-11 13:01
Message generated for change (Comment added) made by jaraco
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Antoine LECA (antoinel)
Assigned to: Jason R. Coombs (jaraco)
Summary: win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6

Initial Comment:
win32timezone.GetSortedTimeZoneNames() uses the default value of win32timezone.GetIndexedTimeZoneNames()'s index_key, which is 'Index'.

This entry was added to NT5 (Windows 2000) registry, and was not present before, i.e. in NT4 (even with all the patch applied).

Furthermore, there is a important change between the two versions, in NT4 (and NT3 before) the key (e.g. 'Mountain Standard Time') was localized (so it ends as 'Montañas Hora estándar' on one box here, and as 'Heure d'hiver Montagnes Roch.' on another there.) So there is no easy way to add this index, or either to retrieve it from some other way.

A workarounds would be to use the 'Display' (will display Ahead-of-GMT zones in order, then Behind-of-GMT zones in reverse order; not completely wrong but not smart); another (bad) workaround would be to use the 'TZI' field, but since it is stored little-endian, the resulting sort looks weird.

The best I can find is to use the Bias field, which is the first bytes of the TZI fields; two bytes are enough to get an acceptable data; however the required change to GetIndexedTimeZoneRange is non-trivial, so it will have an impact on performance (even out of NT4).


By the way, the 'Index' does not exist in Vista either (at least as it is shipped from Microsoft, I understand that some of the patches floating around to deal with the 2007 DST issue in the United States may have change this since the zones names do not vary much between NT5 and NT6)


At first sight (source inspection), the current (1.78) CVS revision of win32timezone.py module carries the same problem, including for Vista... I'll try to do more test if I can. For Vista, a possible solution (=kludge) would be to use the indices of the resources in tzres.dll, which are monotically increasing following the same order as the Index field. Yes, it's a groß hack!

----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2008-10-24 17:14

Message:
Antoine, I've modified the behavior to use the TimeZoneInfo.staticInfo.bias
for the default sort order.  I think this new version should be a drop-in
replacement for most users.  It works for me in Windows Vista.  Can you
test it in your NT4 environment?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2174265 ] return object from method fails

[SourceForge.net <no...@so...>]

Bugs item #2174265, was opened at 2008-10-17 10:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2174265&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Enrico (enrico-b)
Assigned to: Nobody/Anonymous (nobody)
Summary: return object from method fails

Initial Comment:
>From pippo.idl (in test directory)
HRESULT Method1([out, retval] IPippo **val)

When called from C++ there's an exception

I attach a client written with python and comtypes and, with a little effort I
can see the problem is a call to QueryInterface with IID_NULL (as happens if the caller
is a C++ client).

client: pippo-test.py

To show the problem I registered the pippo_server with the --debug option.
Then I changed the function Method1 in this way to have a debug output:

    def Method1(self):
        #return wrap(CPippo())
        return wrap(CPippo(),useDispatcher=1)

Last, in the file policy.py at line 261, at the begin of the
_QueryInterface_ function I added a line:
    print iid

The result in PythonWin trace Collector is:

Object with win32trace dispatcher created (object=None)
Object with win32trace dispatcher created (object=<pippo_server.CPippo
instance at 0x015DF210>)
{00000000-0000-0000-0000-000000000000}Traceback (most recent call last):
  File "C:Python25Libsite-packageswin32comserverdispatcher.py", line 41, in
_QueryInterface_
    return self.policy._QueryInterface_(iid)
  File "C:Python25libsite-packageswin32comserverpolicy.py", line 261, in
_QueryInterface_
    print iid
com_error: (-2147221005, "Stringa dell'interfaccia non valida.", None, None)
pythoncom error: Failed to call the universal dispatcher


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2174265&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2164420 ] win32trace not working as expected: IIS 7

[SourceForge.net <no...@so...>]

Bugs item #2164420, was opened at 2008-10-13 16:00
Message generated for change (Comment added) made by jaraco
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2164420&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32trace not working as expected: IIS 7

Initial Comment:
I'm using pywin32-212 on Python 2.5.2 (32-bit) on Windows Vista (64-bit).

I'm trying to wire up a WSGI application in IIS using isapi-wsgi, but I find that the win32traceutil isn't logging anything.

I've started the collector process using: python -m win32traceutil.

I've tested it by running: python -c "import win32traceutil; print 'working'"
and note that the collector prints the string.

I've installed IIS 7 with IIS 6 WMI compatibility.  I've created a 32-bit application pool.  I've created a web site assigned to a 32-bit application pool (called Legacy Development).

Then, I copy isapi/samples/test.py to /inetpub/isapi_test.  I modify it by adding the following to the section indicated by "default response":
            print 'This should show up in the trace util'

Then install the isapi test using:
.\test.py install "--server=Legacy Development"

The app installs correctly, so I browse to http://url.to.the.server/PyISAPITest and I get the default response in the browser, but nothing is logged to the win32trace collector.

I expect that "This should show up in the trace util" should appear in the collector.

What more can I do to investigate/workaround/resolve the issue?


----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2008-10-14 12:43

Message:
Further testing confirms this problem does not exhibit itself on IIS 5.1
(Windows XP), so the problem appears to be isolated to IIS 7 (maybe 6) or
Windows Vista.

----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2008-10-14 10:35

Message:
I've performed additional testing on a 32-bit Vista machine.  The behavior
is the same... win32traceutil does not receive any output from the ISAPI
process.  Therefore, the problem is not related to the 64-bit platform
aspects.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2164420&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2164420 ] win32trace not working as expected: IIS 7

[SourceForge.net <no...@so...>]

Bugs item #2164420, was opened at 2008-10-13 16:00
Message generated for change (Comment added) made by jaraco
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2164420&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32trace not working as expected: IIS 7

Initial Comment:
I'm using pywin32-212 on Python 2.5.2 (32-bit) on Windows Vista (64-bit).

I'm trying to wire up a WSGI application in IIS using isapi-wsgi, but I find that the win32traceutil isn't logging anything.

I've started the collector process using: python -m win32traceutil.

I've tested it by running: python -c "import win32traceutil; print 'working'"
and note that the collector prints the string.

I've installed IIS 7 with IIS 6 WMI compatibility.  I've created a 32-bit application pool.  I've created a web site assigned to a 32-bit application pool (called Legacy Development).

Then, I copy isapi/samples/test.py to /inetpub/isapi_test.  I modify it by adding the following to the section indicated by "default response":
            print 'This should show up in the trace util'

Then install the isapi test using:
.\test.py install "--server=Legacy Development"

The app installs correctly, so I browse to http://url.to.the.server/PyISAPITest and I get the default response in the browser, but nothing is logged to the win32trace collector.

I expect that "This should show up in the trace util" should appear in the collector.

What more can I do to investigate/workaround/resolve the issue?


----------------------------------------------------------------------

>Comment By: Jason R. Coombs (jaraco)
Date: 2008-10-14 10:35

Message:
I've performed additional testing on a 32-bit Vista machine.  The behavior
is the same... win32traceutil does not receive any output from the ISAPI
process.  Therefore, the problem is not related to the 64-bit platform
aspects.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2164420&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2164420 ] win32trace not working as expected: IIS 7

[SourceForge.net <no...@so...>]

Bugs item #2164420, was opened at 2008-10-13 16:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2164420&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32trace not working as expected: IIS 7

Initial Comment:
I'm using pywin32-212 on Python 2.5.2 (32-bit) on Windows Vista (64-bit).

I'm trying to wire up a WSGI application in IIS using isapi-wsgi, but I find that the win32traceutil isn't logging anything.

I've started the collector process using: python -m win32traceutil.

I've tested it by running: python -c "import win32traceutil; print 'working'"
and note that the collector prints the string.

I've installed IIS 7 with IIS 6 WMI compatibility.  I've created a 32-bit application pool.  I've created a web site assigned to a 32-bit application pool (called Legacy Development).

Then, I copy isapi/samples/test.py to /inetpub/isapi_test.  I modify it by adding the following to the section indicated by "default response":
            print 'This should show up in the trace util'

Then install the isapi test using:
.\test.py install "--server=Legacy Development"

The app installs correctly, so I browse to http://url.to.the.server/PyISAPITest and I get the default response in the browser, but nothing is logged to the win32trace collector.

I expect that "This should show up in the trace util" should appear in the collector.

What more can I do to investigate/workaround/resolve the issue?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2164420&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1869586 ] win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6

[SourceForge.net <no...@so...>]

Bugs item #1869586, was opened at 2008-01-11 13:01
Message generated for change (Settings changed) made by jaraco
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Antoine LECA (antoinel)
>Assigned to: Jason R. Coombs (jaraco)
Summary: win32timezone.GetSortedTimeZoneNames() doesn't work on NT4|6

Initial Comment:
win32timezone.GetSortedTimeZoneNames() uses the default value of win32timezone.GetIndexedTimeZoneNames()'s index_key, which is 'Index'.

This entry was added to NT5 (Windows 2000) registry, and was not present before, i.e. in NT4 (even with all the patch applied).

Furthermore, there is a important change between the two versions, in NT4 (and NT3 before) the key (e.g. 'Mountain Standard Time') was localized (so it ends as 'Montaas Hora estndar' on one box here, and as 'Heure d'hiver Montagnes Roch.' on another there.) So there is no easy way to add this index, or either to retrieve it from some other way.

A workarounds would be to use the 'Display' (will display Ahead-of-GMT zones in order, then Behind-of-GMT zones in reverse order; not completely wrong but not smart); another (bad) workaround would be to use the 'TZI' field, but since it is stored little-endian, the resulting sort looks weird.

The best I can find is to use the Bias field, which is the first bytes of the TZI fields; two bytes are enough to get an acceptable data; however the required change to GetIndexedTimeZoneRange is non-trivial, so it will have an impact on performance (even out of NT4).


By the way, the 'Index' does not exist in Vista either (at least as it is shipped from Microsoft, I understand that some of the patches floating around to deal with the 2007 DST issue in the United States may have change this since the zones names do not vary much between NT5 and NT6)


At first sight (source inspection), the current (1.78) CVS revision of win32timezone.py module carries the same problem, including for Vista... I'll try to do more test if I can. For Vista, a possible solution (=kludge) would be to use the indices of the resources in tzres.dll, which are monotically increasing following the same order as the Index field. Yes, it's a gro hack!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1869586&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2152547 ] version 212 & 211 Always crash on my machine

[SourceForge.net <no...@so...>]

Bugs item #2152547, was opened at 2008-10-08 11:26
Message generated for change (Comment added) made by truthtracer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2152547&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Truth Tracer (truthtracer)
Assigned to: Nobody/Anonymous (nobody)
Summary: version 212 & 211 Always crash on my machine

Initial Comment:
since I updated pywin32 from ver 210 to 212, it always crashed on my machine (win2003 std sp2/Intel P4 2.4GHZ/1GB RAM/.net 3.5 & vs 2008 installed).

When I run pywin32.exe and type some code (a=1 or import string ...) and press 'Enter' then pywin32 crashes.

I don't know whether it is a bug or something is wrong with my machine,but there is a fact is : older pywin32(version 210, build on 2006) works very well on the same machine for a long time.

btw, I can't report these as a bug because sf said that I'm not a member of this project.

----------------------------------------------------------------------

>Comment By: Truth Tracer (truthtracer)
Date: 2008-10-08 17:22

Message:
When I close the interactive window and re-open it, I saw many '='
characters in it and then pywin32 crashes.(I have installed Python 2.6
final,build on Oct,2008)

All the crashes can be repeatable on my machine.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2152547&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2152547 ] version 212 & 211 Always crash on my machine

[SourceForge.net <no...@so...>]

Bugs item #2152547, was opened at 2008-10-08 11:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2152547&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Truth Tracer (truthtracer)
Assigned to: Nobody/Anonymous (nobody)
Summary: version 212 & 211 Always crash on my machine

Initial Comment:
since I updated pywin32 from ver 210 to 212, it always crashed on my machine (win2003 std sp2/Intel P4 2.4GHZ/1GB RAM/.net 3.5 & vs 2008 installed).

When I run pywin32.exe and type some code (a=1 or import string ...) and press 'Enter' then pywin32 crashes.

I don't know whether it is a bug or something is wrong with my machine,but there is a fact is : older pywin32(version 210, build on 2006) works very well on the same machine for a long time.

btw, I can't report these as a bug because sf said that I'm not a member of this project.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2152547&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2146476 ] Program runs in idle, crashes pythonwin

[SourceForge.net <no...@so...>]

Bugs item #2146476, was opened at 2008-10-04 09:34
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2146476&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: paul hide (paulhide)
>Assigned to: Roger Upole (rupole)
Summary: Program runs in idle, crashes pythonwin

Initial Comment:
I'm not sure whether this is the sort of thing that is of interest or not, but in case it is.
The following code and events cause pythonwin to crash, but in Idle it runs as expected.
Win xp
python 2.5.2

import Console #downloaded from effbot.org
cons = Console.getconsole()
#dos box pops up, close it using X, pythonwin crashes
#in Idle it runs ok

Paul Hide

----------------------------------------------------------------------

>Comment By: Roger Upole (rupole)
Date: 2008-10-06 18:46

Message:
You can also get the same effect using win32console.AllocConsole()
from Pythonwin.  I think MFC is not playing nice with the console
Api's.  At one time, I tried using a console control handler
(win32api.SetConsoleCtrlHandler).  This stops pythonwin from
crashing, but you get the 'Windows cannot end this program'
dialog when you try to close the console.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2146476&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2146476 ] Program runs in idle, crashes pythonwin

[SourceForge.net <no...@so...>]

Bugs item #2146476, was opened at 2008-10-04 14:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2146476&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: paul hide (paulhide)
Assigned to: Nobody/Anonymous (nobody)
Summary: Program runs in idle, crashes pythonwin

Initial Comment:
I'm not sure whether this is the sort of thing that is of interest or not, but in case it is.
The following code and events cause pythonwin to crash, but in Idle it runs as expected.
Win xp
python 2.5.2

import Console #downloaded from effbot.org
cons = Console.getconsole()
#dos box pops up, close it using X, pythonwin crashes
#in Idle it runs ok

Paul Hide

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2146476&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2132639 ] win32file.GetCommState incorrect handling of DCB

[SourceForge.net <no...@so...>]

Bugs item #2132639, was opened at 2008-09-27 14:56
Message generated for change (Comment added) made by jiaailun
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2132639&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
>Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alan Gardner (jiaailun)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.GetCommState incorrect handling of DCB

Initial Comment:
I believe I have found a bug in win32file.GetCommState and win32file.SetCommState.  I have seen it in Python 2.4 and Python 2.5, running an older version of pywin32, as well as the current (212) version.  It exists in Win2k and WinXP.  I use pyserial 2.4 as a wrapper for the comm ports, though I believe the problem is in win32file.

The problem manifests itself when I try to open a com port in Python after having that port open in Procomm (an old, no longer supported terminal program).  I have only seen it happen with a particular brand of USB to serial converters (Edgeport, made by Digi).  In these conditions the python script will hang at the win32file.SetCommState() command, usually timing out after 5-30 seconds, and quitting with no error message.

After having done some probing I think I basically understand the problem, and have a workaround, but I lack the know-how to fix it where it should be fixed, in win32file.  When Procomm opens the port, it sets XoffLim to 16128 and the XonLim to 15872.  When my script (actually, serialwin32.py from pyserial) tries to open the port it first reads the DCB with GetCommState(), changes baud rate, etc in the local PyDCB object, and then tries to reconfigure the port with SetCommState().  

>From what I can tell, SetCommState won't accept a value for XoffLim or XonLim >4096.  For example, if I try to execute the following:
DCB.XoffLim = 16128
SetCommState(porthandle,DCB)

I get an exception: (87, 'SetCommState', 'The parameter is incorrect.')

However, if GetCommState gets a DCB which has XoffLim = 16128, and then that DCB is passed to SetCommState, the script hangs for several seconds before exiting without opening the port and with no error message.  For example, after having opened and closed the port in Procomm:

>>> DCB = GetCommState(porthandle)
>>> DCB.XoffLim
16128L
>>> SetCommState(porthandle,DCB)
(...... hangs here for several seconds ......)

If I set XoffLim and XonLim to values from 0-4096 before calling SetCommState, then it works fine.  For example, after having opened and closed the port in Procomm:

>>> DCB = GetCommState(porthandle)
>>> DCB.XoffLim = 128
>>> DCB.XonLim = 512
>>> SetCommState(porthandle,DCB)
>>>
This works fine, and I can go on to open the port normally.  I have incorporated this fix into serialwin32.py which is working for me now, but it's not an elegant solution.  I am still baffled by why
SetCommState limits Xon/XoffLim to 4096, and by what GetCommState does to the PyDCB to make it cause SetCommState to fail so dramatically.  I also don't understand why I only see this problem with the Edgeport USB converters, and not with several other USB converters or hardware serial ports.  Maybe someone with a more intimate understanding of Python and Win32 can come up with some answers.

Thank you
-Alan Gardner
Woods Hole Oceanographic Institution
Woods Hole, MA 02543

----------------------------------------------------------------------

>Comment By: Alan Gardner (jiaailun)
Date: 2008-10-02 09:11

Message:
Gentlemen,
I appreciate your time helping me work this out.  I have been in contact
with the vendor, and after trying several things they had started to point
the finger at Python.  I am feeling pretty confident now that the problem
is not related to Python, and I have a reasonably good handle on what's
going on.  I will follow up with the vendor.  Unfortunately Procomm is
unsupported now, but I really don't think that it is doing anything
"wrong", it just leaves the port in a state that the driver reacts badly
to.  I will follow up here if I learn anything more.
Thank you.
-Alan

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-10-01 17:23

Message:
The code to call SetCommState does not do any retries.
If you're seeing multiple attempts to set the configuration
parameters, they're probably coming from the driver itself.

Since this problem only happens for a particular device, and
only after a completely separate program has accessed it,
it's most likely due to the device driver, and/or the
state in which the other program leaves the port.  I really
don't think there's anything that can be done in win32file
to solve it.

 

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-09-30 00:52

Message:
If you think pywin32 is doing something incorrect with its DCB handling,
the only real way to demonstrate that is a snippet of C code that behaves
differently.  Given our arg handling looks OK, we will otherwise need to
assume the behaviour is just a characteristic of the windows API itself.

----------------------------------------------------------------------

Comment By: Alan Gardner (jiaailun)
Date: 2008-09-30 00:41

Message:
OK, since I realize this may be a difficult problem to recreate I have
annotated some screen captures from the interpreter.  In the process I
realized that the XonLim and XoffLim are obviously going to be limited by
the buffer size, and yes, pyserial does set the buffer to 4096.  OK, so now
I have another workaround, increasing the buffer size so that the XonLim
and XoffLim values are no longer to large.  But I still think that there is
an underlying bug.  When a port is opened with CreateFile it appears to
assign a default buffer size, and this can lead to XonLim and XoffLim
values which are out of range.  If SetCommState then tries to set an out of
range value to one of these parameters, it hangs.  I have some captures
from DebugView and PortMon which show Python.exe repeatedly getting and
setting parameters on the serial port in a nearly endless loop.  I can
upload these if it would be helpful, but they are moderately large and
arcane.  For now I will upload the annotated screen captures showing what I
see at this end.
File Added: win32file.SetCommState_interactive.txt

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-09-27 16:13

Message:
I don't see any problem with the way the DCB is passed to/from
SetCommState and GetCommState.  The XonLim and XoffLim members
consistently have the correct value.

If I recall from looking at pyserial a while back, it sets the
buffer sizes to 4096.  Have you tried increasing them in the
call to SetupComm ?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2132639&group_id=78018

[pywin32-bugs] [ pywin32-Patches-2141368 ] win32event.MsgWaitForMultipleObjectsEx() segfaults

[SourceForge.net <no...@so...>]

Patches item #2141368, was opened at 2008-10-02 09:51
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2141368&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Ziga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32event.MsgWaitForMultipleObjectsEx() segfaults

Initial Comment:
win32event.MsgWaitForMultipleObjectsEx() segfaults if
you call it with an empty list of handles (I didn't try
calling with non-empty list).
The docs say that this should be possible, see: 
http://blogs.msdn.com/oldnewthing/archive/2006/01/25/517395.aspx
(OK, it's not exactly documentation :)

The problem lies in dynamic loading of said function.
Since the win32event module already requires Windows XP,
(#define _WIN32_WINNT 0x0501), and this function was
added in Windows NT 4.0, I simply removed the dynamic
loading.

The patch also contains a very basic test.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2008-10-02 11:41

Message:
Thanks - I checked the changes in:
Checking in src/win32event.i;
new revision: 1.10; previous revision: 1.9
Checking in test/test_win32event.py;
new revision: 1.2; previous revision: 1.1

I'm guessing the lack of a calling convention on the function pointer was
the problem.

FYI, the _WIN32_WINNT macro isn't reliable in this context - often we use
a higher version to get the structure definitions, but still take care to
dynamically load the function pointers that don't exist in all versions we
support.  In this case though you are correct - the function is now
available in all versions we support, so I just nuked the dynamic load code
too rather than verifying it was the calling convention.

Thanks!

----------------------------------------------------------------------

Comment By: Ziga Seilnacht (zseil)
Date: 2008-10-02 10:49

Message:
Of course, I forgot to update the test in the second version of
the patch... Here is the third, and hopefully last version.
File Added: MsgWaitForMultipleObjectsEx3.diff

----------------------------------------------------------------------

Comment By: Ziga Seilnacht (zseil)
Date: 2008-10-02 10:31

Message:
Ok, the old version segfaults even if you have nonempty list:

>>> import win32event
>>> event = win32event.CreateEvent(None, 0, 0, None)
>>> res = win32event.MsgWaitForMultipleObjectsEx([event], 0, 0, 0, 0)  -> 
segfault

This is on Windows XP SP3. Since it looks that this function was
never usable, I attach a new patch that also changes its interface.

The native MsgWaitForMultipleObjectsEx() function doesn't have a
fWaitAll parameter, but the Python wrapper did have it and never did
anything with it. So this updated patch simply removes it.
File Added: MsgWaitForMultipleObjectsEx2.diff

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2141368&group_id=78018

[pywin32-bugs] [ pywin32-Patches-2141368 ] win32event.MsgWaitForMultipleObjectsEx() segfaults

[SourceForge.net <no...@so...>]

Patches item #2141368, was opened at 2008-10-02 01:51
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2141368&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ziga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32event.MsgWaitForMultipleObjectsEx() segfaults

Initial Comment:
win32event.MsgWaitForMultipleObjectsEx() segfaults if
you call it with an empty list of handles (I didn't try
calling with non-empty list).
The docs say that this should be possible, see: 
http://blogs.msdn.com/oldnewthing/archive/2006/01/25/517395.aspx
(OK, it's not exactly documentation :)

The problem lies in dynamic loading of said function.
Since the win32event module already requires Windows XP,
(#define _WIN32_WINNT 0x0501), and this function was
added in Windows NT 4.0, I simply removed the dynamic
loading.

The patch also contains a very basic test.

----------------------------------------------------------------------

>Comment By: Ziga Seilnacht (zseil)
Date: 2008-10-02 02:49

Message:
Of course, I forgot to update the test in the second version of
the patch... Here is the third, and hopefully last version.
File Added: MsgWaitForMultipleObjectsEx3.diff

----------------------------------------------------------------------

Comment By: Ziga Seilnacht (zseil)
Date: 2008-10-02 02:31

Message:
Ok, the old version segfaults even if you have nonempty list:

>>> import win32event
>>> event = win32event.CreateEvent(None, 0, 0, None)
>>> res = win32event.MsgWaitForMultipleObjectsEx([event], 0, 0, 0, 0)  -> 
segfault

This is on Windows XP SP3. Since it looks that this function was
never usable, I attach a new patch that also changes its interface.

The native MsgWaitForMultipleObjectsEx() function doesn't have a
fWaitAll parameter, but the Python wrapper did have it and never did
anything with it. So this updated patch simply removes it.
File Added: MsgWaitForMultipleObjectsEx2.diff

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2141368&group_id=78018

[pywin32-bugs] [ pywin32-Patches-2141368 ] win32event.MsgWaitForMultipleObjectsEx() segfaults

[SourceForge.net <no...@so...>]

Patches item #2141368, was opened at 2008-10-02 01:51
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2141368&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ziga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32event.MsgWaitForMultipleObjectsEx() segfaults

Initial Comment:
win32event.MsgWaitForMultipleObjectsEx() segfaults if
you call it with an empty list of handles (I didn't try
calling with non-empty list).
The docs say that this should be possible, see: 
http://blogs.msdn.com/oldnewthing/archive/2006/01/25/517395.aspx
(OK, it's not exactly documentation :)

The problem lies in dynamic loading of said function.
Since the win32event module already requires Windows XP,
(#define _WIN32_WINNT 0x0501), and this function was
added in Windows NT 4.0, I simply removed the dynamic
loading.

The patch also contains a very basic test.

----------------------------------------------------------------------

>Comment By: Ziga Seilnacht (zseil)
Date: 2008-10-02 02:31

Message:
Ok, the old version segfaults even if you have nonempty list:

>>> import win32event
>>> event = win32event.CreateEvent(None, 0, 0, None)
>>> res = win32event.MsgWaitForMultipleObjectsEx([event], 0, 0, 0, 0)  -> 
segfault

This is on Windows XP SP3. Since it looks that this function was
never usable, I attach a new patch that also changes its interface.

The native MsgWaitForMultipleObjectsEx() function doesn't have a
fWaitAll parameter, but the Python wrapper did have it and never did
anything with it. So this updated patch simply removes it.
File Added: MsgWaitForMultipleObjectsEx2.diff

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2141368&group_id=78018

[pywin32-bugs] [ pywin32-Patches-2141368 ] win32event.MsgWaitForMultipleObjectsEx() segfaults

[SourceForge.net <no...@so...>]

Patches item #2141368, was opened at 2008-10-02 01:51
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2141368&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ziga Seilnacht (zseil)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32event.MsgWaitForMultipleObjectsEx() segfaults

Initial Comment:
win32event.MsgWaitForMultipleObjectsEx() segfaults if
you call it with an empty list of handles (I didn't try
calling with non-empty list).
The docs say that this should be possible, see: 
http://blogs.msdn.com/oldnewthing/archive/2006/01/25/517395.aspx
(OK, it's not exactly documentation :)

The problem lies in dynamic loading of said function.
Since the win32event module already requires Windows XP,
(#define _WIN32_WINNT 0x0501), and this function was
added in Windows NT 4.0, I simply removed the dynamic
loading.

The patch also contains a very basic test.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2141368&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2118863 ] Error compiling

[SourceForge.net <no...@so...>]

Bugs item #2118863, was opened at 2008-09-19 08:59
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2118863&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Farzin Shakib (acusim)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error compiling

Initial Comment:
I just obtained the pywin32-212.zip and attempted to build it, but got the following error:

$ python setup.py install 
Building pywin32 2.4.212.0
running install
running build
running build_py
running build_ext
Found version 0x500 in C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\PlatformSDK\include\WinResrc.h
building 'pywintypes' extension
c:\Program Files\Microsoft Visual Studio .NET 2003\VC7\BIN\cl.exe /c /nologo /Ob2ty /MD /W3 /EHsc /DNDEBUG -DDISTUTILS_BUILD -Icom/win32com/src/include -Iwin32/src -Ic:\Acusim\Win\V1.3\base\include -Ic:\Acusim\Win\V1.3\base\PC /Tpwin32\src\PyACL.cpp /Fobuild\temp.win32-2.4\Release\win32\src\PyACL.obj -DBUILD_PYWINTYPES /YXPyWinTypes.h /Fpbuild\temp.win32-2.4\Release\pywintypes.pch /Zi /Fdbuild\temp.win32-2.4\Release\pywintypes_vc.pdb /EHsc /DMFC_OCC_IMPL_H=\"..\src\occimpl.h\"
PyACL.cpp
win32\src\PyACL.cpp(4) : fatal error C1083: Cannot open precompiled header file: 'build\temp.win32-2.4\Release\pywintypes.pch': The process cannot access the file because it is being used by another process.

This is done on a Windows 2000.

Any ideas how to resolve this issue?

Farzin



----------------------------------------------------------------------

Comment By: Ziga Seilnacht (zseil)
Date: 2008-10-02 01:13

Message:
You should update your Platform SDK. Search for:
"Microsoft Windows Software Development Kit Update for Windows Vista"
on the Microsoft download site. Note that the latest version,
"Windows SDK for Windows Server 2008 and .NET Framework 3.5", won't
work with Visual Studio 2003.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2118863&group_id=78018

[pywin32-bugs] [ pywin32-Feature Requests-1874046 ] "def" code folding, "class" code folding

[SourceForge.net <no...@so...>]

Feature Requests item #1874046, was opened at 2008-01-17 14:32
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1874046&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Jack (gurkesaft)
Assigned to: Roger Upole (rupole)
Summary: "def" code folding, "class" code folding

Initial Comment:
Hello again,

I think it would also be nice if it were possible to fold all the second-level indents, such as the all the def's inside a class for easy navigation (and the ability to maybe do both class and def folding on startup).

Thanks!
Jack

----------------------------------------------------------------------

>Comment By: Roger Upole (rupole)
Date: 2008-10-01 17:04

Message:
This is implemented in the latest release.

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-06-13 16:00

Message:
Logged In: YES 
user_id=771074
Originator: NO

This ability has been added via keyboard shortcuts
(Shift + keypad plus and shift + keypad minus)
The changes should work with any recent release, so
you can grab the latest versions of default.cfg and
coloreditor.py from CVS and try it out to see if this
does what you want.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1874046&group_id=78018

[pywin32-bugs] [ pywin32-Feature Requests-2103779 ] Add Unicode versions for Registry functions

[SourceForge.net <no...@so...>]

Feature Requests item #2103779, was opened at 2008-09-10 08:39
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=2103779&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Wim (wim_h)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add Unicode versions for Registry functions

Initial Comment:
pywin32 build 211 has additional functions added for Unicode strings, like: RegEnumKeyExW, RegQueryInfoKeyW.

However, RegOpenKeyExW and RegQueryValueExW are missing... causing problems on Japanese and Chinese Windows versions.


Please, please add RegOpenKeyExW and RegQueryValueExW...



----------------------------------------------------------------------

>Comment By: Roger Upole (rupole)
Date: 2008-10-01 17:02

Message:
win32api can now be built as full unicode, so that all the available
registry functions call the underlying wide-char api functions.
It hasn't been released this way yet, however.

When we finally have a py3k release, all the modules will be built
using unicode APIs.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=2103779&group_id=78018

[pywin32-bugs] [ pywin32-Feature Requests-1530394 ] 64-bit platform support

[SourceForge.net <no...@so...>]

Feature Requests item #1530394, was opened at 2006-07-28 08:44
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1530394&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: 64-bit platform support

Initial Comment:
I realize this project is called pywin32.  
Nevertheless, it seems the appropriate place to 
suggest a port to 64-bit platforms, particularly the 
x64 platform, as it is very close to the 32-bit 
equivalent.

I searched around and didn't find any discussion on 
this topic.

I'm willing to assist with the effort.

----------------------------------------------------------------------

>Comment By: Roger Upole (rupole)
Date: 2008-10-01 16:55

Message:
The 2.6 release has a 64-bit version, and the project can
be built for Python 2.5 64-bit now.  We should also have a
64-bit release for py3k eventually.


----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2006-07-29 23:50

Message:
Logged In: YES 
user_id=771074

It will require a number of changes relating to the various 
types of HANDLEs.  Currently they're treated as longs 
(which stay 4 bytes), but in win64 HANDLEs are 8 bytes.

However, it looks like there will be more changes for 64bit 
python than for 64 bit windows.  I count 1300-odd uses of 
python API functions that will need to be converted to 
Py_ssize_t.  There are also a lot of places where s# is 
used with PyArg_ParseTuple that will need to be converted.
Many of them place the length in a 32-bit value that's 
passed directly to a Windows api function, so they'll need 
an intermediate variable with a bounds checks.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1530394&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-2132639 ] win32file.GetCommState incorrect handling of DCB

[SourceForge.net <no...@so...>]

Bugs item #2132639, was opened at 2008-09-27 13:56
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2132639&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Alan Gardner (jiaailun)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.GetCommState incorrect handling of DCB

Initial Comment:
I believe I have found a bug in win32file.GetCommState and win32file.SetCommState.  I have seen it in Python 2.4 and Python 2.5, running an older version of pywin32, as well as the current (212) version.  It exists in Win2k and WinXP.  I use pyserial 2.4 as a wrapper for the comm ports, though I believe the problem is in win32file.

The problem manifests itself when I try to open a com port in Python after having that port open in Procomm (an old, no longer supported terminal program).  I have only seen it happen with a particular brand of USB to serial converters (Edgeport, made by Digi).  In these conditions the python script will hang at the win32file.SetCommState() command, usually timing out after 5-30 seconds, and quitting with no error message.

After having done some probing I think I basically understand the problem, and have a workaround, but I lack the know-how to fix it where it should be fixed, in win32file.  When Procomm opens the port, it sets XoffLim to 16128 and the XonLim to 15872.  When my script (actually, serialwin32.py from pyserial) tries to open the port it first reads the DCB with GetCommState(), changes baud rate, etc in the local PyDCB object, and then tries to reconfigure the port with SetCommState().  

>From what I can tell, SetCommState won't accept a value for XoffLim or XonLim >4096.  For example, if I try to execute the following:
DCB.XoffLim = 16128
SetCommState(porthandle,DCB)

I get an exception: (87, 'SetCommState', 'The parameter is incorrect.')

However, if GetCommState gets a DCB which has XoffLim = 16128, and then that DCB is passed to SetCommState, the script hangs for several seconds before exiting without opening the port and with no error message.  For example, after having opened and closed the port in Procomm:

>>> DCB = GetCommState(porthandle)
>>> DCB.XoffLim
16128L
>>> SetCommState(porthandle,DCB)
(...... hangs here for several seconds ......)

If I set XoffLim and XonLim to values from 0-4096 before calling SetCommState, then it works fine.  For example, after having opened and closed the port in Procomm:

>>> DCB = GetCommState(porthandle)
>>> DCB.XoffLim = 128
>>> DCB.XonLim = 512
>>> SetCommState(porthandle,DCB)
>>>
This works fine, and I can go on to open the port normally.  I have incorporated this fix into serialwin32.py which is working for me now, but it's not an elegant solution.  I am still baffled by why
SetCommState limits Xon/XoffLim to 4096, and by what GetCommState does to the PyDCB to make it cause SetCommState to fail so dramatically.  I also don't understand why I only see this problem with the Edgeport USB converters, and not with several other USB converters or hardware serial ports.  Maybe someone with a more intimate understanding of Python and Win32 can come up with some answers.

Thank you
-Alan Gardner
Woods Hole Oceanographic Institution
Woods Hole, MA 02543

----------------------------------------------------------------------

>Comment By: Roger Upole (rupole)
Date: 2008-10-01 16:23

Message:
The code to call SetCommState does not do any retries.
If you're seeing multiple attempts to set the configuration
parameters, they're probably coming from the driver itself.

Since this problem only happens for a particular device, and
only after a completely separate program has accessed it,
it's most likely due to the device driver, and/or the
state in which the other program leaves the port.  I really
don't think there's anything that can be done in win32file
to solve it.

 

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2008-09-29 23:52

Message:
If you think pywin32 is doing something incorrect with its DCB handling,
the only real way to demonstrate that is a snippet of C code that behaves
differently.  Given our arg handling looks OK, we will otherwise need to
assume the behaviour is just a characteristic of the windows API itself.

----------------------------------------------------------------------

Comment By: Alan Gardner (jiaailun)
Date: 2008-09-29 23:41

Message:
OK, since I realize this may be a difficult problem to recreate I have
annotated some screen captures from the interpreter.  In the process I
realized that the XonLim and XoffLim are obviously going to be limited by
the buffer size, and yes, pyserial does set the buffer to 4096.  OK, so now
I have another workaround, increasing the buffer size so that the XonLim
and XoffLim values are no longer to large.  But I still think that there is
an underlying bug.  When a port is opened with CreateFile it appears to
assign a default buffer size, and this can lead to XonLim and XoffLim
values which are out of range.  If SetCommState then tries to set an out of
range value to one of these parameters, it hangs.  I have some captures
from DebugView and PortMon which show Python.exe repeatedly getting and
setting parameters on the serial port in a nearly endless loop.  I can
upload these if it would be helpful, but they are moderately large and
arcane.  For now I will upload the annotated screen captures showing what I
see at this end.
File Added: win32file.SetCommState_interactive.txt

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2008-09-27 15:13

Message:
I don't see any problem with the way the DCB is passed to/from
SetCommState and GetCommState.  The XonLim and XoffLim members
consistently have the correct value.

If I recall from looking at pyserial a while back, it sets the
buffer sizes to 4096.  Have you tried increasing them in the
call to SetupComm ?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2132639&group_id=78018