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

[pywin32-bugs] [ pywin32-Bugs-801291 ] problem with ADO.CommandeExecute() options

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: problem with ADO.CommandeExecute() options

Initial Comment:
I posted this originally on comp.python.  I'm reposting it 
here since it seems a more appropriate place.

I'm hoping this is a coding error on my part, but I've 
encountered a problem with parameters that I cannot 
understand.  Perhaps someone out there might be willing 
to assist me with some suggestions.
 
First, here is some VB code that correctly does what I 
want to do:
 
--------------------------- begin cmdtest.vbs
Dim cn
Dim rs
Dim cmd
 
Set cn = CreateObject( "ADODB.Connection" )
cn.Open( "Provider=SQLOLEDB;Data Source=
(local);Initial Catalog=Environmental 
Monitoring;Integrated Security=SSPI" )
 
Set rs = CreateObject( "ADODB.Stream" )
rs.Open()
 
Set cmd = CreateObject( "ADODB.Command" )
 
cmd.ActiveConnection = cn          
cmd.Properties("Output Stream").Value = rs
cmd.CommandText = "SELECT * FROM [Sources] for 
XML AUTO"
 
cmd.Execute , , 1024 'adExecuteStream
 
rs.Position = 0
WScript.Echo rs.ReadText()
--------------------------- end cmdtest.vbs
 
Here is partial output I get:
C:\>cscript cmdtest.vbs
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All 
rights reserved.
 
<Sources ID="1" Name="South Asia" 
Type="7"/><Sources ID="2" Name="Japan" Type="2"/>...
 
 
 
Now, if I attempt to do the same thing in python, it 
returns no output.
------------------------- begin cmdtest.py
import ADO, sys
 
cn = ADO.Connection()
cn.Open( "Provider=SQLOLEDB;Data Source=
(local);Initial Catalog=Environmental 
Monitoring;Integrated Security=SSPI" )
 
rs = ADO.Stream()
rs.Open()
 
cmd = ADO.Command()
 
cmd.ActiveConnection = cn          
cmd.Properties("Output Stream").Value = rs
cmd.CommandText = "SELECT * FROM [Sources] for 
XML AUTO"
 
cmd.Execute( Options = 
ADO.constants.adExecuteStream )
 
rs.Position = 0
sys.stdout.write( rs.ReadText() ) # prints nothing
------------------------- end cmdtest.py
 
If I pass no parameters to cmd.Execute in the VBScript 
verison, I get no output.  Other tests have further led 
me to conclude that the constant value 1024 is not 
being properly passed to ADO.Command.Execute in the 
Python version only.
 
Here are some other points of information:
 - Using the literal 1024 in the Python code instead of 
the constant reference make no difference. 
 - The VBScript code does not recognize 
adExecuteStream by name. 
 - Using win32com.client.Dispatch( 'ADODB.*' ) to 
create the objects (instead of ADO.py created from 
make PY) yields the same results. 
 - Using a different PROVIDER in the connection (such 
as SQLXMLOLEDB) will yield different results, but still 
indicates that the 'adExecuteStream' is not being set 
properly. 
 - I'm using "Microsoft ActiveX Data Objects 2.8 Library" 
for the ADO.  I've tried using v2.5 and 2.7, but get 
identical results. 
 - The first parameter to ADO.Command.Execute 
appears to be an [out] parameter, but the 
documentation is confusing and I haven't seen the first 
parameter used anywhere.
 
Any insight into this problem would be most appreciated.
 
Regards,
Jason R. Coombs
Sandia National Laboratories

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

Comment By: Jason R. Coombs (jaraco)
Date: 2003-09-09 07:47

Message:
Logged In: YES 
user_id=599869

  Thanks for the comment, but it doesn't address my issue.  I 
apologize for being unclear.

  The reason I am passing an ADO.Stream (Prog ID 
ADODB.Stream) object as the "Output Stream" property of 
the command is because this is the only way AFAIK to 
retrieve the results of a "SELECT ... FOR XML" query in SQL 
Server via ADO.

  I can use the rs = cmd.Execute(...) syntax to receive the 
results of a standard query returning a recordset (where rs is 
a two-tuple containing the recordset and the result status).

  Upon further investigation, I found that the RecordsAffected 
(first parameter to cmd.Execute) is involved in the ADO not 
behaving as expected.

  By sheer luck, I was able to get the Python code to work by 
passing something (and as it turns out anything) as the 
RecordsAffected Parameter.

  Leaving all other code the same, but replacing the execute 
line with the following yields the same results as the VB code.

cmd.Execute( 1, Options = ADO.constants.adExecuteStream )

  Furthermore, passing any value as RecordsAffected or even 
passing it as a keyword argument seems to alleviate the 
problem.

cmd.Execute( RecordsAffected = None, Options = 
ADO.constants.adExecuteStream )
cmd.Execute( 'jelly beans', Options = 
ADO.constants.adExecuteStream )

all work just as well as the control code (VB).

The VB code works fine with all such parameters except for a 
string value (such as "jelly beans").


I hope this sheds some more light on the issue I'm 
experiencing with passing parameters to the 
ADO.Command.Execute method.  Fortunately, I've found a 
workaround now, but it would be nice to track down the core 
of the problem.

Any ideas?

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

Comment By: Roger Upole (rupole)
Date: 2003-09-06 08:40

Message:
Logged In: YES 
user_id=771074

Output parameters are returned as results of the method call, 
so you would do rs=cmd.Execute(....).
    hth
       Roger


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

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

[pywin32-bugs] [ pywin32-Bugs-861877 ] DCOM Disabled and Install Error

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

Bugs item #861877, was opened at 2003-12-18 06:41
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=861877&group_id=78018

>Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: DCOM Disabled and Install Error

Initial Comment:
Everything installs OK until the very last portion of
the process when items are "registering" a Windows
Error box appears and asks if you want to submit an
error report created by the win32all program to MS.
We've disabled DCOM (for obvious security reasons) on
these XP machines... would that cause a problem for the
win32all installer?

Outside the registration error, everything seems to
work OK the IDE, the modules, of course, we don't use
the COM components.

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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-25 17:27

Message:
Logged In: YES 
user_id=14198

Not sure about this one - maybe no DCOM would cause failure!
 Moving to bugs

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

Comment By: Nobody/Anonymous (nobody)
Date: 2003-12-18 09:40

Message:
Logged In: NO 

I'm hok...@ho...

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

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

[pywin32-bugs] [ pywin32-Feature Requests-722847 ] installation without administrator rights

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

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

Category: pythonwin
Group: None
>Status: Closed
Priority: 5
Submitted By: Raphael Alla (khadrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: installation without administrator rights

Initial Comment:
On windows XP, the installation fails if the user installing the 
package is not administrator. This is because the 
installation tries to modify some keys in the registry which 
cannot be modified by a normal user.

It would be good if the installation could be updated to allow 
a normal user to install the package (the python package 
allows this)

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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-25 16:57

Message:
Logged In: YES 
user_id=14198

This should all be implemented now!

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

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

[pywin32-bugs] [ pywin32-Feature Requests-790878 ] SetSecurityDescriptorOwner

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

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

Category: win32
Group: None
>Status: Closed
Priority: 5
Submitted By: Stephen Brown (skbrown1975)
Assigned to: Nobody/Anonymous (nobody)
Summary: SetSecurityDescriptorOwner

Initial Comment:
Support of the SetSecurityDescriptorOwner on the 
win32security.SECURITY_DESCRIPTOR object would be 
useful.

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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-25 16:56

Message:
Logged In: YES 
user_id=14198

Roger to the rescue again - done!

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

Comment By: Roger Upole (rupole)
Date: 2003-08-22 03:13

Message:
Logged In: YES 
user_id=771074

This is already present in more recent win32all builds.
        Roger


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

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

[pywin32-bugs] [ pywin32-Feature Requests-722416 ] GetUserNameEx

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

Feature Requests item #722416, was opened at 2003-04-16 20:58
Message generated for change (Settings changed) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=722416&group_id=78018

Category: win32
Group: None
>Status: Closed
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Nobody/Anonymous (nobody)
Summary: GetUserNameEx

Initial Comment:
GetUserNameEx() would make life easier in an ADSI
environment.

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

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

[pywin32-bugs] [ pywin32-Feature Requests-930298 ] need VBArray support

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

Feature Requests item #930298, was opened at 2004-04-06 18:48
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=930298&group_id=78018

Category: com
Group: None
>Status: Closed
Priority: 5
Submitted By: Max Belugin (belugin)
Assigned to: Nobody/Anonymous (nobody)
Summary: need VBArray support

Initial Comment:
For integration with flashget 
(http://www.flashget.com/) need VBArray support

Test VBCode:

	Dim params2(5)		
	set flashget=CreateObject("JetCar.Netscape")
	Dim j
	for j=0 to 5
		params2(j)="http://test.com/"&j
	next
	flashget.AddUrlList params2

Test python code:

import win32com.client
import array
flashget = win32com.client.Dispatch("JetCar.Netscape")
urls=[
	'http://test.com/1', 
	'http://test.com/2', 
	'http://test.com/3', 
	'http://test.com/4', 
	'http://test.com/5'
]
flashget.AddUrlList(urls)


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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-25 16:55

Message:
Logged In: YES 
user_id=14198

VB Arrays work fine, and have for quite some time.  If you
can post a sample with VB code for a COM object that
supports arrays, and Python code that fails to use it, then
please open a bug attaching that code.

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

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

[pywin32-bugs] [ pywin32-Feature Requests-846682 ] Add PyACL::AddAccessAllowedAceEx

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

Feature Requests item #846682, was opened at 2003-11-22 03:19
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=846682&group_id=78018

Category: win32
Group: None
>Status: Closed
Priority: 7
Submitted By: Hugh Perkins (hughperkins)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add PyACL::AddAccessAllowedAceEx

Initial Comment:
Please could you add the 
PyACL::AddAccessAllowedAceEx function to the 
win32security module?

Python for Windows NT/XP administration
because it very fast, very easy and very powerful.

I'd like to use it instead of xcacls because there are 
certain limitations in xcacls which can be overcome by 
directly editing the ACEs.

AddAccessAllowedAceEx provides the ability to set the 
CI/IO header types, allowing the direct modification of 
directory permissions from within Python.


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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-25 16:53

Message:
Logged In: YES 
user_id=14198

Done (thanks Roger!)

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

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

[pywin32-bugs] [ pywin32-Feature Requests-848035 ] Add PyACL::AddAccessAllowedAceEx

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

Feature Requests item #848035, was opened at 2003-11-24 17:58
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=848035&group_id=78018

Category: win32
Group: None
>Status: Closed
Priority: 5
Submitted By: Hugh Perkins (hughperkins)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add PyACL::AddAccessAllowedAceEx

Initial Comment:
Please could you add the 
PyACL::AddAccessAllowedAceEx function to the 
win32security module?

Python for Windows NT/XP administration
because it very fast, very easy and very powerful.

I'd like to use it instead of xcacls because there are 
certain limitations in xcacls which can be overcome by 
directly editing the ACEs.

AddAccessAllowedAceEx provides the ability to set the 
CI/IO header types, allowing the direct modification of 
directory permissions from within Python.


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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-25 16:52

Message:
Logged In: YES 
user_id=14198

Done (thanks Roger!)

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

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

[pywin32-bugs] [ pywin32-Feature Requests-766328 ] Explorer Shell Extensions

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

Feature Requests item #766328, was opened at 2003-07-05 23:16
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=766328&group_id=78018

Category: win32
Group: None
>Status: Closed
Priority: 5
Submitted By: Ruben Marquez (rrm1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Explorer Shell Extensions

Initial Comment:
Hope this is not a silly request.  I wonder if a way of 
implementing Explorer Shell Extensions could be provided 
so that they could be built with Python without having 
to resort to C/C++.  

For background on this request, you can look at the first 
hit on a search on comp.lang.python for "shell 
extension".  

Your work and help is much apreciated.

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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-25 16:52

Message:
Logged In: YES 
user_id=14198

This is implemented in the current source, and will be
released with the next build.  Build 200 has partial support.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2003-09-30 13:35

Message:
Logged In: NO 

As a last resort you can try to do in on pythonscript (.wsc)...

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

Comment By: Ruben Marquez (rrm1)
Date: 2003-07-21 23:21

Message:
Logged In: YES 
user_id=307646

There have been a few threads at C.L.P. about this issue in 
the past.  One particularly interesting included M.H. and A. 
Martelli.  It looked as if they were onto something, but I don't 
think it was followed through.  This is the link:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-
8&oe=UTF-8&th=20a5f8176ef4ddcd&rnum=2

It looks like what needs to be implemented is IDropTarget, 
IDataObject, and/or IPersistFile. These interfaces would be 
added to the existing "win32com.shell" module.

-Ruben

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

Comment By: Michael Dubner (dubnerm)
Date: 2003-07-20 11:09

Message:
Logged In: YES 
user_id=39274

Not sure but, isn't creating an explorer extention just a
matter of implementing object supporting some pre-defined
interfaces (i.e. for extention toolbar)?

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

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

[pywin32-bugs] [ pywin32-Patches-873846 ] Fix PyTime.Format (null pointer error)

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David Fraser (davidfraser)
Assigned to: Mark Hammond (mhammond)
Summary: Fix PyTime.Format (null pointer error)

Initial Comment:
PyTime.Format currently crashes with a null pointer
exception on times before 1970. (pywintypes.Time(x)
where x < -1)

In Patch 808465 I submitted a change to PyTime.Format
that used mktime and localtime to generate the day of
week and day of year since day of year is not included
in the SYSTEMTIME struct. This can crash because if the
time is before 1970 (e.g. pywintypes.Time(-10)) then
mktime returns -1 and localtime returns NULL.

This is a patch that rather does the calculations
properly (they are just numeric).
I took the code directly from the Python 2.3 datetime
module and merged in the required functions.
The resulting code is therefore simple and more reliable.

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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-25 16:47

Message:
Logged In: YES 
user_id=14198

Sorry for the delay.  I checked this in, with the addition
of setting the is_dst flag correctly from the current
system.  Thanks!

Checking in PyTime.cpp;
new revision: 1.11; previous revision: 1.10


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

Comment By: David Fraser (davidfraser)
Date: 2004-03-05 23:25

Message:
Logged In: YES 
user_id=221678

No longer high priority as a fix for the crash has been applied.
But still, this is more general code.
Should it still be applied?
Or linked to the Python 2.3 datetime module?

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

Comment By: David Fraser (davidfraser)
Date: 2004-03-02 18:30

Message:
Logged In: YES 
user_id=221678

Changing priority - this should be fixed soon!
There is a test to demonstrate it in bug 873847

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

Comment By: David Fraser (davidfraser)
Date: 2004-01-20 01:14

Message:
Logged In: YES 
user_id=221678

fixes a crash, so should be applied soon

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

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

[pywin32-bugs] [ pywin32-Patches-937779 ] ODBC-Metadata

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

Patches item #937779, was opened at 2004-04-19 20:14
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=937779&group_id=78018

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andre Reitz (inworks)
Assigned to: Nobody/Anonymous (nobody)
Summary: ODBC-Metadata

Initial Comment:
Hi all,

please aplly this patch.

We use pywin32 to connect ODBC-Databases.
Our DB-adapter reads the column-metadata after sending
a query. 

Everything works great except that all column names 
are in lowercase.

The patch deletes only the line which is responsible for that:

  _strlwr(name);


I am looking forward, that somebody applies this patch before 
nexts release of pywin32.


Greetings, Andre'

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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-25 14:32

Message:
Logged In: YES 
user_id=14198

Sounds reasonable to me - I see no good reason for the strlwr.

Checking in odbc.cpp;
new revision: 1.10; previous revision: 1.9

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

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

[pywin32-bugs] [ pywin32-Patches-850322 ] Patch to fix error running makepy.py

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

Patches item #850322, was opened at 2003-11-28 03:22
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=850322&group_id=78018

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David Fraser (davidfraser)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch to fix error running makepy.py

Initial Comment:
Hi

When running makepy.py to try and speed up COM access
to ADO, received the following error in selecttlb.py:

win32com\client>makepy.py "Microsoft ActiveX Data
Objects 2.7 Library"
Traceback (most recent call last):
  File "win32com\client\makepy.py", line 369, in ?
    rc = main()
  File "win32com\client\makepy.py", line 362, in main
    GenerateFromTypeLibSpec(arg, f, verboseLevel =
verboseLevel, bForDemand = bForDemand, bBuildHidden =
hiddenSpec)
  File "win32com\client\makepy.py", line 215, in
GenerateFromTypeLibSpec
    typelibs = GetTypeLibsForSpec(typelibInfo)
  File "win32com\client\makepy.py", line 157, in
GetTypeLibsForSpec
    tlbs = selecttlb.FindTlbsWithDescription(arg)
  File "win32com\client\selecttlb.py", line 127, in
FindTlbsWithDescription
    items = EnumTlbs()
  File "win32com\client\selecttlb.py", line 119, in
EnumTlbs
    spec.ver_desc = tlbdesc + " (" + version + ")"
TypeError: unsupported operand types for +: 'NoneType'
and 'str'

Unfortunately am remote and cannot debug what entry in
the registry caused this, but created a patch to ignore
such an error, and have attached it here (this is from
win32all-162.exe, which contains the latest CVS version)

Instead of exiting, it prints "TypeError" and the
parameters, and continues...

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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-25 14:24

Message:
Logged In: YES 
user_id=14198

Fixed, but in a slightly different way.

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

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

[pywin32-bugs] [ pywin32-Patches-898555 ] Patch to use arbitrarely sized Safearray

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Stefan Schukat (sschukat)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch to use arbitrarely sized Safearray

Initial Comment:
In the current implementation you can only recieve
arbitrary sized SAFEARRAYs via pythoncom. If you want
to send these SAFEARRAYs there is a limitation that all
dimensions must have the same size. I patched the
oleargs.cpp to calculate the dimension of any Python
sequence to be converted, so that any sized sequence
can be transported. 
In the attached file you find a test COM server, a
python test script and the changed oleargs.cpp

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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-25 14:13

Message:
Logged In: YES 
user_id=14198

Thanks Stefan - I checked this in.  I had to make a couple
of changes to your code to allow all the old tests to pass -
specifically, handling zero-size sequences and buffer
objects as special cases.  I've also checked most of your
test code into our existing COM test harness.

Thanks!  Sorry for the delay.

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

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

[pywin32-bugs] [ pywin32-Patches-891068 ] win32con.py: added font qualities and charsets

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kerim Borchaev (warkid)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32con.py: added font qualities and charsets

Initial Comment:
Added font qualities and charsets WINVER >= 0x0400.

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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-24 10:55

Message:
Logged In: YES 
user_id=14198

Checked in - thanks.

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

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

[pywin32-bugs] [ pywin32-Patches-825294 ] StgOpenStorageEx

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Roger Upole (rupole)
Assigned to: Roger Upole (rupole)
Summary: StgOpenStorageEx

Initial Comment:
Opens extended property sets for normal files
(StgOpenStorage only accesses properties for compound 
object documents - Microsoft binder files, *.obd).
Requires Win2k or higher and NTFS.

Files changed:
PyStorage.cpp - added StgOpenStorageEx
storagecon.py - add constants needed by above
PythonCOM.cpp - added FMTID's
PythonCOM.h - add forward declaration of 
PyCom_PyObjectFromSTATPROPSETSTG
Register.cpp - add IEnumSTATPROPSETSTG

PyComHelpers.cpp - add 
PyCom_PyObjectAsSTGOPTIONS, move 
PyCom_PyObjectFromSTATPROPSETSTG here (renamed)

PyIEnumSTATPROPSETSTG.cpp - new
PyIEnumSTATPROPSETSTG.h      -new
PyIPropertyStorage.cpp - move conversion of     
STATPROPSETSTG to PyComHelpers



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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-23 22:18

Message:
Logged In: YES 
user_id=14198

Pretty sure this is in too :)  StgOpenStorageEx certainly is!

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

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

[pywin32-bugs] [ pywin32-Patches-812181 ] EnumResourceTypes, EnumResourceLanguages

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

Patches item #812181, was opened at 2003-09-25 13:26
Message generated for change (Settings changed) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=812181&group_id=78018

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Roger Upole (rupole)
Assigned to: Roger Upole (rupole)
Summary: EnumResourceTypes, EnumResourceLanguages

Initial Comment:
Unicode versions

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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-23 22:16

Message:
Logged In: YES 
user_id=14198

this is already in

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

Comment By: Mark Hammond (mhammond)
Date: 2003-10-19 09:49

Message:
Logged In: YES 
user_id=14198

Can you please regenerate this patch (or just check it in!)

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

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

[pywin32-bugs] [ pywin32-Bugs-785258 ] Recent breakage in VBComponents

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Mark Carter (comcol)
Assigned to: Nobody/Anonymous (nobody)
Summary: Recent breakage in VBComponents

Initial Comment:

I use Office 2000, Windows 98, and I have recently 
upgraded to python 2.3 and
win32all-155.exe

The following code worked in python 2.2 under an old 
pywin32:

xlApp = Dispatch("Excel.Application")
xlApp.Visible = 1
xlApp.Workbooks.Add()
xlApp.ActiveWorkbook.SaveAs(sys.path[0] + '\temp.xls')
wb = xlApp.Workbooks("temp.xls")
wbc = wb.VBProject.VBComponents # <---- CAUSES 
CRASH IN 2.3
xlApp.Quit()
del xlApp

but I get a GPE in 2.3, when the code finishes execution:
EXCEL caused an invalid page fault in
module OLE32.DLL at 0167:65f18ae3.

If you comment out the line 
wbc = ...
then I get no GPE.


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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-22 18:46

Message:
Logged In: YES 
user_id=14198

As per previous comments, closing as an excel bug.

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

Comment By: Mark Carter (comcol)
Date: 2003-08-09 23:09

Message:
Logged In: YES 
user_id=478116

Response by mhammond:

I think this is a bug in Excel, but it is not clear why Python 
2.3 shows 
it, but 2.2 does not.  If you set wbc to None before closing, it 
doesn't 
crash.  I think the problem is that Excel doesn't like being 
shut down 
when references to it still exist.  You should try and make 
sure that 
pythoncom._GetInterfaceCount() returns zero before quitting

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

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

[pywin32-bugs] [ pywin32-Bugs-838232 ] SetScrollInfo incorrectly raises exception

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

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

Category: win32
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: SetScrollInfo incorrectly raises exception

Initial Comment:
I'm using win32all build 163 on Windows XP.  I just got 
an api exception with 0 error code when using 
win32gui.SetScrollInfo.  It looks like the reason for this 
is that PySetScrollInfo treats the result of the 
SetScrollInfo api call as a BOOL, with a false result 
indicating error.  My copy of the win32 api 
documentation states that SetScrollInfo returns the 
current position of the scroll box.  This position 
happened to be 0 in my case, so PySetScrollInfo raised 
an exception.

Also, I just discovered that win32gui.GetScrollInfo also 
generates an api error with a 0 error code.  Looking at 
the source, I note that PyGetScrollInfo does not fill in 
the fMask field before calling GetScrollInfo.  My 
documentation indicates the mask must be initialized to 
specify which members to retrieve.

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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-22 20:03

Message:
Logged In: YES 
user_id=14198

Sorry for the delay!  I checked this in:
Checking in win32gui.i;
new revision: 1.36; previous revision: 1.35


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

Comment By: Greg Chapman (glchapman)
Date: 2003-11-12 05:38

Message:
Logged In: YES 
user_id=86307

I'm attaching a diff file to indicate the changes I think are 
needed.  I used the web CVS browser to get the win32gui.i 
file, so the date of the original is wrong, but it is revision 
1.31.  The changes included address both this report and 
report 838065.

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

Comment By: Greg Chapman (glchapman)
Date: 2003-11-08 10:25

Message:
Logged In: YES 
user_id=86307

Also concerning win32gui.GetScrollInfo, if it creates an 
exception because ok is false, it fails to return NULL.


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

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

[pywin32-bugs] [ pywin32-Bugs-828151 ] various external libraries change the C locale

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

Bugs item #828151, was opened at 2003-10-22 21:17
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=828151&group_id=78018

Category: win32
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Johan Fredrik Öhman (johanfo)
Assigned to: Nobody/Anonymous (nobody)
>Summary: various external libraries change the C locale

Initial Comment:
This bug caused me some major headache.  On some 
machines (not all) the win32pdh.AddCounter(base, path) 
causes some trouble with the Locale so that the decimal 
is changed from "." to ","
 This has to be a bug?   BTW What is the easiste way to 
check what version number of your win32 extentions I 
am running?

   print "wgetCpu1 (0.3):", float(0.3)    
   counter = win32pdh.AddCounter(base, path)
   print "wgetCpu2 (0.3):", float(0.3)   
==============================
wgetCpu1 (0.3): 0.3
wgetCpu2 (0.3): 0,3


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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-22 19:19

Message:
Logged In: YES 
user_id=14198

This isn't really a bug in these extensions.  There really
are 2 potential bugs here:
1) that the pdh library changes the C locale.  This is
pretty nasty, and the SpamBayes project found MAPI does the
same thing.  Our solution there was to call
'locale.setlocale(locale.LC_NUMERIC, "C")' after any MAPI
function that may change the locale.
2) That Python screws up when the locale is changed
underneath is.  Specifically, future imports may well fail,
along with other obscure stuff.  There is a bug in the main
Python bug database on this.

I'm not convinced the pywin32 extensions should go to
lengths to work around these problems (eg, resetting the
locale to solve this bug may end up creating others, even
possibly in the PDH libraries themself!)

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

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

[pywin32-bugs] [ pywin32-Bugs-887858 ] printing unicode subclass instance => TypeError

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

Bugs item #887858, was opened at 2004-01-31 08:36
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=887858&group_id=78018

Category: pythonwin
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jason Orendorff (jorend)
Assigned to: Nobody/Anonymous (nobody)
Summary: printing unicode subclass instance => TypeError

Initial Comment:
Ramon M. Felciano reported this problem to me.

The bug happens when you enter code like the following
into PythonWin's interactive window:

	class x(unicode):
		pass

	print x(u'hello world')

(Full traceback at the bottom of this message.)

I have win32all build 163.  In this version, line 440
of
"{PYTHONHOME}\lib\site-packages\Pythonwin\pywin\framework\winout.py"
reads:

	if type(item) != UnicodeType:

Changing this to "if not isinstance(type,
UnicodeType):" fixes the problem for me, and I think it
works in Python 2.2 as well; before that I dunno.

(The reason this comes up at all is that my path class,
http://www.jorendorff.com/articles/python/path, is a
subclass of unicode on Windows.)



PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC
v.1200 32 bit (Intel)] on win32.
Portions Copyright 1994-2001 Mark Hammond
(mha...@sk...) - see 'Help/About
PythonWin' for further copyright information.
>>> class x(unicode):
... 	pass
... 
>>> print x(u'hello world')

Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
  File
"C:\PROGRA~1\PYTHON~1.3\lib\site-packages\Pythonwin\pywin\framework\winout.py",
line 172, in write
    return self.template.write(msg)
  File
"C:\PROGRA~1\PYTHON~1.3\lib\site-packages\Pythonwin\pywin\framework\winout.py",
line 487, in write
    self.HandleOutput(message)
  File
"C:\PROGRA~1\PYTHON~1.3\lib\site-packages\Pythonwin\pywin\framework\winout.py",
line 468, in HandleOutput
    self.QueueFlush()
  File
"C:\PROGRA~1\PYTHON~1.3\lib\site-packages\Pythonwin\pywin\framework\winout.py",
line 441, in QueueFlush
    item = unicode(item, default_platform_encoding)
TypeError: decoding Unicode is not supported


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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-22 19:00

Message:
Logged In: YES 
user_id=14198

This is fixed in build 200, but by accident -
is_platform_unicode is never true any more.  However, your
fix is still correct, and will be checked in.

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

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

[pywin32-bugs] [ pywin32-Bugs-829513 ] Word 10.0 CentimetersToPoints crashes

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

Bugs item #829513, was opened at 2003-10-24 20:48
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=829513&group_id=78018

Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Reinhard König (rkoenigts)
Assigned to: Nobody/Anonymous (nobody)
Summary: Word 10.0 CentimetersToPoints crashes

Initial Comment:
I'm using Python 2.3.1 with win32all-157 and have used makepy for the Word 10.0 object library.
I get:

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import win32com.client
>>> app = win32com.client.Dispatch("Word.Application")
>>> app.CentimetersToPoints(3.)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "00020905-0000-0000-C000-000000000046x0x8x2.py", line 16324, in CentimetersToPoints
    return self._oleobj_.InvokeTypes(371, LCID, 1, (4, 0), ((4, 1),),Centimeters)
pywintypes.com_error: (-2147467259, 'Unbekannter Fehler', None, None)
>>> 

CentimetersToPoints is a method of Application, so, the invoation should be ok?

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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-22 18:53

Message:
Logged In: YES 
user_id=14198

I'm not sure what the problem is, but it doesn't appear
related to Python.  The following vbscript code fails in the
same way:

set app = CreateObject("Word.Application")
app.CentimetersToPoints(3.0)


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

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

[pywin32-bugs] [ pywin32-Bugs-939727 ] There was an error in the DDE conversation with Pythonwin

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

Bugs item #939727, was opened at 2004-04-22 11:24
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=939727&group_id=78018

Category: None
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: achan (alccmb)
Assigned to: Nobody/Anonymous (nobody)
Summary: There was an error in the DDE conversation with Pythonwin

Initial Comment:
There are times when I'm starting Pythonwin, I get this 
error:

"There was an error in the DDE conversation with 
Pythonwin"

After pressing 'ok' button.  The debugger loads. 

What's with this error?

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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-22 18:49

Message:
Logged In: YES 
user_id=14198

This can happen when another app is "frozen", or not
processing windows messages correctly.  DDE itself is quite
fragile.  To avoid this message (by avoiding DDE
alltogether), start Pythonwin with "/nodde" on the
command-line (but multiple Pythonwin's will then start!). 
Marking "wont-fix" as it is DDE's fault more than ours, but
one day DDE might be removed from pythonwin.

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

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

[pywin32-bugs] [ pywin32-Bugs-716708 ] pythonwin editor does strange things with non-english chars

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

Bugs item #716708, was opened at 2003-04-07 22:43
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=716708&group_id=78018

Category: pythonwin
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: pythonwin editor does strange things with non-english chars

Initial Comment:
Reported by a few people, but to repro:
* Paste "# ça ne va pas" into pywin (or any other
string with extended char)
* Move to the ç
* Press Backspace

Some other character appears.  This will be related to
pywin.idle not being mult-character aware.

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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-22 18:48

Message:
Logged In: YES 
user_id=14198

Had a couple of reports that this is fixed in build 200 :)

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

Comment By: Kanich Vladimir (kanich)
Date: 2004-02-26 18:13

Message:
Logged In: YES 
user_id=304670

With the solution described by oleg_noga (replacing of 
scintilla.dll) I tried to edit full string of special Slovak and 
Czech characters (codepage Cp1250) in PythonWin editor 
with full success. Thank you for the solution. N.B. Backspace 
operation in this arragement needs twice to push BACKSPACE 
key.

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

Comment By: Oleg Noga (oleg_noga)
Date: 2004-02-26 02:02

Message:
Logged In: YES 
user_id=551440

view.py, KeyDotEvent() allways generates "." but it can be 
non-english character instead of "."!

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

Comment By: Oleg Noga (oleg_noga)
Date: 2004-02-26 01:32

Message:
Logged In: YES 
user_id=551440

Bug has a solution: editor does not display characters after 
non-english (see followup by anadelonbrin, 2003-05-09 10:38)

Solution is to replase scintilla.dll with latest version. Just 
download scintilla src from sourcefourge, build it and replase 
scintilla.dll with SciLexer.dll (rename SciLexer.dll to 
scintilla.dll). 

It do not solves bugs with clipboard, backspace and Cyrillic 
small "u" ("ю") letter.


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

Comment By: Kanich Vladimir (kanich)
Date: 2004-01-22 19:33

Message:
Logged In: YES 
user_id=304670

I have same problem with encoding 'cp1250' (default encoding 
in sk/cz). Without changing __init__.py file (as recommended 
by hweber) the editor is swallowing the half of characters 
with char-code above 127. It seems that the used editor 
routine is byte-oriented and not UNICODE.
Setting the variable is_platform_unicode = 0 helps also for 
encoding 'cp1250'.

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

Comment By: Henrik Weber (hweber)
Date: 2004-01-07 22:17

Message:
Logged In: YES 
user_id=121229

This behaviour can be worked around by switching off unicode 
support. The easiest way to do this is in the __init__.py file.

Replace the line beginning with is_platform_unicode by this:
is_platform_unicode = 0

With this pythonwin works normally at least with the german 
umlauts (I haven't tried the other ones).

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

Comment By: Henrik Weber (hweber)
Date: 2004-01-07 22:16

Message:
Logged In: YES 
user_id=121229

This behaviour can be worked around by switching off unicode 
support. The easiest way to do this is in the __init__.py file.

Replace the line beginning with is_platform_unicode by this:
is_platform_unicode = 0

With this pythonwin works normally at least with the german 
umlauts (I haven't tried the other ones).

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

Comment By: Gilles Lenfant (glenfant)
Date: 2003-11-29 01:53

Message:
Logged In: YES 
user_id=122383

Same strange charset behaviour when copying text (with non
ASCCI chars) from pythonwin to a regular text editor
(notepad or any other).

It seems that pythonwin copies utf-8 to the clipboard rather
than "natural" default encoding (cp1252 for western european
languages).


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

Comment By: Oleg Noga (oleg_noga)
Date: 2003-08-19 00:08

Message:
Logged In: YES 
user_id=551440

So there are 3 bugs:
------------
First bug (this report, 716708):

Incorrect work of backspace. (Del works ok). I must press 
backspace two times to remove non-english character. This 
bug presents in every version of pythonwin from 1.46, and 
very probably, in the earlier versions.
------------

Second bug (see followup by anadelonbrin, 2003-05-09 10:38
):

Editor does not display characters after non-english.
Another reproduces: 
- open py file with non-english strings, encoded with system 
default encoding. Look at non-english strings in editor: editor 
does not display string ends! Now move cursor at the begin of 
string and move it with right arrow button. Cursor stucks at 
the end of string, and lefts there for click count that equals 
invisible characters count. Move cursor to the inwisible end of 
string. Now type english characters: qwertyu... Invisible end 
of string will apear, but newly typed characters (qwertyu...) 
still not visible. Save file. Look in notepad. Document data is 
ok.
  So this bug is how pythonwin displays strings in editor, it 
does not affect document data.

There was no bug like this in version 1.48, we still use it. But 
it present in earlier versions (1.50 ... 1.55).
--------------

Third bug (seems unreported yet): 

Can't type \xFE character in editor. It is "ю" (Cyrillic small "u") 
letter. Dot typed instead of this character. Interesting that 
dot in at the same keybord button as Cyrillic small "u" letter.  
Editor opens files with this character, displays them correctly, 
and removes and copies them ok.
This bug presents in every version of pythonwin from 1.46, 
and very probably, in the earlier versions.

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

Comment By: Tony Meyer (anadelonbrin)
Date: 2003-05-09 17:38

Message:
Logged In: YES 
user_id=552329

As another example:

In IDLE (0.8):
>>> u = u'questa \xe8 bella'
>>> u
u'questa \xe8 bella'
>>> print u
questa è bella

In PythonWin (152):
>>> u = u'questa \xe8 bella'
>>> u
u'questa \xe8 bella'
>>> print u
questa è bell

(note that if you copy the result of the 'print u', or type 
something after it, the a appears.  *very* confusing!)

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

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

[pywin32-bugs] [ pywin32-Bugs-787563 ] fatal error with taskbar

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

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

Category: win32
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dietmar Schwertberger (dschwertberger)
Assigned to: Nobody/Anonymous (nobody)
Summary: fatal error with taskbar

Initial Comment:
e.g. with demos\win32gui_taskbar.py:

Fatal Python error: This thread state must be current 
when releasing


Python 2.3; win32all versions 1.55 and 1.57; Windows 
2000


OK with 2.2; 1.48; Windows 98

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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-22 18:43

Message:
Logged In: YES 
user_id=14198

Fixed in build 200.

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

Comment By: Kerim Borchaev (warkid)
Date: 2003-08-21 21:20

Message:
Logged In: YES 
user_id=314933

This code just calls CreateWindow and it fails the same way:

################################
import win32gui
import win32api
import win32con

def registerWindowClass():
    def OnDestroy(hwnd, msg, wparam, lparam):
        win32gui.PostQuitMessage(0) # Terminate the app.

    message_map = {
        win32con.WM_DESTROY: OnDestroy,
        }
    wc = win32gui.WNDCLASS()
    wc.hInstance = hinst
    wc.lpszClassName 
= "warkid.try_CreateWindow.WindowClass"
    wc.lpfnWndProc = message_map # could also specify a 
wndproc.
    return win32gui.RegisterClass(wc)

def createWindow(class_atom):
    return win32gui.CreateWindow(
        class_atom,
        "a window",
        0,
        0, 0, win32con.CW_USEDEFAULT, 
win32con.CW_USEDEFAULT,         0, 0, hinst, None)

hinst = win32api.GetModuleHandle(None)

hwnd = createWindow(registerWindowClass())

win32gui.ShowWindow(hwnd, True)

win32gui.PumpMessages()
###################################


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

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

[pywin32-bugs] [ pywin32-Bugs-723837 ] PyHANDLE destructor triggers a SystemError

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

Bugs item #723837, was opened at 2003-04-19 05:03
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=723837&group_id=78018

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jason Orendorff (jorend)
Assigned to: Mark Hammond (mhammond)
Summary: PyHANDLE destructor triggers a SystemError

Initial Comment:
This code is in PyHANDLE.cpp:

/*static*/ void PyHANDLE::deallocFunc(PyObject *ob)
{
	// Call virtual method Close
	((PyHANDLE *)ob)->Close();
    PyErr_Clear(); // can not leave pending exceptions
in destructors.
	delete (PyHANDLE *)ob;
}

If this is called because an unrelated exception
occurred, it incorrectly clears the exception.

For example, suppose I have Python code that calls a
Python function f1().  This function successfully
creates a PyHANDLE, stores it in a local varaible, and
then raises an unrelated exception.  The caller, f2(),
catches the exception.  At this point, the PyHANDLE
still exists because the traceback object has a
reference to it (indirectly).  Now suppose f2() throws
an exception.  The previous traceback object is now
released (replaced by the new traceback).  The PyHANDLE
object is decref'd and freed.  PyHANDLE::deallocFunc()
is called.  The exception that f2() threw is now cleared.

This results in a SystemError.  The attached test case
reproduces it.

I think it should be

    if (!((PyHANDLE *)ob)->Close())
        PyErr_Clear();

but I'm not sure.

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

>Comment By: Mark Hammond (mhammond)
Date: 2004-04-22 18:43

Message:
Logged In: YES 
user_id=14198

This has been fixed for a while now, and should be in the
most recent build.  win32\test\handles.py should demonstrate
it is fixed.

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

Comment By: Mark Hammond (mhammond)
Date: 2003-04-20 14:01

Message:
Logged In: YES 
user_id=14198

This is a little nasty.  I think the PyErr_Clear call is a
hack, but Python prints a warning in some cases.  The
semantics for exceptions during object destruction are hard,
and I will need to look into things a little more - but in
the meantime, please see the new win32\tests\handles.py -
your test case with some additions.  These additions
exercise some of these other cases, which will hopefully
allow you to see my dilemma.

I've been meaning to move to unittest, and this gave me the
push I needed - thanks!  I will probably move some of the
other "demos" code into tests where it belongs.

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

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