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

[pywin32-bugs] [ pywin32-Bugs-2846720 ] win32ui crash in embedded app (212 -> 213 & 214 regression)

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

Bugs item #2846720, was opened at 2009-08-29 05:56
Message generated for change (Tracker Item Submitted) made by farshizzo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2846720&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: Farshid Lashkari (farshizzo)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32ui crash in embedded app (212 -> 213 & 214 regression)

Initial Comment:
I have an application that embeds python and uses the win32ui module. Everything worked fine until I upgraded from 212 to 214. After the upgrade my application crashes on exit. The Visual Studio debugger is showing that the crash is occurring after my application calls CoUninitialize. Here is a rough outline of what my app does:

CoInitialize(NULL)
InitPython()
RunPythonCode() //This code will import win32ui
ClosePython()
CoUninitialize()

Simply importing the win32ui module causes the crash. I don't even need to call any of the modules functions. If I don't import win32ui then my application exits cleanly. I tried downgrading to version 213 but the crash still occurs. Version 212 seems to be the last version that was stable with my application.


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

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

Re: [pywin32-bugs] problem on conversor

[Mark H. <mha...@sk...>]

This bugs list is for the automated delivery of mail generated by the 
sourceforge bug tracker.  It isn't used as a place to report bugs or get 
support - bugs should be reported directly in the sourceforge page, or 
if you are asking for support you might like to resend your question to 
the python-win32 mailing list.  You need to be subscribed to the list 
before you can post to it - see 
http://mail.python.org/mailman/listinfo/python-win32 for subscription 
options.

Regards,

Mark


On 29/08/2009 8:06 AM, Patricio Stegmann wrote:
> Hello to all,
>
> I am trying to use an activex component that has a property named Display:
>
> """
> _prop_map_get_ = {
> "AcquisitionMode": (1610743818, 2, (3, 0), (), "AcquisitionMode", None),
> "Display": (1610743816, 2, (3, 0), (), "Display", None),
> "TimeOut": (1610743820, 2, (3, 0), (), "TimeOut", None),
> }
> _prop_map_put_ = {
> "AcquisitionMode": ((1610743818, LCID, 4, 0),()),
> "Display": ((1610743816, LCID, 4, 0),()),
> "TimeOut": ((1610743820, LCID, 4, 0),()),
> }
> """
>
> This works:
>
> print l__acq.Display
>
>
> However this doesnt:
>
> l__acq.Display = 135780 # 135780 is the handle to a window on my screen
>
> and I get this:
>
> *** com_error: (-2147467262, 'Interfaz no compatible', None, None)
>
>
> It seems that pywin is correctly converting from 1610743816 to an int,
> but is not doing the other way (from int to win handle variant).
> Is there a way to create a Variable of that type 1610743816 somehow ?
>
> Thank you !
>
> ------------------------------------------------------------------------
> With Windows Live, you can organize, edit, and share your photos.
> <http://www.microsoft.com/middleeast/windows/windowslive/products/photo-gallery-edit.aspx>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> pywin32-bugs mailing list
> pyw...@li...
> https://lists.sourceforge.net/lists/listinfo/pywin32-bugs

[pywin32-bugs] problem on conversor

[Patricio S. <kp...@ho...>]

Hello to all,

I am trying to use an activex component that has a property named Display:

"""
    _prop_map_get_ = {
        "AcquisitionMode": (1610743818, 2, (3, 0), (), "AcquisitionMode", None),
        "Display": (1610743816, 2, (3, 0), (), "Display", None),
        "TimeOut": (1610743820, 2, (3, 0), (), "TimeOut", None),
    }
    _prop_map_put_ = {
        "AcquisitionMode": ((1610743818, LCID, 4, 0),()),
        "Display": ((1610743816, LCID, 4, 0),()),
        "TimeOut": ((1610743820, LCID, 4, 0),()),
    }
"""

This works:

print l__acq.Display


However this doesnt:

l__acq.Display = 135780 # 135780 is the handle to a window on my screen

and I get this:

*** com_error: (-2147467262, 'Interfaz no compatible', None, None)


It seems that pywin is correctly converting from 1610743816 to an int, but is not doing the other way (from int to win handle variant).
Is there a way to create a Variable of that type 1610743816 somehow ?

Thank you !

_________________________________________________________________
With Windows Live, you can organize, edit, and share your photos.
http://www.microsoft.com/middleeast/windows/windowslive/products/photo-gallery-edit.aspx

[pywin32-bugs] [ pywin32-Bugs-2843647 ] SimpleCOMServer from PPW32 p. 68 dies in PyWin 2.5, 2.6, 3.1

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

Bugs item #2843647, was opened at 2009-08-25 02:06
Message generated for change (Settings changed) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2843647&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: Invalid
Priority: 5
Private: No
Submitted By: docduke (docduke)
Assigned to: Nobody/Anonymous (nobody)
Summary: SimpleCOMServer from PPW32 p. 68 dies in PyWin 2.5, 2.6, 3.1

Initial Comment:
My objective is a server-side COM to call from VB 6.0 SP6, to do mathematics better.
 * The server demo in the book dies the same way no matter how I try it. Both from Word VBA and from VB6 SP6, the error is: 
Microsoft Visual Basic
Run-time error '-214746259 (80004005)':
 Unexpected Python Error: Traceback (most recent call last):
  File "C:\c\Python3\lib\site-packages\win32com\server\policy.py", line 278, in _Invoke_
    return self._invoke_(dispid, lcid, wFlags, args)
  File "C:\c\Python3\lib\site-packages\win32com\server\policy.py", line 283, in _invoke_
    return S_OK, -1, self._invokeex_(dispid, lcid, wFlags, args, None, None)

The traceback beyond here (and the underscores) are cut off by VB. I got the full last line from the source. I haven't figured out how to get the full traceback from PyWin.
* This is similar to 2391931, for which M. Hammond wrote: "You need to install a global copy of the MSVC2008 assemblies from Microsoft for this to work."
* Based on a Google search, I interpreted that to mean: "Microsoft Visual C++ 2008 SP1 Redistributable Package (x86)" which I installed. The error message is unchanged. I have also seen remarks about "COM updates," but that is not specific enough for me to have any idea what to look for. 

Please help!



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

>Comment By: Mark Hammond (mhammond)
Date: 2009-08-25 13:49

Message:
Thanks for the followup!

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

Comment By: docduke (docduke)
Date: 2009-08-25 12:19

Message:
First, thank you very much for your prompt response!

Now that PyWin knows the master is watching ...

I have run this code at least a dozan times, and it has failed every time!
 So with your comments, I went back, and it ran!  However, I rebooted the
computer to confirm that it was not a fluke, and it failed again.  The
explanation is embarassing ...  I will give the complete traceback in a
moment, but for other readers, the solution is more important.

The first successful run must have been in PyWin 25 or 26 (I don't
remember that I switched).  The failure was in PyWin 31.  The reason (see
the traceback!) is that I needed to change: "return string.split(str(val),
item)" to "return str(val).split(item)" for 3.1.  The thing I didn't
realize is that the compiler didn't catch the method error until the VB
call executed it, so the "return code 0" didn't mean the code was
functional.

Here is the full trace collection (Thanks for explaining how to get it in
Chapter 7!):
# This window will display output from any programs that import
win32traceutil
# win32com servers registered with '--debug' are in this category.
Object with win32trace dispatcher created (object=None)
in <SimpleCOMServer.PythonUtilities object at 0x03A9CA10>._QueryInterface_
with unsupported IID b'IPersistStreamInit'
({7FD52380-4E07-101B-AE2D-08002B2EC713})
in <SimpleCOMServer.PythonUtilities object at 0x03A9CA10>._QueryInterface_
with unsupported IID b'IPersistPropertyBag'
({37D84F60-42CB-11CE-8135-00AA004BB851})
in _GetIDsOfNames_ with '('SplitString',)' and '1033'

in _Invoke_ with 1000 1033 3 ('Hello to FSC',)
Traceback (most recent call last):
  File "C:\c\Python31\lib\site-packages\win32com\server\dispatcher.py",
line 47, in _Invoke_
    return self.policy._Invoke_(dispid, lcid, wFlags, args)
  File "C:\c\Python31\lib\site-packages\win32com\server\policy.py", line
278, in _Invoke_
    return self._invoke_(dispid, lcid, wFlags, args)
  File "C:\c\Python31\lib\site-packages\win32com\server\policy.py", line
283, in _invoke_
    return S_OK, -1, self._invokeex_(dispid, lcid, wFlags, args, None,
None)
  File "C:\c\Python31\lib\site-packages\win32com\server\policy.py", line
586, in _invokeex_
    return func(*args)
  File "C:\a\pywin\SimpleCOMServer.py", line 14, in SplitString
    return string.split(str(val), item)
AttributeError: 'module' object has no attribute 'split'

Thanks again!

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

Comment By: Mark Hammond (mhammond)
Date: 2009-08-25 08:05

Message:
Without the full traceback it is hard to be sure, but assuming the solution
is appropriate, you are *not* lookig for the "SP1" version of those libs -
just the 'plain' pre-SP1 ones.

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

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

[pywin32-bugs] [ pywin32-Bugs-2843647 ] SimpleCOMServer from PPW32 p. 68 dies in PyWin 2.5, 2.6, 3.1

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

Bugs item #2843647, was opened at 2009-08-24 10:06
Message generated for change (Comment added) made by docduke
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2843647&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: docduke (docduke)
Assigned to: Nobody/Anonymous (nobody)
Summary: SimpleCOMServer from PPW32 p. 68 dies in PyWin 2.5, 2.6, 3.1

Initial Comment:
My objective is a server-side COM to call from VB 6.0 SP6, to do mathematics better.
 * The server demo in the book dies the same way no matter how I try it. Both from Word VBA and from VB6 SP6, the error is: 
Microsoft Visual Basic
Run-time error '-214746259 (80004005)':
 Unexpected Python Error: Traceback (most recent call last):
  File "C:\c\Python3\lib\site-packages\win32com\server\policy.py", line 278, in _Invoke_
    return self._invoke_(dispid, lcid, wFlags, args)
  File "C:\c\Python3\lib\site-packages\win32com\server\policy.py", line 283, in _invoke_
    return S_OK, -1, self._invokeex_(dispid, lcid, wFlags, args, None, None)

The traceback beyond here (and the underscores) are cut off by VB. I got the full last line from the source. I haven't figured out how to get the full traceback from PyWin.
* This is similar to 2391931, for which M. Hammond wrote: "You need to install a global copy of the MSVC2008 assemblies from Microsoft for this to work."
* Based on a Google search, I interpreted that to mean: "Microsoft Visual C++ 2008 SP1 Redistributable Package (x86)" which I installed. The error message is unchanged. I have also seen remarks about "COM updates," but that is not specific enough for me to have any idea what to look for. 

Please help!



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

Comment By: docduke (docduke)
Date: 2009-08-24 20:19

Message:
First, thank you very much for your prompt response!

Now that PyWin knows the master is watching ...

I have run this code at least a dozan times, and it has failed every time!
 So with your comments, I went back, and it ran!  However, I rebooted the
computer to confirm that it was not a fluke, and it failed again.  The
explanation is embarassing ...  I will give the complete traceback in a
moment, but for other readers, the solution is more important.

The first successful run must have been in PyWin 25 or 26 (I don't
remember that I switched).  The failure was in PyWin 31.  The reason (see
the traceback!) is that I needed to change: "return string.split(str(val),
item)" to "return str(val).split(item)" for 3.1.  The thing I didn't
realize is that the compiler didn't catch the method error until the VB
call executed it, so the "return code 0" didn't mean the code was
functional.

Here is the full trace collection (Thanks for explaining how to get it in
Chapter 7!):
# This window will display output from any programs that import
win32traceutil
# win32com servers registered with '--debug' are in this category.
Object with win32trace dispatcher created (object=None)
in <SimpleCOMServer.PythonUtilities object at 0x03A9CA10>._QueryInterface_
with unsupported IID b'IPersistStreamInit'
({7FD52380-4E07-101B-AE2D-08002B2EC713})
in <SimpleCOMServer.PythonUtilities object at 0x03A9CA10>._QueryInterface_
with unsupported IID b'IPersistPropertyBag'
({37D84F60-42CB-11CE-8135-00AA004BB851})
in _GetIDsOfNames_ with '('SplitString',)' and '1033'

in _Invoke_ with 1000 1033 3 ('Hello to FSC',)
Traceback (most recent call last):
  File "C:\c\Python31\lib\site-packages\win32com\server\dispatcher.py",
line 47, in _Invoke_
    return self.policy._Invoke_(dispid, lcid, wFlags, args)
  File "C:\c\Python31\lib\site-packages\win32com\server\policy.py", line
278, in _Invoke_
    return self._invoke_(dispid, lcid, wFlags, args)
  File "C:\c\Python31\lib\site-packages\win32com\server\policy.py", line
283, in _invoke_
    return S_OK, -1, self._invokeex_(dispid, lcid, wFlags, args, None,
None)
  File "C:\c\Python31\lib\site-packages\win32com\server\policy.py", line
586, in _invokeex_
    return func(*args)
  File "C:\a\pywin\SimpleCOMServer.py", line 14, in SplitString
    return string.split(str(val), item)
AttributeError: 'module' object has no attribute 'split'

Thanks again!

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

Comment By: Mark Hammond (mhammond)
Date: 2009-08-24 16:05

Message:
Without the full traceback it is hard to be sure, but assuming the solution
is appropriate, you are *not* lookig for the "SP1" version of those libs -
just the 'plain' pre-SP1 ones.

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

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

[pywin32-bugs] [ pywin32-Bugs-2843647 ] SimpleCOMServer from PPW32 p. 68 dies in PyWin 2.5, 2.6, 3.1

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

Bugs item #2843647, was opened at 2009-08-25 02:06
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2843647&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: docduke (docduke)
Assigned to: Nobody/Anonymous (nobody)
Summary: SimpleCOMServer from PPW32 p. 68 dies in PyWin 2.5, 2.6, 3.1

Initial Comment:
My objective is a server-side COM to call from VB 6.0 SP6, to do mathematics better.
 * The server demo in the book dies the same way no matter how I try it. Both from Word VBA and from VB6 SP6, the error is: 
Microsoft Visual Basic
Run-time error '-214746259 (80004005)':
 Unexpected Python Error: Traceback (most recent call last):
  File "C:\c\Python3\lib\site-packages\win32com\server\policy.py", line 278, in _Invoke_
    return self._invoke_(dispid, lcid, wFlags, args)
  File "C:\c\Python3\lib\site-packages\win32com\server\policy.py", line 283, in _invoke_
    return S_OK, -1, self._invokeex_(dispid, lcid, wFlags, args, None, None)

The traceback beyond here (and the underscores) are cut off by VB. I got the full last line from the source. I haven't figured out how to get the full traceback from PyWin.
* This is similar to 2391931, for which M. Hammond wrote: "You need to install a global copy of the MSVC2008 assemblies from Microsoft for this to work."
* Based on a Google search, I interpreted that to mean: "Microsoft Visual C++ 2008 SP1 Redistributable Package (x86)" which I installed. The error message is unchanged. I have also seen remarks about "COM updates," but that is not specific enough for me to have any idea what to look for. 

Please help!



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

>Comment By: Mark Hammond (mhammond)
Date: 2009-08-25 08:05

Message:
Without the full traceback it is hard to be sure, but assuming the solution
is appropriate, you are *not* lookig for the "SP1" version of those libs -
just the 'plain' pre-SP1 ones.

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

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

[pywin32-bugs] [ pywin32-Bugs-2843647 ] SimpleCOMServer from PPW32 p. 68 dies in PyWin 2.5, 2.6, 3.1

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

Bugs item #2843647, was opened at 2009-08-24 10:06
Message generated for change (Tracker Item Submitted) made by docduke
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2843647&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: docduke (docduke)
Assigned to: Nobody/Anonymous (nobody)
Summary: SimpleCOMServer from PPW32 p. 68 dies in PyWin 2.5, 2.6, 3.1

Initial Comment:
My objective is a server-side COM to call from VB 6.0 SP6, to do mathematics better.
 * The server demo in the book dies the same way no matter how I try it. Both from Word VBA and from VB6 SP6, the error is: 
Microsoft Visual Basic
Run-time error '-214746259 (80004005)':
 Unexpected Python Error: Traceback (most recent call last):
  File "C:\c\Python3\lib\site-packages\win32com\server\policy.py", line 278, in _Invoke_
    return self._invoke_(dispid, lcid, wFlags, args)
  File "C:\c\Python3\lib\site-packages\win32com\server\policy.py", line 283, in _invoke_
    return S_OK, -1, self._invokeex_(dispid, lcid, wFlags, args, None, None)

The traceback beyond here (and the underscores) are cut off by VB. I got the full last line from the source. I haven't figured out how to get the full traceback from PyWin.
* This is similar to 2391931, for which M. Hammond wrote: "You need to install a global copy of the MSVC2008 assemblies from Microsoft for this to work."
* Based on a Google search, I interpreted that to mean: "Microsoft Visual C++ 2008 SP1 Redistributable Package (x86)" which I installed. The error message is unchanged. I have also seen remarks about "COM updates," but that is not specific enough for me to have any idea what to look for. 

Please help!



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

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

[pywin32-bugs] [ pywin32-Bugs-2841107 ] v214 breaks modules autogenerated with v212's EnsureDispatch

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

Bugs item #2841107, was opened at 2009-08-20 13:54
Message generated for change (Tracker Item Submitted) made by bsdz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2841107&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: blair sutton (bsdz)
Assigned to: Nobody/Anonymous (nobody)
Summary: v214 breaks modules autogenerated with v212's EnsureDispatch

Initial Comment:
The additional unicode support added in revision 3.18 breaks modules generated with previous versions of pywin32. This happens in Python 2.6.

When running a previously generated module the following assert breaks previously generated modules that set UnicodeToString=0: -

assert UnicodeToString is None, "this is deprecated and will go away"

The revision that makes this change can be found here: -

http://pywin32.cvs.sourceforge.net/viewvc/pywin32/pywin32/com/win32com/client/__init__.py?r1=1.37&r2=1.38&pathrev=HEAD

A workaround is to remove autogenerated files under 

C:\Python26\Lib\site-packages\win32com\gen_py\



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

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

[pywin32-bugs] [ pywin32-Bugs-2831327 ] GetProcessTimes converts wrongly to PyTime

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

Bugs item #2831327, was opened at 2009-08-03 17:22
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2831327&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: lplatypus (ldeller)
Assigned to: Nobody/Anonymous (nobody)
Summary: GetProcessTimes converts wrongly to PyTime

Initial Comment:
win32process.GetProcessTimes returns PyTime objects which are off by time.timezone seconds.  It appears that Windows returns a UTC time, but this is interpreted as if it were a local time.

See attached example which demonstrates the bug.

A similar problem probably exists with the win32process.GetThreadTimes function.

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

>Comment By: Mark Hammond (mhammond)
Date: 2009-08-06 11:05

Message:
Good catch - I should therefore nuke that function supporting a SYSTEMTIME
seeing we have managed without *really* needing one so far...

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

Comment By: lplatypus (ldeller)
Date: 2009-08-06 10:40

Message:
That sounds good to me.  I see that the code for the py3k builds assumes
that SYSTEMTIME always contains UTC, which contradicts the MSDN
documentation for SYSTEMTIME [
http://msdn.microsoft.com/en-us/library/ms724950%28VS.85%29.aspx ].  Maybe
this is not so bad: the only example I can find where SYSTEMTIME contains a
local time is the return value of GetLocalTime(), and pywin's wrapper for
this function return a tuple thus sidestepping the problem.

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

Comment By: Mark Hammond (mhammond)
Date: 2009-08-04 13:06

Message:
Note the py3k builds use a datetime objects; I think a better solution is
to allow these objects to also be used in py2k and let the PyTime object
die a graceful death...

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

Comment By: lplatypus (ldeller)
Date: 2009-08-04 11:15

Message:
Following through the C++ code, I see that the type conversion sequence
is:
FILETIME -> SYSTEMTIME -> DATE -> struct tm -> time_t

Now with MSDN documentation handy I see that:
- FILETIME is always UTC
- SYSTEMTIME can be either UTC or the system's local time depending on the
function being called
- DATE documentation does not mention timezones at all
- struct tm can contain UTC or the system's local time
- time_t is always UTC

In the present example, we have a UTC time all the way through to struct
tm, but then it is converted to time_t using the mktime() function which
expects the struct tm to be in local time.  This occurs in PyTime::asLong()
in PyTime.cpp

How to fix this?  I think that the PyTime object needs to be extended to
know whether it contains UTC or local time. When constructed from a
FILETIME value it needs to be marked as containing UTC.

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

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

[pywin32-bugs] [ pywin32-Bugs-2831327 ] GetProcessTimes converts wrongly to PyTime

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

Bugs item #2831327, was opened at 2009-08-03 17:22
Message generated for change (Comment added) made by ldeller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2831327&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: lplatypus (ldeller)
Assigned to: Nobody/Anonymous (nobody)
Summary: GetProcessTimes converts wrongly to PyTime

Initial Comment:
win32process.GetProcessTimes returns PyTime objects which are off by time.timezone seconds.  It appears that Windows returns a UTC time, but this is interpreted as if it were a local time.

See attached example which demonstrates the bug.

A similar problem probably exists with the win32process.GetThreadTimes function.

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

>Comment By: lplatypus (ldeller)
Date: 2009-08-06 10:40

Message:
That sounds good to me.  I see that the code for the py3k builds assumes
that SYSTEMTIME always contains UTC, which contradicts the MSDN
documentation for SYSTEMTIME [
http://msdn.microsoft.com/en-us/library/ms724950%28VS.85%29.aspx ].  Maybe
this is not so bad: the only example I can find where SYSTEMTIME contains a
local time is the return value of GetLocalTime(), and pywin's wrapper for
this function return a tuple thus sidestepping the problem.

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

Comment By: Mark Hammond (mhammond)
Date: 2009-08-04 13:06

Message:
Note the py3k builds use a datetime objects; I think a better solution is
to allow these objects to also be used in py2k and let the PyTime object
die a graceful death...

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

Comment By: lplatypus (ldeller)
Date: 2009-08-04 11:15

Message:
Following through the C++ code, I see that the type conversion sequence
is:
FILETIME -> SYSTEMTIME -> DATE -> struct tm -> time_t

Now with MSDN documentation handy I see that:
- FILETIME is always UTC
- SYSTEMTIME can be either UTC or the system's local time depending on the
function being called
- DATE documentation does not mention timezones at all
- struct tm can contain UTC or the system's local time
- time_t is always UTC

In the present example, we have a UTC time all the way through to struct
tm, but then it is converted to time_t using the mktime() function which
expects the struct tm to be in local time.  This occurs in PyTime::asLong()
in PyTime.cpp

How to fix this?  I think that the PyTime object needs to be extended to
know whether it contains UTC or local time. When constructed from a
FILETIME value it needs to be marked as containing UTC.

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

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

[pywin32-bugs] [ pywin32-Bugs-2830702 ] dynamic.py, __str__ and unicode

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

Bugs item #2830702, was opened at 2009-07-31 23:23
Message generated for change (Comment added) made by closedbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2830702&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: Michael Bush (closedbox)
Assigned to: Nobody/Anonymous (nobody)
Summary: dynamic.py, __str__ and unicode

Initial Comment:
I had a problem where a 3rd party com object was unexpectedly outputting unicode data which would making my program's str() blow up on that property. The only solution I could find was to modify the dynamic.py program.

dynamic.py: Line 198; Insert
except UnicodeEncodeError:
     return self.__call__().encode('utf-7')

Is their a better solution? If not please add this or something like it. Thanks!

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

>Comment By: Michael Bush (closedbox)
Date: 2009-08-04 21:54

Message:
woops that line 189 not 198

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

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

[pywin32-bugs] [ pywin32-Bugs-2831327 ] GetProcessTimes converts wrongly to PyTime

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

Bugs item #2831327, was opened at 2009-08-03 17:22
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2831327&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: lplatypus (ldeller)
Assigned to: Nobody/Anonymous (nobody)
Summary: GetProcessTimes converts wrongly to PyTime

Initial Comment:
win32process.GetProcessTimes returns PyTime objects which are off by time.timezone seconds.  It appears that Windows returns a UTC time, but this is interpreted as if it were a local time.

See attached example which demonstrates the bug.

A similar problem probably exists with the win32process.GetThreadTimes function.

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

>Comment By: Mark Hammond (mhammond)
Date: 2009-08-04 13:06

Message:
Note the py3k builds use a datetime objects; I think a better solution is
to allow these objects to also be used in py2k and let the PyTime object
die a graceful death...

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

Comment By: lplatypus (ldeller)
Date: 2009-08-04 11:15

Message:
Following through the C++ code, I see that the type conversion sequence
is:
FILETIME -> SYSTEMTIME -> DATE -> struct tm -> time_t

Now with MSDN documentation handy I see that:
- FILETIME is always UTC
- SYSTEMTIME can be either UTC or the system's local time depending on the
function being called
- DATE documentation does not mention timezones at all
- struct tm can contain UTC or the system's local time
- time_t is always UTC

In the present example, we have a UTC time all the way through to struct
tm, but then it is converted to time_t using the mktime() function which
expects the struct tm to be in local time.  This occurs in PyTime::asLong()
in PyTime.cpp

How to fix this?  I think that the PyTime object needs to be extended to
know whether it contains UTC or local time. When constructed from a
FILETIME value it needs to be marked as containing UTC.

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

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

[pywin32-bugs] [ pywin32-Bugs-2831327 ] GetProcessTimes converts wrongly to PyTime

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

Bugs item #2831327, was opened at 2009-08-03 17:22
Message generated for change (Comment added) made by ldeller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2831327&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: lplatypus (ldeller)
Assigned to: Nobody/Anonymous (nobody)
Summary: GetProcessTimes converts wrongly to PyTime

Initial Comment:
win32process.GetProcessTimes returns PyTime objects which are off by time.timezone seconds.  It appears that Windows returns a UTC time, but this is interpreted as if it were a local time.

See attached example which demonstrates the bug.

A similar problem probably exists with the win32process.GetThreadTimes function.

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

>Comment By: lplatypus (ldeller)
Date: 2009-08-04 11:15

Message:
Following through the C++ code, I see that the type conversion sequence
is:
FILETIME -> SYSTEMTIME -> DATE -> struct tm -> time_t

Now with MSDN documentation handy I see that:
- FILETIME is always UTC
- SYSTEMTIME can be either UTC or the system's local time depending on the
function being called
- DATE documentation does not mention timezones at all
- struct tm can contain UTC or the system's local time
- time_t is always UTC

In the present example, we have a UTC time all the way through to struct
tm, but then it is converted to time_t using the mktime() function which
expects the struct tm to be in local time.  This occurs in PyTime::asLong()
in PyTime.cpp

How to fix this?  I think that the PyTime object needs to be extended to
know whether it contains UTC or local time. When constructed from a
FILETIME value it needs to be marked as containing UTC.

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

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

[pywin32-bugs] [ pywin32-Bugs-2831327 ] GetProcessTimes converts wrongly to PyTime

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

Bugs item #2831327, was opened at 2009-08-03 17:22
Message generated for change (Tracker Item Submitted) made by ldeller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2831327&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: lplatypus (ldeller)
Assigned to: Nobody/Anonymous (nobody)
Summary: GetProcessTimes converts wrongly to PyTime

Initial Comment:
win32process.GetProcessTimes returns PyTime objects which are off by time.timezone seconds.  It appears that Windows returns a UTC time, but this is interpreted as if it were a local time.

See attached example which demonstrates the bug.

A similar problem probably exists with the win32process.GetThreadTimes function.

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

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

[pywin32-bugs] [ pywin32-Bugs-2830702 ] dynamic.py, __str__ and unicode

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

Bugs item #2830702, was opened at 2009-07-31 23:23
Message generated for change (Tracker Item Submitted) made by closedbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2830702&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: Michael Bush (closedbox)
Assigned to: Nobody/Anonymous (nobody)
Summary: dynamic.py, __str__ and unicode

Initial Comment:
I had a problem where a 3rd party com object was unexpectedly outputting unicode data which would making my program's str() blow up on that property. The only solution I could find was to modify the dynamic.py program.

dynamic.py: Line 198; Insert
except UnicodeEncodeError:
     return self.__call__().encode('utf-7')

Is their a better solution? If not please add this or something like it. Thanks!

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

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

[pywin32-bugs] [ pywin32-Feature Requests-2830589 ] RFE: Vista/2008 service - "Automatically (Delayed Start)"

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

Feature Requests item #2830589, was opened at 2009-07-31 22:36
Message generated for change (Tracker Item Submitted) made by jpoliv
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=2830589&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: jpoliv (jpoliv)
Assigned to: Nobody/Anonymous (nobody)
Summary: RFE: Vista/2008 service - "Automatically (Delayed Start)"

Initial Comment:
Context:
Services in Windows Vista and Windows 2008  have a fourth startup type value - "Automatic (Delayed Start)" - that isn't available through the --startup command line option of a python windows service script.

Description of the problem:
Currently the --startup command line option only supports the "Manual", "Automatic", and "Disabled" values.

Expected results:
Having the fourth option "Automatically (Delayed Start)" available through the --startup command line option

/jpo


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

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

[pywin32-bugs] [ pywin32-Bugs-2821361 ] Installation error on 214.win32-py2.5.exe w/ VC8 w/ SDK 6.0a

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

Bugs item #2821361, was opened at 2009-07-14 14:17
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2821361&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: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Terry Zhang (terryz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installation error on 214.win32-py2.5.exe w/ VC8 w/ SDK 6.0a

Initial Comment:
com dll error during installation. Please help.


Copied pythoncom25.dll to C:\WINDOWS\system32\pythoncom25.dll
Copied pywintypes25.dll to C:\WINDOWS\system32\pywintypes25.dll
Registered: Python.Interpreter 
Registered: Python.Dictionary 
FAILED to register the Python COM objects
-> Software\Python\PythonCore\2.5\Help[None]=None
-> Software\Python\PythonCore\2.5\Help\Pythonwin Reference[None]='C:\\Python25\\Lib\\site-packages\\PyWin32.chm'
Failed to register pythonwin as editor
Can't install shortcuts - 'C:\\Documents and Settings\\All Users\\Start Menu\\Programs\\Python 2.5' is not a folder
The pywin32 extensions were successfully installed.
Traceback (most recent call last):
  File "<string>", line 369, in install
  File "<string>", line 176, in RegisterCOMObjects
  File "c:\python25\lib\site-packages\pywin32-210n1-py2.5-win32.egg\win32comext\axscript\client\pyscript.py", line 10, in <module>

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

>Comment By: SourceForge Robot (sf-robot)
Date: 2009-07-29 02:20

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: Mark Hammond (mhammond)
Date: 2009-07-14 21:42

Message:
You snipped the last line of the traceback which includes the error
message.

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

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

Re: [pywin32-bugs] Byte range locking with Lockfileex has side effects

[Pascal C. <pyt...@gm...>]

Hello

Actually I've investigated a bit more, and it seems the problem doesn't come
from pywin32, but from the normal python file objects, which are not able to
cope properly with win32 fucntions (even with get_osf_handle() etc.). It
seems I'll have to use my own file objects in python if I want to lock them
on byte ranges.

regards,
Pascal Chambon

2009/7/16 Pascal Chambon <pyt...@gm...>

>
>
> Hello
>
> I don't know yet if it's a pywin32-specific bug, but locking file ranges
> with lockfileex currently prevents other processes from reading previous
> parts of the files : read operation on python file objects return IOErrors,
> and read operations on handles obtained via CreateFile() return empty
> strings.
>
> Normally, as long as we dont read or write (depending on teh type of lock)
> the locked range, we shouldn't have any troubel, should we ? Has anyone
> around already used concurrent file accesses with lokfile ex ?
>
> Here are two python scripts showing the problem - just launch the first
> one, then in parralel teh second one.
>
> regards,
> Pascal Chambon
>
>
>
>

[pywin32-bugs] Byte range locking with Lockfileex has side effects

[Pascal C. <pyt...@gm...>]

Hello

I don't know yet if it's a pywin32-specific bug, but locking file ranges
with lockfileex currently prevents other processes from reading previous
parts of the files : read operation on python file objects return IOErrors,
and read operations on handles obtained via CreateFile() return empty
strings.

Normally, as long as we dont read or write (depending on teh type of lock)
the locked range, we shouldn't have any troubel, should we ? Has anyone
around already used concurrent file accesses with lokfile ex ?

Here are two python scripts showing the problem - just launch the first one,
then in parralel teh second one.

regards,
Pascal Chambon

[pywin32-bugs] [ pywin32-Bugs-2821361 ] Installation error on 214.win32-py2.5.exe w/ VC8 w/ SDK 6.0a

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

Bugs item #2821361, was opened at 2009-07-15 00:17
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2821361&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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Terry Zhang (terryz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installation error on 214.win32-py2.5.exe w/ VC8 w/ SDK 6.0a

Initial Comment:
com dll error during installation. Please help.


Copied pythoncom25.dll to C:\WINDOWS\system32\pythoncom25.dll
Copied pywintypes25.dll to C:\WINDOWS\system32\pywintypes25.dll
Registered: Python.Interpreter 
Registered: Python.Dictionary 
FAILED to register the Python COM objects
-> Software\Python\PythonCore\2.5\Help[None]=None
-> Software\Python\PythonCore\2.5\Help\Pythonwin Reference[None]='C:\\Python25\\Lib\\site-packages\\PyWin32.chm'
Failed to register pythonwin as editor
Can't install shortcuts - 'C:\\Documents and Settings\\All Users\\Start Menu\\Programs\\Python 2.5' is not a folder
The pywin32 extensions were successfully installed.
Traceback (most recent call last):
  File "<string>", line 369, in install
  File "<string>", line 176, in RegisterCOMObjects
  File "c:\python25\lib\site-packages\pywin32-210n1-py2.5-win32.egg\win32comext\axscript\client\pyscript.py", line 10, in <module>

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

>Comment By: Mark Hammond (mhammond)
Date: 2009-07-15 07:42

Message:
You snipped the last line of the traceback which includes the error
message.

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

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

[pywin32-bugs] [ pywin32-Bugs-2821361 ] Installation error on 214.win32-py2.5.exe w/ VC8 w/ SDK 6.0a

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

Bugs item #2821361, was opened at 2009-07-14 07:17
Message generated for change (Tracker Item Submitted) made by terryz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2821361&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: Terry Zhang (terryz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installation error on 214.win32-py2.5.exe w/ VC8 w/ SDK 6.0a

Initial Comment:
com dll error during installation. Please help.


Copied pythoncom25.dll to C:\WINDOWS\system32\pythoncom25.dll
Copied pywintypes25.dll to C:\WINDOWS\system32\pywintypes25.dll
Registered: Python.Interpreter 
Registered: Python.Dictionary 
FAILED to register the Python COM objects
-> Software\Python\PythonCore\2.5\Help[None]=None
-> Software\Python\PythonCore\2.5\Help\Pythonwin Reference[None]='C:\\Python25\\Lib\\site-packages\\PyWin32.chm'
Failed to register pythonwin as editor
Can't install shortcuts - 'C:\\Documents and Settings\\All Users\\Start Menu\\Programs\\Python 2.5' is not a folder
The pywin32 extensions were successfully installed.
Traceback (most recent call last):
  File "<string>", line 369, in install
  File "<string>", line 176, in RegisterCOMObjects
  File "c:\python25\lib\site-packages\pywin32-210n1-py2.5-win32.egg\win32comext\axscript\client\pyscript.py", line 10, in <module>

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

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

[pywin32-bugs] [ pywin32-Bugs-2820666 ] Install problem XP

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

Bugs item #2820666, was opened at 2009-07-13 11:23
Message generated for change (Tracker Item Submitted) made by trancos7
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2820666&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: Ignacio Perez (trancos7)
Assigned to: Nobody/Anonymous (nobody)
Summary: Install problem XP

Initial Comment:
When I try to install 
pywin32-214.win32-py3.1.exe
on a system with Windows XP SP3 the installation finish with this message:

Copied pythoncom31.dll to C:\WINDOWS\system32\pythoncom31.dll
Copied pywintypes31.dll to C:\WINDOWS\system32\pywintypes31.dll
Registered: Python.Interpreter 
Registered: Python.Dictionary 
Registered: Python 
-> Software\Python\PythonCore\3.1\Help[None]=None
-> Software\Python\PythonCore\3.1\Help\Pythonwin Reference[None]='C:\\Python31\\Lib\\site-packages\\PyWin32.chm'
Failed to register pythonwin as editor
'utf8' codec can't decode bytes in position 39-43: unsupported Unicode code range
The pywin32 extensions were successfully installed.
Traceback (most recent call last):
  File "<string>", line 398, in install
  File "<string>", line 208, in RegisterPythonwin
WindowsError: [Error 5] Acceso denegado

The user has admin rights.
Thanks in advance.

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

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

[pywin32-bugs] [ pywin32-Bugs-2819345 ] integer property return None

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

Bugs item #2819345, was opened at 2009-07-10 09:14
Message generated for change (Comment added) made by santiwk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2819345&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: Santi Wangkerkoon (santiwk)
Assigned to: Nobody/Anonymous (nobody)
Summary: integer property return None

Initial Comment:
With Pywin32 Build 210..213,
   self.TransSeqNo always return None

I also try
   self._oleobj_.invoke(1, 0, 3, True) #disp_id, LCID, (PROP+METHOD), ResultNeeded
the result is the same.

While VB & Delphi return integer data correctly.

What went wrong ?

# Reference
# VB:  Property TransSeqNo As Long 
# TLB:  HRESULT TransSeqNo([out, retval] long *pVal) 

class IFpTransaction(DispatchBaseClass):
	"""IFpTransaction Interface"""
	CLSID = IID('{FD4E0B96-CF0B-11D3-BCEC-005004125A39}')
	coclass_clsid = IID('{FD4E0B97-CF0B-11D3-BCEC-005004125A39}')
	_prop_map_get_ = {
		"AuthId": (16, 2, (17, 0), (), "AuthId", None),
		"CurrencyCode": (29, 2, (8, 0), (), "CurrencyCode", None),
		# Method 'FinishTime' returns object of type 'ITimeStamp'
		"FinishTime": (23, 2, (9, 0), (), "FinishTime", '{2A09B624-7836-4620-A35F-2417B2653DF6}'),
		"FormattedMoney": (10, 2, (8, 0), (), "FormattedMoney", None),
		"FpId": (9, 2, (17, 0), (), "FpId", None),
		"FuellingModeId": (17, 2, (17, 0), (), "FuellingModeId", None),
		"GradeDescriptor": (21, 2, (17, 0), (), "GradeDescriptor", None),
		"GradeId": (8, 2, (17, 0), (), "GradeId", None),
		"GradeOptionNo": (20, 2, (17, 0), (), "GradeOptionNo", None),
		"Money": (12, 2, (4, 0), (), "Money", None),
		"MoneyDue": (7, 2, (4, 0), (), "MoneyDue", None),
		"MoneyDueValid": (5, 2, (11, 0), (), "MoneyDueValid", None),
		"Price": (11, 2, (4, 0), (), "Price", None),
		"PriceGroupId": (18, 2, (17, 0), (), "PriceGroupId", None),
		"PriceSetId": (19, 2, (17, 0), (), "PriceSetId", None),
		"SecurityTelegram": (30, 2, (8209, 0), (), "SecurityTelegram", None),
		"SecurityTelegramTypePSS": (31, 2, (8209, 0), (), "SecurityTelegramTypePSS", None),
		"ServiceModeId": (2, 2, (17, 0), (), "ServiceModeId", None),
		"StartLimit": (27, 2, (4, 0), (), "StartLimit", None),
		"StartLimitType": (26, 2, (3, 0), (), "StartLimitType", None),
		# Method 'StartTime' returns object of type 'ITimeStamp'
		"StartTime": (22, 2, (9, 0), (), "StartTime", '{2A09B624-7836-4620-A35F-2417B2653DF6}'),
		"Supervised": (28, 2, (11, 0), (), "Supervised", None),
		"TransErrorCode": (25, 2, (3, 0), (), "TransErrorCode", None),
		"TransInfoMask": (3, 2, (17, 0), (), "TransInfoMask", None),
		"TransLockId": (4, 2, (17, 0), (), "TransLockId", None),
		"TransSeqNo": (1, 2, (3, 0), (), "TransSeqNo", None),
		"TransTerminationStatus": (24, 2, (17, 0), (), "TransTerminationStatus", None),
		"Volume": (6, 2, (4, 0), (), "Volume", None),
	}

IFpTransaction_vtables_dispatch_ = 1
IFpTransaction_vtables_ = [
	(( u'TransSeqNo' , u'pVal' , ), 1, (1, (), [ (16387, 10, None, None) , ], 1 , 2 , 4 , 0 , 28 , (3, 0, None, None) , 0 , )),
	(( u'ServiceModeId' , u'pVal' , ), 2, (2, (), [ (16401, 10, None, None) , ], 1 , 2 , 4 , 0 , 32 , (3, 0, None, None) , 0 , )),
	(( u'TransInfoMask' , u'pVal' , ), 3, (3, (), [ (16401, 10, None, None) , ], 1 , 2 , 4 , 0 , 36 , (3, 0, None, None) , 64 , )),
	(( u'TransLockId' , u'pVal' , ), 4, (4, (), [ (16401, 10, None, None) , ], 1 , 2 , 4 , 0 , 40 , (3, 0, None, None) , 0 , )),
	(( u'MoneyDueValid' , u'pVal' , ), 5, (5, (), [ (16395, 10, None, None) , ], 1 , 2 , 4 , 0 , 44 , (3, 0, None, None) , 0 , )),
	(( u'Volume' , u'pVal' , ), 6, (6, (), [ (16388, 10, None, None) , ], 1 , 2 , 4 , 0 , 48 , (3, 0, None, None) , 0 , )),
	(( u'MoneyDue' , u'pVal' , ), 7, (7, (), [ (16388, 10, None, None) , ], 1 , 2 , 4 , 0 , 52 , (3, 0, None, None) , 0 , )),
	(( u'GradeId' , u'pVal' , ), 8, (8, (), [ (16401, 10, None, None) , ], 1 , 2 , 4 , 0 , 56 , (3, 0, None, None) , 0 , )),
	(( u'FpId' , u'pVal' , ), 9, (9, (), [ (16401, 10, None, None) , ], 1 , 2 , 4 , 0 , 60 , (3, 0, None, None) , 0 , )),
	(( u'FormattedMoney' , u'pVal' , ), 10, (10, (), [ (16392, 10, None, None) , ], 1 , 2 , 4 , 0 , 64 , (3, 0, None, None) , 0 , )),
	(( u'Price' , u'pVal' , ), 11, (11, (), [ (16388, 10, None, None) , ], 1 , 2 , 4 , 0 , 68 , (3, 0, None, None) , 0 , )),
	(( u'Money' , u'pVal' , ), 12, (12, (), [ (16388, 10, None, None) , ], 1 , 2 , 4 , 0 , 72 , (3, 0, None, None) , 0 , )),
	(( u'lock' , u'PosId' , ), 13, (13, (), [ (17, 1, None, None) , ], 1 , 1 , 4 , 0 , 76 , (3, 0, None, None) , 0 , )),
	(( u'unlock' , u'PosId' , ), 14, (14, (), [ (17, 1, None, None) , ], 1 , 1 , 4 , 0 , 80 , (3, 0, None, None) , 0 , )),
	(( u'Clear' , u'PosId' , ), 15, (15, (), [ (17, 1, None, None) , ], 1 , 1 , 4 , 0 , 84 , (3, 0, None, None) , 0 , )),
	(( u'AuthId' , u'pVal' , ), 16, (16, (), [ (16401, 10, None, None) , ], 1 , 2 , 4 , 0 , 88 , (3, 0, None, None) , 0 , )),
	(( u'FuellingModeId' , u'pVal' , ), 17, (17, (), [ (16401, 10, None, None) , ], 1 , 2 , 4 , 0 , 92 , (3, 0, None, None) , 0 , )),
	(( u'PriceGroupId' , u'pVal' , ), 18, (18, (), [ (16401, 10, None, None) , ], 1 , 2 , 4 , 0 , 96 , (3, 0, None, None) , 0 , )),
	(( u'PriceSetId' , u'pVal' , ), 19, (19, (), [ (16401, 10, None, None) , ], 1 , 2 , 4 , 0 , 100 , (3, 0, None, None) , 0 , )),
	(( u'GradeOptionNo' , u'pVal' , ), 20, (20, (), [ (16401, 10, None, None) , ], 1 , 2 , 4 , 0 , 104 , (3, 0, None, None) , 0 , )),
	(( u'GradeDescriptor' , u'pVal' , ), 21, (21, (), [ (16401, 10, None, None) , ], 1 , 2 , 4 , 0 , 108 , (3, 0, None, None) , 64 , )),
	(( u'StartTime' , u'pVal' , ), 22, (22, (), [ (16393, 10, None, "IID('{2A09B624-7836-4620-A35F-2417B2653DF6}')") , ], 1 , 2 , 4 , 0 , 112 , (3, 0, None, None) , 0 , )),
	(( u'FinishTime' , u'pVal' , ), 23, (23, (), [ (16393, 10, None, "IID('{2A09B624-7836-4620-A35F-2417B2653DF6}')") , ], 1 , 2 , 4 , 0 , 116 , (3, 0, None, None) , 0 , )),
	(( u'TransTerminationStatus' , u'pVal' , ), 24, (24, (), [ (16401, 10, None, None) , ], 1 , 2 , 4 , 0 , 120 , (3, 0, None, None) , 0 , )),
	(( u'TransErrorCode' , u'pVal' , ), 25, (25, (), [ (16387, 10, None, None) , ], 1 , 2 , 4 , 0 , 124 , (3, 0, None, None) , 0 , )),
	(( u'StartLimitType' , u'pVal' , ), 26, (26, (), [ (16387, 10, None, None) , ], 1 , 2 , 4 , 0 , 128 , (3, 0, None, None) , 0 , )),
	(( u'StartLimit' , u'pVal' , ), 27, (27, (), [ (16388, 10, None, None) , ], 1 , 2 , 4 , 0 , 132 , (3, 0, None, None) , 0 , )),
	(( u'Supervised' , u'pVal' , ), 28, (28, (), [ (16395, 10, None, None) , ], 1 , 2 , 4 , 0 , 136 , (3, 0, None, None) , 0 , )),
	(( u'CurrencyCode' , u'pVal' , ), 29, (29, (), [ (16392, 10, None, None) , ], 1 , 2 , 4 , 0 , 140 , (3, 0, None, None) , 0 , )),
	(( u'SecurityTelegram' , u'pVal' , ), 30, (30, (), [ (24593, 10, None, None) , ], 1 , 2 , 4 , 0 , 144 , (3, 0, None, None) , 0 , )),
	(( u'SecurityTelegramTypePSS' , u'pVal' , ), 31, (31, (), [ (24593, 10, None, None) , ], 1 , 2 , 4 , 0 , 148 , (3, 0, None, None) , 0 , )),
	(( u'ClearAndAddReceiptItem' , u'PosId' , u'ClearSeqParms' , ), 32, (32, (), [ (17, 1, None, None) , 
			(9, 1, None, "IID('{3460EA4B-31E3-451B-92E2-94A05D8BC379}')") , ], 1 , 1 , 4 , 0 , 152 , (3, 0, None, None) , 0 , )),
	(( u'ClearWithParms' , u'PosId' , u'pClearTransParms' , ), 33, (33, (), [ (17, 1, None, None) , 
			(9, 1, None, "IID('{B1DF33BE-0A54-4D8A-8F5A-827B49209555}')") , ], 1 , 1 , 4 , 0 , 156 , (3, 0, None, None) , 0 , )),
]
	

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

>Comment By: Santi Wangkerkoon (santiwk)
Date: 2009-07-13 09:18

Message:
Usage Pattern
The code below shows minimum step to the problem.

# full interface is in attached file 'interface_py.zip'
FcServer = Dispatch('PSS.Forecourt')
FcConfig = Dispatch(FcServer, None,
IID('{9C255624-C1B0-11D3-BCDC-005004125A39}'))
FcServer.HostName = 'localhost'
FcServer.PosId = 9
FcServer.Initialize()
FcServer.FcLogon('POS,APPL_ID=APP01')

pumpID = 1
for xf in FcConfig.FuellingPoints.Item(pumpID).TransCollection:
  print(xf.GradeOptionNo)  # numeric eg. 1
  print(xf.TransSeqNo) # always None !

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

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

[pywin32-bugs] [ pywin32-Bugs-1784777 ] wrong timezone info returned by GetTimeZoneInformation()

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

Bugs item #1784777, was opened at 2007-08-30 08:12
Message generated for change (Settings changed) made by jaraco
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1784777&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: None
Priority: 5
Private: No
Submitted By: Bernhard (bernhard_bender)
Assigned to: Jason R. Coombs (jaraco)
Summary: wrong timezone info returned by GetTimeZoneInformation()

Initial Comment:
In my setting:

Windows XP (German), up-to-date patches applied (including the lated August 2007 timezone database patch)
Python 2.4
pywin 2.10
Timezone Europe/Berlin (+0100) with DST enabled

win32api.GetTimeZoneInformation() returns seemingly wrong information for the date DST ends.

This is shown by the little scripe I have attached, which prints:

>>>
Daylight time begins :  Last Sunday in March
Daylight time ends   :  Last Thursday in October
<<<

Since I am pretty sure that our DST does not end on a Thursday, I suspect an error in either the implementation of GetTimeZoneInformation() or in the WinXP TZ database.


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

>Comment By: Jason R. Coombs (jaraco)
Date: 2009-07-12 09:27

Message:
This was fixed for build 213 and 214.  Please comment or re-open if this
problem exhibits itself once again.

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

Comment By: Jason R. Coombs (jaraco)
Date: 2009-01-31 09:03

Message:
I think the solution is to use win32api.GetTimeZoneInformation(True),
available in the forthcoming pywin32-213, to get tuples instead of the
PyTime structures, which then contain the unaltered elements of a
SYSTEMTIME structure.

Alternately, the new release has direct support for parsing the result of
the API call: win32timezone.TimeZoneInfo.local()

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

Comment By: Mark Hammond (mhammond)
Date: 2009-01-31 00:59

Message:
Jason, I think this has been addressed in the most recent win32timezone
changes?  Bernhard, please keep your eye open for build 213 which has this
new version.

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

Comment By: Jason R. Coombs (jaraco)
Date: 2007-09-04 21:26

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

I'm attaching a patch that demonstrates (perhaps incorrectly) a way to
address this issue.  I've never done PythonC programming (that is,
extensions to python in C/C++).  I used to know C++ like the back of my
hand, and now it looks Greek to me.

What I think I've proposed will change the return value for
GetTimeZoneInformation, which will break prior implementations that depend
on it.  I think Bernhard has demonstrated, however, that any
implementations that depend on it are probably flawed anyway, so that's why
I'm suggesting changing the interface.

I think the patch returns a tuple of 8 ints (they're defined as WORDs in
the specs) instead of converting to the PyTime object (via
PyWinObject_FromSYSTEMTIME).

This could probably better be implemented with a different class (instead
of PyTime) to represent SYSTEMTIME when converting to variant time is
inadequate such as in this case.

Although this is assigned to me, I'd like to defer to Mark as to how he
would like to approach this issue.  Mark, if you would like me to fully
test and implement a full patch, I'll need some assistance on getting a
PyWin32 development environment set up.
File Added: win32apimodule.cpp.systemtime.patch

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

Comment By: Mark Hammond (mhammond)
Date: 2007-09-04 19:18

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

Hi jason,
  Thanks for your comments.  I've taken the liberty of adding you to the
pywin32 project and making you an admin in various places, so now you can
be assigned bugs (which I've done here) and should also be able to make any
changes to them.

Cheers

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

Comment By: Jason R. Coombs (jaraco)
Date: 2007-09-04 10:45

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

It seems I can't attach files to a bug I did not create.

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

Comment By: Jason R. Coombs (jaraco)
Date: 2007-09-04 10:43

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

Indeed, that's my finding as well.  It's probably not appropriate to
construct a PyTime from the SYSTEMTIME structure in GetTimeZoneInformation,
as it's using the day of the week value explicitly.

In the meantime, Bernhard, you may try using the win32timezone module.  I
wrote it, and it reads from the registry directly to provide richer
timezone support than the Microsoft system calls.

>>> import win32timezone
>>> my_tz = win32timezone.GetLocalTimeZone()
>>> my_tz.GetDSTStartTime(2007)
datetime.datetime(2007, 3, 11, 2, 0)

Note there are some changes to this module that aren't in the current
release of pywin32 (build 210).  I will attach the latest win32timezone.py
to this bug for convenience.

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

Comment By: Bernhard (bernhard_bender)
Date: 2007-09-04 10:32

Message:
Logged In: YES 
user_id=1637368
Originator: YES

I had been doing some digging in the source code. I may well be that the
problem stems from the fact that the date for changing time zones is stored
as a float (seconds since the epoch). As such it does not explicitly store
the day of week, but rather the day of week is recalculated in the Format()
method.

Thank you for looking into this.
Bernhard

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

Comment By: Jason R. Coombs (jaraco)
Date: 2007-09-04 10:25

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

I looked into the .NET platform, but it uses a completely different
mechanism, apparently, so it was little help.

ipy
>>> from System import TimeZone
>>> localZone = TimeZone.CurrentTimeZone
>>> print localZone.StandardName
Eastern Standard Time
>>> localZone.GetDaylightChanges( 2007 ).Start
<System.DateTime object at 0x000000000000002D [11-Mar-2007 02:00:00]>

BTW, 11-Mar is correct (not 10-Mar like I mentioned earlier).

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

Comment By: Jason R. Coombs (jaraco)
Date: 2007-09-04 10:13

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

It's not immediately clear to me what's going on here.  It does appear as
if GetTimeZoneInformation() is returning the wrong values.

>>> win32api.GetTimeZoneInformation()
(2, (300, u'Eastern Standard Time', <PyTime:01-Nov-2000 02:00:00>, 0,
u'Eastern Daylight Time', <PyTime:02-Mar-2000 02:00:00>, -60))

One interesting point to note is the date is 2000 (not 2007).  I don't
know why this would be.  This year, it should be 04-Nov and 10-Mar.  The
01-Nov and 02-Mar does coincide with first and second weeks, so perhaps
pywin32 is misinterpreting the structure?  It's just a SYSTEMTIME, so that
seems unlikely.

I suspect this problem emerged with the introduction of dynamic time
zones.  I'd be interested to see what the results of
GetDynamicTimeZoneInformation or GetTimeZoneInformationForYear would
produce.

I think the next steps are to (a) double-check the source to confirm the
fields are being parsed correctly and (b) to call this from another
platform (native C++ or .NET) to see what the results of the call are.

Bernhard, would you be willing to return the output of the raw
GetTimeZoneInformation() call?  I think that would help me prove or
disprove my theory of the fields being mis-interpreted.

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

Comment By: Jason R. Coombs (jaraco)
Date: 2007-09-04 09:40

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

I am seeing this behavior on my US Win Vista machine also.  I will
investigate.

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

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

[pywin32-bugs] [ pywin32-Bugs-2820111 ] Timezone Problem

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

Bugs item #2820111, was opened at 2009-07-11 11:55
Message generated for change (Tracker Item Submitted) made by rebstwok
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2820111&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: Roscoe Bailey (rebstwok)
Assigned to: Nobody/Anonymous (nobody)
Summary: Timezone Problem

Initial Comment:
I've been wrestling with the timezone module in pywin32 for several of days and was wondering if any one here might know how to solve the following Keyword: 'Std' error.

I've looked at the code and double checked my system registry and there is an entry for Std in each of the timezones in the hive.

Here is a listing from PythonWin and what can be done to repeat the failure:

PythonWin 3.0.1 (r301:69561, Feb 13 2009, 20:04:18) [MSC v.1500 32 bit (Intel)] on win32.
Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for further copyright information.
>>> import os
>>> import sys
>>> import time
>>> import pywin32
>>> import pywin32api
>>> import win32api
>>> import win32file
>>> import win32timezone
>>> import datetime
>>> assert 'Mountain Standard Time' in win32timezone.TimeZoneInfo.get_sorted_time_zone_names()
Traceback (most recent call last):
File "<interactive input>", line 1, in <module>
File "C:\Python30\lib\site-packages\win32\lib\win32timezone.py", line 588, in get_sorted_time_zone_names
tzs = TimeZoneInfo.get_sorted_time_zones()
File "C:\Python30\lib\site-packages\win32\lib\win32timezone.py", line 606, in get_sorted_time_zones
zones = TimeZoneInfo.get_all_time_zones()
File "C:\Python30\lib\site-packages\win32\lib\win32timezone.py", line 594, in get_all_time_zones
return [TimeZoneInfo(n) for n in TimeZoneInfo._get_time_zone_key_names()]
File "C:\Python30\lib\site-packages\win32\lib\win32timezone.py", line 594, in <listcomp>
return [TimeZoneInfo(n) for n in TimeZoneInfo._get_time_zone_key_names()]
File "C:\Python30\lib\site-packages\win32\lib\win32timezone.py", line 385, in __init__
self._LoadInfoFromKey()
File "C:\Python30\lib\site-packages\win32\lib\win32timezone.py", line 406, in _LoadInfoFromKey
key = self._FindTimeZoneKey()
File "C:\Python30\lib\site-packages\win32\lib\win32timezone.py", line 392, in _FindTimeZoneKey
zoneNames = dict(self._get_indexed_time_zone_keys('Std'))
File "C:\Python30\lib\site-packages\win32\lib\win32timezone.py", line 581, in get_index_value
return key[index_key]
KeyError: 'Std'

Thanks

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

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