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

[pywin32-bugs] [ pywin32-Patches-886588 ] [Bug: 817035] Exception while browsing python path

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Maxim Sokolov (dzuki)
Assigned to: Nobody/Anonymous (nobody)
Summary: [Bug: 817035] Exception while browsing python path

Initial Comment:
The problem is that self.name for module level functions 
containes Function object and not string object. 
I have pached it with:
lib\site-packages\Pythonwin\pywin\tools\browseProjects.
py
line 26: 

return self.name + self.suffix

changed to:

name = self.name
if not isinstance(self.name, type("")):
name = self.name.name
return name + self.suffix 

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

>Comment By: Maxim Sokolov (dzuki)
Date: 2004-01-29 02:00

Message:
Logged In: YES 
user_id=264383

Right formatting:

name = self.name
if not isinstance(self.name, type("")):
    name = self.name.name
return name + self.suffix

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=886588&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 14:43
Message generated for change (Comment added) made by kanich
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=716708&group_id=78018

Category: pythonwin
Group: None
Status: Open
Resolution: None
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: Kanich Vladimir (kanich)
Date: 2004-01-22 09: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 12: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 12: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-28 15: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-18 16: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 09: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-Patches-873846 ] Fix PyTime.Format (null pointer error)

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

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

Category: None
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: David Fraser (davidfraser)
Assigned to: Nobody/Anonymous (nobody)
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: David Fraser (davidfraser)
Date: 2004-01-19 16: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-Bugs-868473 ] win32all-163 install problems

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

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

Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Tabares (gustabares)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32all-163 install problems

Initial Comment:
I've had several problems installing version 163 of the
Windows Extensions. I have seen these problems on 8
seperate machines running either Win2k or WinXP. These
machines were all previously running Python 2.3.2 with
the 157 version of the Windows extensions.

I attempted to upgrade each machine to Python 2.3.3
with version 163. The uninstall of Python 2.3.2 and 157
went smoothly on every machine. The install of Python
2.3.3 also went smoothly on every machine.

The problem comes at the end of the 163 install. When
the install goes to register the COM Server AXScript
Engine, the install either crashes or produces the
following error messages:

exceptions.AttributeError: 'module' object has no
attribute '__import_pywin32_system_module__'
exceptions.AttributeError: 'module' object has no
attribute 'com_error'
exceptions.ImportError: cannot import name DISPATCH_METHOD

When the install crashes, I relaunch the install for
163 and it asks if I would like to uninstall, so I
click 'Yes' and the uinstall fails, so it continues to
install 163 and works fine. However, machines that
receive the above error messages I am unable to fix or
get working.

These machines are up-to-date as far as updates and
patches but have NOT installed any kind of COM updates
or such. 

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

Comment By: Todd Whiteman (twhiteman)
Date: 2004-01-19 16:09

Message:
Logged In: YES 
user_id=954612

I have noticed the same error.
I have a brand new Windows XP machine.

I installed Python-2.3.3.exe.
I then proceeded to try and install win32all-163.exe.
The install crashes (around 100% progress bar) and no 
cleanup is performed.

Any ideas on why this is occuring?


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

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

[pywin32-bugs] [ pywin32-Bugs-784962 ] Installation crash in recent win32all's.

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

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

Category: None
Group: None
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: John J Smith (johnjsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installation crash in recent win32all's.

Initial Comment:
The win32all installer has been crashing on me for
the last few win32all releases.

This has happened for Python 2.2.3 with win32all-156
and Python 2.3 with win32all-157.  It has also
happened for some previous win32all releases
(such as 153 and 155 with Python 2.3).

The error occurs during the `Completing Installation'
stage, when the message box says
`Registering COM Server AXScript Engine'.  The
error message is the usual `This program has performed
an illegal operation and will be shut down' message.
Pressing the `Details' button gives:

WIN32ALL-156 caused an invalid page fault in
module MSVCRT.DLL at 016f:7800b936.
Registers:
EAX=006b61a0 CS=016f EIP=7800b936 EFLGS=00010202
EBX=00000000 SS=0177 ESP=0063cad4 EBP=0063caf0
ECX=00000120 DS=0177 ESI=01ddab0c FS=3fb7
EDX=00000000 ES=0177 EDI=00000013 GS=0000
Bytes at CS:EIP:
89 5a 04 8b 55 0c 89 4d fc 8b 5a 04 8b 52 08 89 
Stack dump:
00760840 01ddab10 00000001 006b8930 00000000 
000004d0 00000120 0063cb34 7800b30c 0075005c 
01ddac2c 00760840 00000000 00000001 bff813f8 
81d52568 

(This is with Python 2.2.3 and win32all-156.)

This has happened on both WinXP and Win98SE.

Once this happens, the win32all uninstaller doesn't
work (says `can't find install.log').

If Python is installed with the `Non-Admin' option,
then win32all installs fine (presumably because it
never reaches the `Registering COM Server AXScript
Engine' stage).

I haven't seen anyone else report this, so looks like
I'm the only one.  Any help is greatly appreciated.


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

Comment By: Eric Promislow (ericp)
Date: 2004-01-15 19:37

Message:
Logged In: YES 
user_id=63713

I ran into this problem as well, with version 2.3.3
from Python.org, and win32all 163.

This happened on both Windows Server 2003 (with
.Net 1.0 installed), and Win2K (no .Net installed).
I didn't try further systems.

The event log says the crash is due to an access
violation in RtlDestroyHeap()

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

Comment By: Andy Lange (andylange)
Date: 2003-10-10 08:17

Message:
Logged In: YES 
user_id=884085

Well, installing and removing win32all-153 and then
installing -157 let -157 install without any errors
reported, so it appears that something is changed (and left
changed) by the earlier installers that is required for more
recent installers to work.  I really don't know enough about
what it is doing to figure out exactly what that something
is, though.

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

Comment By: Andy Lange (andylange)
Date: 2003-10-10 08:13

Message:
Logged In: YES 
user_id=884085

I have seen this also - trying to install win32all-157 over
python 2.3.2 would consistently hang my machine (win XP Pro)
at the registration point.   Sometimes it would leave the
"Registering COM Server AXScript Engine" message up,
sometimes it would clear that progress box and then hang. 
(All installs attempted with normal Admin option). 

Every time I finished rebooting, there would be nothing to
install via the Windows add/remove programs control panel.
Attempting to check the version of PythonCOM23.dll with the
Windows properties function showed no "version" tab,
although PyWinTypes23.dll appeared to be fine. 

I then tried the newer win32all-159, which didn't hang, but
did give me the following error: "Registration of the
AXScript Engine COM Server Failed.  Install will
continue....manual registration required", then
"Exceptions.EOFError:"  (nothing after the EOFError:).  The
windows uninstaller can't remove it because it can't find
INSTALL.LOG.

Putting the older win32all-153 on top mostly worked, except
for problems reported with the version mismatch on
PyWinTypes23.dll.  153 seems to have uninstalled (According
to windows) but the dll verisons are still reported as -153,
and the 159 version is apparently still there and still not
removable via add/remove.  I will try reinstalling (now that
an earlier version was installed/removed) and will post
results here. 

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

Comment By: John J Smith (johnjsmith)
Date: 2003-09-13 20:02

Message:
Logged In: YES 
user_id=830565

This seems to be related to bug #799063 (Registering Python
COM Server component category crashes).


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

Comment By: Michael Geary (geary)
Date: 2003-08-11 07:24

Message:
Logged In: YES 
user_id=114596

I see a very similar crash when installing win32all-154 on a
Python 2.2.2 installation. This is on a clean Windows XP
virtual machine with nothing but VS.NET 2003 installed.

If I install Python 2.2.2 on this VM and then install
win32all-154, it crashes. If I then run the pyscript.py,
that succeeds.

After reverting the VM, if I install Python 2.2.2 and then
install win32all-152, it succeeds. If I then install
win32all-154 (letting it uninstall 152), this also succeeds.
So the crash happens only when installing 154 without having
previously installed 152.

The crash is an access violation writing to location 0. Here
is the stack trace (with apologies for its length):

	ntdll.dll!77f57e4f() 	
 	ntdll.dll!77f93a50() 	
 	ntdll.dll!77f93a50() 	
 	ntdll.dll!77f57cf7() 	
 	ntdll.dll!77f588f5() 	
 	ntdll.dll!77f93a73() 	
 	ntdll.dll!77f5be44() 	
 	kernel32.dll!77e78bf1() 	
 	kernel32.dll!77e78c14() 	
 	kernel32.dll!77e78c14() 	
 	msvcrt.dll!77c2ac14() 	
 	msvcrt.dll!77c2ac2a() 	
 	msvcrt.dll!77c2ac55() 	
 	python22.dll!1e04f836() 	
 	python22.dll!1e052b2d() 	
 	python22.dll!1e052963() 	
 	python22.dll!1e05306b() 	
 	python22.dll!1e052ef3() 	
 	python22.dll!1e05e84b() 	
 	python22.dll!1e05e886() 	
 	python22.dll!1e040f66() 	
 	python22.dll!1e040d92() 	
 	ntdll.dll!77f58ec1() 	
 	msvcrt.dll!77c2ab2e() 	
 	msvcrt.dll!77c2ab33() 	
 	msvcrt.dll!77c2ab33() 	
 	python22.dll!1e040ab3() 	
 	python22.dll!1e04025b() 	
 	ntdll.dll!77f588f5() 	
 	python22.dll!1e03afdb() 	
 	ntdll.dll!77f58ec1() 	
 	msvcrt.dll!77c2ab2e() 	
 	msvcrt.dll!77c2ab33() 	
 	python22.dll!1e02f9ab() 	
 	msvcrt.dll!77c2ab33() 	
 	python22.dll!1e04f9eb() 	
 	python22.dll!1e03fe16() 	
 	python22.dll!1e03fe4c() 	
 	python22.dll!1e03fac6() 	
 	ntdll.dll!77f93a73() 	
 	ntdll.dll!77f58a7e() 	
 	ntdll.dll!77f58ec1() 	
 	python22.dll!1e016137() 	
 	python22.dll!1e015e89() 	
 	python22.dll!1e03a90f() 	
 	python22.dll!1e03f98f() 	
 	python22.dll!1e00d2f8() 	
 	python22.dll!1e04d469() 	
 	python22.dll!1e006ccc() 	
 	python22.dll!1e014977() 	
 	python22.dll!1e012879() 	
 	python22.dll!1e01376f() 	
 	python22.dll!1e013e2f() 	
 	python22.dll!1e0109f2() 	
 	python22.dll!1e03f701() 	
 	python22.dll!1e040ddc() 	
 	python22.dll!1e02fc88() 	
 	python22.dll!1e02fc88() 	
 	python22.dll!1e051151() 	
 	python22.dll!1e050dcb() 	
 	python22.dll!1e040ab3() 	
 	python22.dll!1e04025b() 	
 	python22.dll!1e03afdb() 	
 	python22.dll!1e03ac39() 	
 	ntdll.dll!77f8d98c() 	
 	msvcrt.dll!77c2af77() 	
 	ntdll.dll!77f83367() 	
 	python22.dll!1e03fe16() 	
 	python22.dll!1e03fb04() 	
 	user32.dll!77d48fb4() 	
 	ntdll.dll!77f93a73() 	
 	ntdll.dll!77f58a7e() 	
 	ntdll.dll!77f58ec1() 	
 	python22.dll!1e04d469() 	
 	python22.dll!1e072ae1() 	
 	python22.dll!1e072b09() 	
 	python22.dll!1e072d2b() 	
 	python22.dll!1e01349d() 	
 	python22.dll!1e072ac9() 	
 	python22.dll!1e072b09() 	
 	python22.dll!1e072d2b() 	
 	python22.dll!1e03f98f() 	
 	python22.dll!1e00d2f8() 	
 	python22.dll!1e04d469() 	
 	python22.dll!1e012c54() 	
 	python22.dll!1e01376f() 	
 	python22.dll!1e013e2f() 	
 	python22.dll!1e039390() 	
 	python22.dll!1e006ccc() 	
 	python22.dll!1e014977() 	
 	python22.dll!1e00d427() 	
 	python22.dll!1e04d469() 	
 	python22.dll!1e012c54() 	
 	python22.dll!1e01376f() 	
 	python22.dll!1e013e2f() 	
 	python22.dll!1e039390() 	
 	python22.dll!1e006ccc() 	
 	python22.dll!1e014977() 	
 	python22.dll!1e00d427() 	
 	python22.dll!1e04d469() 	
 	python22.dll!1e012c54() 	
 	python22.dll!1e01376f() 	
 	python22.dll!1e013e2f() 	
 	python22.dll!1e014c14() 	
 	python22.dll!1e012d1a() 	
 	python22.dll!1e01376f() 	
 	python22.dll!1e013e2f() 	
 	python22.dll!1e039390() 	
 	python22.dll!1e006ccc() 	
 	python22.dll!1e014977() 	
 	python22.dll!1e006ca1() 	
 	PyWise22.dll!00a91bd8() 	

-Mike

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

Comment By: John J Smith (johnjsmith)
Date: 2003-08-08 10:12

Message:
Logged In: YES 
user_id=830565

Okay, here is some more info.

This sequence on a newly installed Win98SE works:

  Install Python 2.2.3
  Install win32all-152

This sequence on a newly installed Win98SE crashes:

  Install Python 2.2.3
  Install win32all-154

This sequence on a newly installed Win98SE *works*:

  Install Python 2.2.3
  Install win32all-152
  Uninstall win32all-152
  Install win32all-154

And, finally, this also works on a fresh Win98SE:

  Install Python 2.2.3
  Install win32all-152
  Uninstall win32all-152
  Install win32all-154
  Uninstall win32all-154
  Uninstall Python 2.2.3
  Install Python 2.3
  Install win32all-157

The installer crash has happened for me on at least 5 PCs
with very different configurations (spanning Win98SE,
Win2K, WinXP, Athlon, P3, P4, and different peripherals
and drivers).  In each case, Python and win32all were
being installed for the first time on the PC.

My guess is that most people are upgrading from cleanly
installed versions of win32all, and are therefore not
seeing the problem.


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

Comment By: John J Smith (johnjsmith)
Date: 2003-08-08 08:47

Message:
Logged In: YES 
user_id=830565

I assume you mean run it after the failed installation.
I tried it on Python 2.3, win32all-157, Win98SE, and it
worked:

  Registered: Python
  Registration of Python ActiveX Scripting Engine complete.

And yes, an admin install even after crashing does work,
and I've been using it.  However it would be nice to have
a clean install (especially for eventual un-installation and
upgradation).


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

Comment By: Mark Hammond (mhammond)
Date: 2003-08-08 04:07

Message:
Logged In: YES 
user_id=14198

Can you please see if running
"win32comext\axscript\client\pyscript.py" also crashes for you?

An admin install should still actually work fine - just
can't be uninstalled, and a couple of demo COM objects won't
be installed.

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

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

[pywin32-bugs] [ pywin32-Bugs-799063 ] Registering Python COM Server component category crashes

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

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

Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Kirst (mattkirst)
Assigned to: Nobody/Anonymous (nobody)
Summary: Registering Python COM Server component category crashes

Initial Comment:
When registering the Python COM Server component 
category, Python crashes with Dr.Watson.

The crash happens when executing the last line in the 
function:

def RegisterPyComCategory():
  """ Register the Python COM Server component 
category.
  """
  regCat = _cat_registrar()
  regCat.RegisterCategories( [ (CATID_PythonCOMServer,
                                0x0409,
                                "Python COM Server") ] )

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

Comment By: Eric Promislow (ericp)
Date: 2004-01-15 19:35

Message:
Logged In: YES 
user_id=63713

I got occasional crashes when registering a Python
COM Server on a clean Win2K system with 
ActivePython 2.3.2 build 232.  When attempting
to register a COM server the first time, I would
get an access violation reported in PyNode_Future

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

Comment By: Stuart Rackham (sjrackham)
Date: 2003-09-28 00:49

Message:
Logged In: YES 
user_id=655059

Observed on Win98/XP/2000/NT4.
A workaround is to have your installer write the following
registry entry *before* registering the server:

[HKEY_CLASSES_ROOT\Component
Categories\{B3EF80D0-68E2-11D0-A689-00C04FD658FF}]
"409"="Python COM Server"


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

Comment By: Matthias Kirst (mattkirst)
Date: 2003-09-05 06:55

Message:
Logged In: YES 
user_id=397984

Bingo!
The installation crashed as well with 154 (NT/XP).
Since I experienced my crash with a customized 
Python/PythonCOM version I did not register the scripting 
engine -> the crash occured when I registered my first COM 
component.
Since win32all does not unregister the  Python COM Server 
component category when uninstalling you succeed when 
preinstalling an older version of win32all.


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

Comment By: John J Smith (johnjsmith)
Date: 2003-09-04 18:47

Message:
Logged In: YES 
user_id=830565

Is this related to bug #784962 (Installation crash in recent
win32all's)?


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

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

[pywin32-bugs] [ pywin32-Bugs-874184 ] pythonwin debugger: paste problem in a watch window

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

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

Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dmitry Dembinsky (xloggerz)
Assigned to: Nobody/Anonymous (nobody)
Summary: pythonwin debugger: paste problem in a watch window

Initial Comment:
When pasting an expression in a watch window, the only
option is to use 
mouse right-click -> Paste

Using Ctrl-V or Shift-Insert causes a clipboard
contents to be pasted in an active editor window
instead of a watch window.

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

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

[pywin32-bugs] [ pywin32-Bugs-874176 ] pythonwin debugger does not track changed files

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

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

Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dmitry Dembinsky (xloggerz)
Assigned to: Nobody/Anonymous (nobody)
Summary: pythonwin debugger does not track changed files

Initial Comment:
I have encountered a problem while running python
scripts under pythonwin debugger
It looks like the debugger does not track changes in
the imported files.

Here's the sequence to reproduce the problem:

1. Create two files with the following contents and
save them in the same directory:
    File imptest.py:
        def f(): print "f ()"

    File test.py:
        import imptest

        if __name__=='__main__':
            imptest.f ()

2. Open test.py in an IDE and select File -> Run...
(either with or without debugger)
    "f ()" 
    will be printed in an interactive window

3. Now edit file imptest.py (no matter inside or
outside of the IDE) and change the funcion f() so that
it'd print something else, e.g.:
    def f(): print "f () changed"

    Then, run test.py again.
    It will still print "f ()" instead of expected "f
() changed"

The change in code would not be reflected, unless IDE
is restarted or "reload(imptest)" is manually invoked
in an interactive window.

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

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

[pywin32-bugs] [ pywin32-Bugs-874096 ] Race condition with genpy.py and stdout

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

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

Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Boreham (dboreham)
Assigned to: Nobody/Anonymous (nobody)
Summary: Race condition with genpy.py and stdout

Initial Comment:

I've been investigating a problem for a client of mine
where the symptoms were that a generated python
file in the ...\win32com\gen_py directory had become
corrupted. It looked mostly ok, but contained one
line of text which was not Python. I tracked that string
down to another part of the application, completely
unrelated.

Upon investigation I believe that the cause is this
code in genpy.py:

  def generate(self, file, is_for_demand = 0):
    if is_for_demand:
      self.generate_type = GEN_DEMAND_BASE
    else:
      self.generate_type = GEN_FULL
    self.file = file
    oldOut = sys.stdout
    sys.stdout = file
    try:
      self.do_generate()
    finally:
      sys.stdout = oldOut
      self.file = None
      self.progress.Finished()

It's redirecting stdout for the generated python file.
In the application this happens underneath a call
to gencache.EnsureModule().
Unfortunately the application is concurrently executing 
another thread which is also writing to stdout.

The result is that the two sets of output are 
intermingled.

I guess that it would be possible to refactor the
code in genpy.py such that it outputs to a file
rather than to stdout (the file could be stdout
for cases where the code is run as a standalone
utility).

I see the checkin comment for version 1.30
suggests that this is a known problem:

>Also started a move to "print >>" for the generation.

Thanks.



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

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

[pywin32-bugs] [ pywin32-Patches-873847 ] add test to catch null pointer error in PyTime.Format

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Fraser (davidfraser)
Assigned to: Nobody/Anonymous (nobody)
Summary: add test to catch null pointer error in PyTime.Format

Initial Comment:
This test will crash Python in versions that don't have
the fix for the null pointer in PyTime.Format

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=873847&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-09 17:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=873846&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Fraser (davidfraser)
Assigned to: Nobody/Anonymous (nobody)
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.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=873846&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 14:43
Message generated for change (Comment added) made by hweber
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=716708&group_id=78018

Category: pythonwin
Group: None
Status: Open
Resolution: None
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: Henrik Weber (hweber)
Date: 2004-01-07 12: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 12: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-28 15: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-18 16: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 09: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-716708 ] pythonwin editor does strange things with non-english chars

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

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

Category: pythonwin
Group: None
Status: Open
Resolution: None
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: Henrik Weber (hweber)
Date: 2004-01-07 12: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-28 15: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-18 16: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 09: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-868473 ] win32all-163 install problems

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

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

Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Tabares (gustabares)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32all-163 install problems

Initial Comment:
I've had several problems installing version 163 of the
Windows Extensions. I have seen these problems on 8
seperate machines running either Win2k or WinXP. These
machines were all previously running Python 2.3.2 with
the 157 version of the Windows extensions.

I attempted to upgrade each machine to Python 2.3.3
with version 163. The uninstall of Python 2.3.2 and 157
went smoothly on every machine. The install of Python
2.3.3 also went smoothly on every machine.

The problem comes at the end of the 163 install. When
the install goes to register the COM Server AXScript
Engine, the install either crashes or produces the
following error messages:

exceptions.AttributeError: 'module' object has no
attribute '__import_pywin32_system_module__'
exceptions.AttributeError: 'module' object has no
attribute 'com_error'
exceptions.ImportError: cannot import name DISPATCH_METHOD

When the install crashes, I relaunch the install for
163 and it asks if I would like to uninstall, so I
click 'Yes' and the uinstall fails, so it continues to
install 163 and works fine. However, machines that
receive the above error messages I am unable to fix or
get working.

These machines are up-to-date as far as updates and
patches but have NOT installed any kind of COM updates
or such. 

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

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

[pywin32-bugs] [ pywin32-Feature Requests-861514 ] Dedent, Indent Region. Plus Collapsible Sections.

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

Feature Requests item #861514, was opened at 2003-12-17 09:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=861514&group_id=78018

Category: pythonwin
Group: None
Status: Open
Priority: 5
Submitted By: mike foord (fuzzy_dream)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dedent, Indent Region. Plus Collapsible Sections.

Initial Comment:
In IDLE I use the Indent and Unindent region options -  
frequently.
Particularly by their shortcuts - 'ctrl-]' and 'ctrl-['.
Not only does pythonwin use a different shortcut for 
dedent region - but it doesn't have a shortcut at all for 
indent region.

For this region I tend to edit my modules in IDLE and 
only use pythonwin for my main code - because of it's 
quick 'import/reload - module' option. (Which 
intermittently fails to reload a module by the way... - 
*possibly* caused by occasional conflicts with Psyco 
the optimizing compiler ?).

Also an option to collapse sections of code from view 
would be useful.

If these features I request are *already* available - 
could you contact me on mike at pcblokes dot com ??

Thanks

Fuzzy




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

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

[pywin32-bugs] [ pywin32-Bugs-861258 ] PyTime.Format kills Python interpreter

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

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

Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Waldemar Osuch (osuchw)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyTime.Format kills Python interpreter

Initial Comment:
When using win32all-163 following session causes hard
crash.

C:\Python23>python
Python 2.3.2 (#49, Oct  2 2003, 20:02:00) [MSC v.1200
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import pywintypes
>>> t = pywintypes.Time(-1223123)
>>> t
<PyTime:12/30/1899 12:00:00 AM>
>>> t.Format('%d-%b-%Y')

See attached DrWatson log file

I came accross this error when retrieving dates from
MSAcces database and trying to convert it into
something I can load into Oracle.
It seems that the dates before epoch cause this.

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

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

[pywin32-bugs] [ pywin32-Bugs-858458 ] CoInitializeSecurity checks obAuthSvc is NULL not Py_None

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

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

Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Garth Bushell (garth_42)
Assigned to: Nobody/Anonymous (nobody)
Summary: CoInitializeSecurity checks obAuthSvc is NULL not Py_None

Initial Comment:
(Patch attached Below)

CoInitializeSecurity checks to see if obAuthSvc is
NULL. it should Check to see if it is Equal to Py_None

This means that CoInitializeSecurity  call is pretty
useless! Unless I'm using it wrong as you can only
specify the Auth services to be none and not let COM
Choose!

I'm using like this..

pythoncom.CoInitializeSecurity( None,                 
               None, None,                            
  pythoncom.RPC_C_AUTHN_LEVEL_CALL,
pythoncom.RPC_C_IMP_LEVEL_IMPERSONATE,
None,
0x10, #pythoncom.EOAC_DYNAMIC_CLOAKING ,
None)

Patch attached 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=858458&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 14:43
Message generated for change (Comment added) made by glenfant
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=716708&group_id=78018

Category: pythonwin
Group: None
Status: Open
Resolution: None
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: Gilles Lenfant (glenfant)
Date: 2003-11-28 15: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-18 16: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 09: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-Patches-850322 ] Patch to fix error running makepy.py

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

Patches item #850322, was opened at 2003-11-27 18:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=850322&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
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...

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

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

[pywin32-bugs] [ pywin32-Bugs-849191 ] SaveBarState called too many times

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

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

Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Waldemar Osuch (osuchw)
Assigned to: Nobody/Anonymous (nobody)
Summary: SaveBarState called too many times

Initial Comment:
I have noticed that after a debuggin session in
Pythonwin my 
HKEY_CURRENT_USER\Software\Python 2.3\Python for Win32
registry key can grow very large.
It seems that the way I work:
 - step trough the code in debuger.
 - find and fix an error.
 - stop debugger.
 - repeat.
provokes uncontrollable frenzy of writing to registry
the state of toolbars.  On a few occasions I ended up
with over a thousand 'ToolbarDebugging-Bar%s' %i
entries i beeing as high as 1500.
If not stopped Pythonwin gives <Could not load toolbar
state> message and continue to work but very slowly.
My workaround is:
 - delete the offending registry key
 - start Pythonwin
 - set the preferences to my liking.
 - start debugging sessions.  Set prefrences again.
 - close Pythonwin.
 - comment out line 462 in Pythonwin\pywin\debugger.py

I have observed the same behaviour for versions of
Pythonwin going back as far v.154 on Windows2000 and Win98 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=849191&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 06:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=848035&group_id=78018

Category: win32
Group: None
Status: Open
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.


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

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

[pywin32-bugs] [ pywin32-Bugs-841605 ] com->Excel: 'int' object has no attribute 'GetTypeInfo'

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

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

Category: com
Group: None
Status: Open
Resolution: None
>Priority: 9
Submitted By: bob gailer (ramrom)
Assigned to: Nobody/Anonymous (nobody)
Summary: com->Excel: 'int' object has no attribute 'GetTypeInfo'

Initial Comment:
win32all Version 154 
------------ CODE ---------------
import win32com.client
ex =
win32com.client.Dispatch("excel.application");ex.Visible
= 1
wb = ex.Workbooks.Open('i:\samis\data\graph_base.xls')
sheets = ex.Worksheets.Count
ex.Worksheets(1).Copy(None, ex.Worksheets(1))
wk2 = ex.Worksheets(sheets + 1)
co = wk2.ChartObjects(1)
ch = co.Chart
ch.ChartType = 4 # xlLine
series_range = ex.Range("C25:D27")
ch.SeriesCollection().Add(series_range, 2)
------------ ERROR ---------------
  File "i:\samis\python\super_out.py", line 11
    ch.SeriesCollection().Add(series_range, 2)
  File "<COMObject SeriesCollection>", line 3, in Add
  File
"C:\Python22\lib\site-packages\win32com\client\__init__.py",
line 93, in Dispatch
    return __WrapDispatch(dispatch, userName,
resultCLSID, typeinfo, UnicodeToString, clsctx)
  File
"C:\Python22\lib\site-packages\win32com\client\__init__.py",
line 41, in __WrapDispatch
    return dynamic.Dispatch(dispatch, userName,
WrapperClass, typeinfo,
UnicodeToString=UnicodeToString,clsctx=clsctx)
  File
"C:\Python22\lib\site-packages\win32com\client\dynamic.py",
line 90, in Dispatch
    typeinfo = IDispatch.GetTypeInfo()
AttributeError: 'int' object has no attribute 'GetTypeInfo'


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

>Comment By: bob gailer (ramrom)
Date: 2003-11-21 13:54

Message:
Logged In: YES 
user_id=587593

I really need help with this one, as I cannot serve my
client's needs until it is fixed.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=841605&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-21 16:19
Message generated for change (Settings changed) made by hughperkins
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=846682&group_id=78018

Category: win32
Group: None
Status: Open
>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.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=846682&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-21 16:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=846682&group_id=78018

Category: win32
Group: None
Status: Open
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.


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

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

[pywin32-bugs] [ pywin32-Bugs-753033 ] Help misses functions

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

Bugs item #753033, was opened at 2003-06-12 06:36
Message generated for change (Settings changed) made by dubnerm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=753033&group_id=78018

Category: win32
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Dubner (dubnerm)
Assigned to: Mark Hammond (mhammond)
Summary: Help misses functions

Initial Comment:
Help for win32all-152 misses entries for
AppendMenu, InsertMenu, InsertMenuItem
possibly for other items too... somebody should check

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

Comment By: Michael Dubner (dubnerm)
Date: 2003-09-04 09:08

Message:
Logged In: YES 
user_id=39274

Just a reminder: for version 155 problem is still here.

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

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