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

[pywin32-bugs] [ pywin32-Bugs-1984147 ] Bogus indentation errors

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Hugh S. Myers (hsmyers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bogus indentation errors

Initial Comment:
PythonWin under some circumstances is unable to handle multi line docstrings. Yet when they are removed(the offending docstring), there remain bogus indent errors. This further seems to corrupt the file, as apon reload or restart and load, bogus error is still there.

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-27 21:11

Message:
If you can provide the additional requested information, please reopen this
bug

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

Comment By: Mark Hammond (mhammond)
Date: 2008-07-03 17:53

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

There haven't been any recent fixes to autoindent.  Can you please provide
an example of how I can reproduce this?

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

Comment By: Hugh S. Myers (hsmyers)
Date: 2008-06-04 00:03

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

After some research the bogus errors can be made to go away by block
de-indenting and then re-indenting. Is this the problem fixed with a newer
version of autoindent.py? 

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

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

[pywin32-bugs] [ pywin32-Bugs-1944375 ] PyRegEnumValue fails on i18n systems

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
>Status: Closed
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Christopher Nelson (neverjade)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyRegEnumValue fails on i18n systems

Initial Comment:
If you try to enumerate the contents of the registry key:

"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control Panel\\Cursors\\Schemes"

pywin32 will fail with a (234, "PyRegEnumValue", ""), which means that RegEnumValue returned with ERROR_MORE_DATA.

The method pywin32 currently uses to detect the size of the value name buffer does not work properly on Windows  2003 X64 Japanese.  

To fix this bug you must make the code look like the follwing:

// @pymethod (string,object,type)|win32api|RegEnumValue|Enumerates values of the specified open registry key. The function retrieves the name of one subkey each time it is called.

static PyObject *

PyRegEnumValue( PyObject *self, PyObject *args )

{

	// This value is taken from MSDN docs.

	const DWORD maxValueNameSize=16384;



	HKEY hKey;

	PyObject *obKey;

	int index;

	long rc;

	TCHAR retValueBuf[maxValueNameSize];

	BYTE *retDataBuf;

	DWORD retValueSize = maxValueNameSize;

	DWORD retDataSize=0;

	DWORD typ;

	

	// @pyparm <o PyHKEY>/int|key||An already open key, or any one of the following win32con constants:<nl>HKEY_CLASSES_ROOT<nl>HKEY_CURRENT_USER<nl>HKEY_LOCAL_MACHINE<nl>HKEY_USERS

	// @pyparm int|index||The index of the key to retrieve.



	if (!PyArg_ParseTuple(args, "Oi:PyRegEnumValue", &obKey, &index))

		return NULL;

	if (!PyWinObject_AsHKEY(obKey, &hKey))

		return NULL;

	

	// @pyseeapi PyRegEnumValue

	PyW32_BEGIN_ALLOW_THREADS

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, NULL, &retDataSize);

	PyW32_END_ALLOW_THREADS

		

	// Reset because the call above messed it up.

	retValueSize=maxValueNameSize;

	// Don't need to increment because the size returned from RegEnumValue includes any needed terminators.

	retDataBuf= (BYTE * )alloca(retDataSize);

	if ((retDataBuf==NULL)){

		PyErr_NoMemory();

		return NULL;

		}

	

	rc=RegEnumValue(hKey, index, retValueBuf, &retValueSize, NULL, &typ, retDataBuf, &retDataSize);	 



	if (rc!=ERROR_SUCCESS)

	{		

		return ReturnAPIError("PyRegEnumValue", rc);

	}



	PyObject *obData=PyWinObject_FromRegistryValue(retDataBuf, retDataSize, typ);

	if (obData==NULL)

	{

		return NULL;

	}

	PyObject *retVal = Py_BuildValue("NOi", PyWinObject_FromTCHAR(retValueBuf), obData, typ);

	

	Py_DECREF(obData);

	

	return retVal;

	// @comm This function is typically called repeatedly, until an exception is raised, indicating no more values.

}

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-27 21:10

Message:
This bug had a resolution of "rejected" but was still open, so I closed it.
 Please reopen if you can provide more info.

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

Comment By: Roger Upole (rupole)
Date: 2008-06-18 14:34

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

Have you tried build 211 yet to see if you still get this error ?
It's compiled without UNICODE defined, but I can also provide a
compatible win32api compiled for wide-character to see if that
solves the problem.


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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-17 18:22

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

Bugger - that's what I get for rushing :(  There is still something wrong
here though (my example doesn't seem to read MBCS that represents the
unicode that we wrote, but that isn't related to the bug being discussed
here.)

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

Comment By: Roger Upole (rupole)
Date: 2008-05-17 02:04

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

You're calling RegEnumKey which enumerates subkeys,
and there are none.  Note that the error here is
ERROR_NO_MORE_ITEMS, rather than ERROR_MORE_DATA.


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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-16 22:33

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

I've reproduced this (although sadly with a few hacks).  The trick is (a)
to use a character that doesn't fit in 1 MBCS byte and (b) possibly this
value needs to be the longest in the key.

The following code *should* then demonstrate the problem:
---
import win32api, win32con

test_key_name = "SOFTWARE\\Python Registry Test Key - Delete Me"
root_key = win32con.HKEY_CURRENT_USER
key = win32api.RegCreateKey(root_key, test_key_name)
try:
    win32api.RegSetValueEx(key, u"\u0106", 0, win32con.REG_SZ, u"\u0106")
    print win32api.RegEnumKey(key, 0)
finally:
    key.Close()
    win32api.RegDeleteKey(root_key, test_key_name)
---
However, that is not enough - for some reason, using that same character, I
see:

>>> len(u"\u0106".encode("mbcs"))
1

Which seems quite incorrect to me.  So, I just hacked win32apimodule.cpp to
check for a unicode value and call RegSetValueExW() - and as soon as I did
that, I saw:

Traceback (most recent call last):
  File "\temp\delme.py", line 9, in <module>
print win32api.RegEnumKey(key, 0)
pywintypes.error: (259, 'RegEnumKey', 'No more data is available.')

A look in the debugger shows that the max size returned is zero - which we
add 1 to for the terminator!  Hence this return value.  Sadly, my hack to
RegSetValueEx() is incomplete - PyWinObject_AsRegistryValue() can't handle
both unicode and ansi.

Roger (or anyone) - any clue why I can't seem to make
'len(u"\uxxxx".encode("mbcs"))' return >1 for any value of xxxx?


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

Comment By: Roger Upole (rupole)
Date: 2008-05-16 20:35

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

The size of TCHAR is actually determined at compile time.  It's either 1 or
2
bytes depending solely on whether UNICODE is defined, and does not depend
on
the platform on which it's compiled or run.

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-16 06:18

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

I am attaching a file that contains some changes to the implementations of
RegEnumKey, RegEnumKeyEx, and RegEnumValue - all of which are affected by
this ERROR_MORE_DATA situation.  I have modified the implementation to
expect ERROR_MORE_DATA.

I have looked at the implementation of RegENumValue and friends in the CVS
code.  They still won't work because they presume to know the size of a
TCHAR at compile time, and generally the code is not compiled on an
internationalized box.  I tried a similar implementation that uses the wide
method, and it suffers from the same problem.  I have not tried the link to
the latest version of pywin32, but I will try that today and see if it
resolves the problem.  If it is derived from the code in the latest CVS, it
most likely will not.
File Added: registry_fixes.cpp

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-15 15:35

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

Hrm - I guess an RDP session might be our last option.  Before that, it
would be nice if you can check the latest pywin32 has the same issue, and
if possible, verify that when you get ERROR_MORE_DATA, the actual buffer
size isn't being returned in one of the pointers - that too would allow us
to avoid any hard-coded limits.

Thanks.

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-15 06:55

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

Ah. The .reg file I attached earlier fails properly on a Korean / Japanese
system.  It seems to work fine on an English system.  I suspect this is due
to some underlying difference in the windows registry handling code.  I
don't think it is possible to reproduce this w/o a version of Windows that
is localized in this way. 

I could probably make an RDP session to such a system available if that
would help you or someone else verify this.

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-15 06:25

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

> The test cases won't fail on Latin character sets because they are
> typically 1-byte granular, so 1 TCHAR ends up being 1 byte.  The
Japanese
> and Korean encodings are not that simple. 

Yeah - I was trying to say that if we could use the native Unicode registry
functions to write Unicode values that can't be represented in latin1/mbcs,
then we would probably be well on the way to reproducing this.  But best I
can see, that's not currently possible with pywin32/_winreg - although I
can't see why win32api and/or _winreg can't be modified to handle Unicode
natively in that case.  In the meantime, maybe a .reg file could be used to
simulate the same thing - as you mention, the key is probably to end up
with characters that can't be represented in 1 byte inside our English
registry for test purposes.

Thanks!

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-15 05:39

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

The test cases won't fail on Latin character sets because they are
typically 1-byte granular, so 1 TCHAR ends up being 1 byte.  The Japanese
and Korean encodings are not that simple.  I am also unhappy with setting
to a maximum value, so I have revised RegEnumKey and friends to loop when
detecting ERROR_MORE_DATA.  I will also change that for RegEnumValue.

The Windows API seems a bit fuzzy.  However, QueryInfoKey supposedly
returns the maximum size of a key and value name in Unicode characters,
whereas EnumKey/EnumValue say that they return the exact size in TCHARS. 
TCHARS are not necessarily unicode characters, which makes it frustrating
to interpret.  There are a variety of unicode encodings, and they are not
necessarily byte_width * 2.  For example, in the output I pasted below the
key was apparently 8 TCHARS long, but that translated to a buffer of 12
bytes plus a NULL sequence.

I will look at the CVS version and the link you pasted below and see if I
can reproduce the problem with those versions.

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-15 05:38

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

The test cases won't fail on Latin character sets because they are
typically 1-byte granular, so 1 TCHAR ends up being 1 byte.  The Japanese
and Korean encodings are not that simple.  I am also unhappy with setting
to a maximum value, so I have revised RegEnumKey and friends to loop when
detecting ERROR_MORE_DATA.  I will also change that for RegEnumValue.

The Windows API seems a bit fuzzy.  However, QueryInfoKey supposedly
returns the maximum size of a key and value name in Unicode characters,
whereas EnumKey/EnumValue say that they return the exact size in TCHARS. 
TCHARS are not necessarily unicode characters, which makes it frustrating
to interpret.  There are a variety of unicode encodings, and they are not
necessarily byte_width * 2.  For example, in the output I pasted below the
key was apparently 8 TCHARS long, but that translated to a buffer of 12
bytes plus a NULL sequence.

I will look at the CVS version and the link you pasted below and see if I
can reproduce the problem with those versions.

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-14 18:03

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

You might like to try out
starship.python.net/crew/mhammond/pywin32-210.9.win32-py2.5.exe and see if
you can still repro it.

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

Comment By: Roger Upole (rupole)
Date: 2008-05-14 17:03

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

In CVS, win32apimodule.cpp has already been updated to calculate
the name buffer size in TCHARs, and can be compiled with
UNICODE defined to call the wide-character versions of the
API functions.  With the current CVS code (compiled with
or without UNICODE), I don't get an error while reading the
registry data you posted.


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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-14 15:42

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

Thanks for the update, but I'm afraid I will not have time for a few days,
but a couple of thoughts: does the test case fail on English windows?  If
the issue is simply that the number of bytes returned is sometimes too
small, presumably when multi-byte characters exist, it should be possible
to repro by writing Unicode that has a multi-byte representation and trying
to read it back.  

When you say:
> If you read the documentation for that RegEnumValue closely, you will
> realize that it doesn't actually return what you think.

can you be more specific?  I'd be happy with code that handled the
ERROR_MORE_DATA case, but I'm not happy with setting a hard-coded limit to
either key or value size, and ideally I'd like *some* indication why the
code in question isn't working correctly - as we are discussing the API
itself here, I bet we are not the first people to strike this issue.  Hence
I'm quite keen to see this fail myself (if for no better reason than I can
then submit a patch upstream for Python's _winreg module - they will insist
on a test)

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 12:43

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

I have attached the .cpp file containing the program I used to generate
these results.
File Added: main.cpp

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 12:42

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

I believe there are two problems:

(1) MS's registry code works strangely
(2) python and pywin32 assume that the functions are returning sizes in
bytes, whereas the API documentation clearly says unicode characters (or in
some places, TCHARS.)

This happens to work by accident on Latin character set systems b/c they
usually use utf-8 or similar 8-byte systems. Korean and Japanese systems do
not.
The following is output of a C++ program I wrote to examine the
functionality of the registry functions on a 64-bit japanese localized
system:

C:\temp>\\tsclient\dev\registry_test.exe
info:          number of subkeys: 2
   maximum length of subkey name: 8
                number of values: 0
    maximum length of value name: 0
info: read key name:
  size before call: 9
   size after call: 5
     buffer growth: 0
          contents: agent
warn: the buffer allocated was not large enough:
  size before call: 9
   size after call: 9
       resizing to: 10
warn: the buffer allocated was not large enough:
  size before call: 10
   size after call: 10
       resizing to: 12
warn: the buffer allocated was not large enough:
  size before call: 12
   size after call: 12
       resizing to: 15
info: read key name:
  size before call: 15
   size after call: 12
     buffer growth: 3
          contents: \x8c\xc2\x82\xcc\x83t\x83@\x83C\x83\x8b
info: done

== Some explanation:

Size before call is the size of the buffer we allocated in order retrieve
the results of RegEnumKeyEx.
Size after call is what RegEnumKeyEx wrote back INTO the buffer size
parameter after the RegEnumKeyEx call.
Resizing to is the size in bytes of the buffer that has been enlarged to
potentially fit the contents.
buffer growth is the increment over the value returned by RegEnumKeyEx in
the lpcbName buffer.


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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 07:33

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

I should also clarify - this is a problem with key and value NAMES. Not the
data.

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 06:24

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

I have attached a registry key that causes the failure that I posted below
for your debugging pleasure.

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 06:23

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

File Added: opsware_reg.dat

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 06:22

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

I have also discovered the same problem in RegEnumKey today.  The error
occurs this way:

Testing:  SOFTWARE\Opsware
=========================
agent
Traceback (most recent call last):
  File "c:\temp\testreg3.py", line 21, in ?
    print win32api.RegEnumKey(r2, index)
pywintypes.error: (234, 'RegEnumKey',
'\x83f\x81[\x83^\x82\xaa\x82\xb3\x82\xe7\x
82\xc9\x82\xa0\x82\xe8\x82\xdc\x82\xb7\x81B')

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 06:12

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

File Added: PyRegEnumValue.c

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 06:09

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

File Added: test_pywin32_reg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 06:04

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

File Added: test_winreg.py

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

Comment By: Christopher Nelson (neverjade)
Date: 2008-05-14 06:03

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

Mark, please read the bug description. This happens on i18n systems.  For
example, Windows 2003 x64 localized in Japanese or Korean.  I am sorry that
you haven't had any bug reports on this, but I can guarantee you that if
you run that code on a w2k3 Japanese or Korean localized system, you will
hit that bug.

With respect to you comment that 

// Reset because the call above messed it up.
retValueSize=maxValueNameSize;

is wrong, I would agree with you, except that I watched the original code
not work.  I spent a number of hours tracking this problem down in our
production code, and it came back to this function in pywin32. FWIW,
_winreg manifests the same problem, in the same way.

If you read the documentation for that RegEnumValue closely, you will
realize that it doesn't actually return what you think.  Also, on i18n
systems, the ascii version of this call simply doesn't work correctly. 
Partly this is due to size limitations of the API call.  In any case, the
MSDN documentation does not try to get the key's name size, it simply uses
this value.  I suspect this is because they know that the ascii version of
this call does not work properly.

I am attaching the scripts that fail below.










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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-05 05:59

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

I had another look at this and sadly can't repro it with that key on
win2003.  Either way, the patch as it stands needs work - eg, the code and
comment:

  // Reset because the call above messed it up.
  retValueSize=maxValueNameSize;

is wrong - the whole point of the call above was to determine the size - so
the correct fix given that approach would be to remove the first call
completely.  It also seems this would fail to work for binary values with
more than 16384 bytes from working, which best I can tell does now.  So
while I don't doubt the Japanese version of 2003 fails, I'm rejecting this
as it stands still welcome more input on the best way to approach this -
eg, the smallest script that fails for you would help - I'm assuming it
would be:

  import win32api, win32con
  key=win32api.RegOpenKey(win32con.HKEY_LOCAL_MACHINE,
                         
"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Control
Panel\\Cursors\\Schemes",
                          win32con.KEY_READ)
  print win32api.RegEnumValue(key, 0)

FWIW, Python's _winreg module still has identical code to win32api and no
open bugs on a similar issue, so no one has reported a problem there either
(but that still doesn't mean one doesn't exist :)

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-04 04:07

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

Could you please attach either a patch, or the complete source file with
the new function (all the indentation is lost above)

Thanks.

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

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

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

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roscoe Bailey (rebstwok)
>Assigned to: Jason R. Coombs (jaraco)
Summary: Timezone Problem

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

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

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

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

Thanks

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-27 21:04

Message:
I can't reproduce this, but I've assigned it to Jason who might have some
insights (and sorry for the delay!)

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

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

[pywin32-bugs] [ pywin32-Bugs-3238774 ] Calls from VBScript clobber passed args

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Chris Lambacher (lambacck)
Assigned to: Nobody/Anonymous (nobody)
Summary:  Calls from VBScript clobber passed args

Initial Comment:
I am running into a bug that was submitted erroneously to the python language bug tracker: http://bugs.python.org/issue1156179

I am using v216 with Python 2.6.

The original reporter did some excellent detective work on what is happening. From his description:

I'm using Python 2.4.0 and VBScript under ASP on IIS 5. If I call a 
Python function from VBScript AND pass a local var as the first 
parameter AND don't use the return value, then the local var I 
passed in is, upon the function's return, set to Null.

If I store the return value (even if there isn't one) OR pass the return 
value to another function, this doesn't happen. I'm attaching some 
snippets that demonstrate and work around the bug.

He later updates the problem to be:
call go(x)
clobbers x, as I've said before, but...

call aTwoParamFunction("somethingStatic", x, y)
clobbers x as well! y is not clobbered.

If someone can point me in the general right direction, I am willing to try and fix the bug, but as of right now the active script stuff looks like a maze of twisty little passages, all alike.

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-27 21:01

Message:
Yeah - unfortunately I don't think we can change these semantics at this
stage.

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

Comment By: Chris Lambacher (lambacck)
Date: 2011-03-25 11:01

Message:
Okay let me see if I understand this correctly (I've been looking at the
code of PyGatewayBase.cpp InvokeEx):

In python, there is no way to say I expect these parameters to be passed by
reference and pass values to those parameters so instead, a return tuple is
interpreted as:
    index 0: return value (pVarResult) , 
    subsequent values: the positional values of parameters listed as
by-ref
   
    if there is no pVarResult, assume that return values are only applied
to by-ref arguments (i.e. skip return value)
    
    if return value is not a tuple, interpret the one values as if it were
index 0 and apply same algorithm.
    

Is this documented somewhere? This scheme seems like an awful big burden to
put on the caller. What if the caller missed setting that a particular
value should be by-ref?

I expect we are stuck with it now because someone, somewhere is dependent
on this behavior :(

-Chris


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

Comment By: Mark Hammond (mhammond)
Date: 2011-03-24 15:26

Message:
> Why do we need to pass the return value back if the caller does
not ask for it? 

The problem is that from Python's POV, the caller *has* asked for a result
to be placed in a BYREF param.  This is why there is no problem with only
BYVAL params as there is literally nowhere to put it.

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

Comment By: Chris Lambacher (lambacck)
Date: 2011-03-24 12:55

Message:
I missed your earlier comment so my "discovery" would appear to be obvious
from the information you provided. It probably follows on that this happens
with other VB languages (like VBA) but not with javascript. 

Your answer about not having a place to put the return value sounds
correct. Why do we need to pass the return value back if the caller does
not ask for it? VB makes a distinction between Functions and Subroutines
and has a call convention that explicitly drops the return value using the
Call keyword or by not having parens around the function/method/sub
arguments.



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

Comment By: Chris Lambacher (lambacck)
Date: 2011-03-24 12:20

Message:
More info:
Looks like this happens with a registered com object as well, so it seems
like it is an issue with values passed in to a COM function from at the
very least VBScript in IIS (I am using windows 7).

At least it gives me a place to look.

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

Comment By: Mark Hammond (mhammond)
Date: 2011-03-23 15:37

Message:
That is going to be very hard to avoid given the dynamic nature of Python
and VBScript  - when "go" returns (with an implied value of None or with
any explicit value), pythoncom looks for somewhere to stick the result.  As
the only place is the byref arg, that is where it is placed.  It is
probably possible to work around this by doing something like having the
function raise a COMServerException with a hresult of S_OK, or by tricking
VB into not passing the args byref.

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

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

[pywin32-bugs] [ pywin32-Bugs-3192904 ] v215/py.32 win32 install fails 32 and 64-bit

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: j petrick (jpetrick1)
Assigned to: Nobody/Anonymous (nobody)
Summary: v215/py.32 win32 install fails 32 and 64-bit

Initial Comment:
Both pywin32-215.win32-py3.2.exe and pywin32-215.win-amd64-py3.2.exe throw and exception on install:

Traceback (most recent call last):
  File "<string>", line 604, in <module>
  File "<string>", line 332, in install
  File "<string>", line 15, in write
AttributeError: 'NoneType' object has no attribute 'write'
Exception AttributeError: "'NoneType' object has no attribute 'flush'" in <__main__.Tee object at 0x033995B0> ignored

As a result, 
import win32com.client as win32

fails like this:
Traceback (most recent call last):
  File "D:\EQ\InventoryDumps\testScript1.py", line 1, in <module>
    import win32com.client as win32
  File "D:\Python32\lib\site-packages\win32com\__init__.py", line 5, in <module>
    import win32api, sys, os
ImportError: DLL load failed: The specified module could not be found.

Importing sys and os separately works fine, looks like win32api install failed.


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

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-27 21:00

Message:
Hopefully I'll have a new build out in a few days...

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

Comment By: Mark Hammond (mhammond)
Date: 2011-08-09 23:54

Message:
It is fixed in hg - I hope to release a new binary within a month or so.

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

Comment By: Aneesh (aneeshmbaby)
Date: 2011-08-09 23:44

Message:
Hi, When we can expect a fix for this issue? We have one product which
makes use of this and would like to go for a release of that with Python
3.2 and PyWin32 3.2.

Thanks a lot
Aneesh

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

Comment By: Aneesh (aneeshmbaby)
Date: 2011-07-25 04:50

Message:
I am also facing same problem. Today I tried to install
pywin32-216.win32-py3.1.exe on two different Windows 7 Pro 32 bit machines
and this issue was there always. It got installed fine on a Windows XP
machine. 

The work around mentioned by masinghal helped in installing it but that is
not good enough for us. Would like to have a solution for this quickly...

Thanks,
Aneesh

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

Comment By: masinghal ()
Date: 2011-07-12 15:30

Message:
I ran the postinstall script manually and it failed while creating
shortcuts. It is actually trying to find the "python 3.2" folder in my user
profile roaming data folder. However, python32 is installed for all users
so it does not find the python 3.2 folder and fails. Easiest fix was to
create the "Python 3.2" folder. Better fix would be to modify the script so
that it finds the right folder.

C:\Python32\Scripts>pywin32_postinstall.py -install
Copied pythoncom32.dll to C:\Windows\system32\pythoncom32.dll
Copied pythoncomloader32.dll to C:\Windows\system32\pythoncomloader32.dll
Copied pywintypes32.dll to C:\Windows\system32\pywintypes32.dll
Registered: Python.Interpreter
Registered: Python.Dictionary
Registered: Python
-> Software\Python\PythonCore\3.2\Help[None]=None
-> Software\Python\PythonCore\3.2\Help\Pythonwin
Reference[None]='C:\\Python32\\
Lib\\site-packages\\PyWin32.chm'
Pythonwin has been registered in context menu
Can't install shortcuts -
'C:\\Users\\singhalm\\AppData\\Roaming\\Microsoft\\Win
dows\\Start Menu\\Programs\\Python 3.2' is not a folder
The pywin32 extensions were successfully installed.

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

Comment By: johanfo ()
Date: 2011-03-10 15:36

Message:
I just "double clicked the installer" in windows.  Has tried both with
"admin" and "regular user" rights.

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

Comment By: Mark Hammond (mhammond)
Date: 2011-03-08 01:07

Message:
running the post-install script was to be my next suggestion :)  How did
you start the installer - from a cmd-prompt?  IThis has been reported
before, but it works fine for many (including me) too!

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

Comment By: johanfo ()
Date: 2011-03-08 00:49

Message:
Update: I ran "C:\Python32\Scripts\pywin32_postinstall.py -install" after
the failed installation, and now it works :)  I'm happy!
Still, the installer should be investigated though if you have the time. 
Mark:  Thanks for your time and effort on this project!

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

Comment By: johanfo ()
Date: 2011-03-08 00:41

Message:
Hi!  I am on Vista 64bit, using Python 3.2.    It fails with
pywin32-216.1.win32-py3.2.exe!  By accident, I noticed that I could install
the 64 bit python and the 64bit pywin without any problems.  Unfortunately,
I have to control a 32 bit com object, so I uninstalled all python, deleted
registry and the python directory and started from scratch with 32bit
python and pywin, and then it fails.

Is there something I can do to help you debug this?   I'm not sure where to
start.

JF

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

Comment By: j petrick (jpetrick1)
Date: 2011-03-07 16:42

Message:
216 build, 64-bit installed OK.  I didn't try the 32-bit version.

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

Comment By: Mark Hammond (mhammond)
Date: 2011-03-07 13:32

Message:
Do you have the same problem in build 216?

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

Comment By: johanfo ()
Date: 2011-03-07 11:01

Message:
I have the exact same problem!  Solved it yet?

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

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

[pywin32-bugs] [ pywin32-Bugs-3190606 ] pywin32-215.win32-py2.6.exe ERROR

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: TJ Developer (tjdeveloper)
Assigned to: Nobody/Anonymous (nobody)
Summary: pywin32-215.win32-py2.6.exe ERROR

Initial Comment:
So after struggling with errors trying to use the 64 bit version of PythonWin, I learned that my application can only interface with the 32 bit version.  So I uninstalled EVERYTHING today and decided to start over.  Due to the constraints of my application (ArcGIS), I have to use the Python 2.6 version.  I downloaded pywin32-215.win32-py2.6.exe, but I'm getting the follow error at the very end of the install:

'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "<string>", line 5, in <module>
ImportError: No module named os

Any advice on what might be the problem here?

Thanks!

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-27 20:59

Message:
It appears there isn't a problem relating to pywin32 here - please reopen
if you think that is incorrect.

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

Comment By: TJ Developer (tjdeveloper)
Date: 2011-02-28 06:49

Message:
Okay, I got it fixed.  I had to uninstall EVERYTHING.  Then I cleaned up
the registry a little.  When I reinstalled, I started with the Python26
files and put them in C:\Python26\ArcGIS, followed by the numpy files and
last was the PythonWin install.  I still got the following error for
PythonWin:

close failed in file object destructor:
Error in sys.excepthook:

Original exception was:

However, it appears to have at least installed this time and is working so
far.  Not sure what that error is or how critical it is????

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

Comment By: Mark Hammond (mhammond)
Date: 2011-02-24 14:19

Message:
Sorry I wasn't clear - I was referring to the python install, not pywin32. 
The pywin32 installer is failing to load python, so it looks as though
python itself is messed up.

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

Comment By: TJ Developer (tjdeveloper)
Date: 2011-02-24 06:51

Message:
I simply downloaded the .exe file (the one in the thread title) and ran it.
 There is no "reinstall" because the program did not install.  Due to this
error, the install failed.

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

Comment By: Mark Hammond (mhammond)
Date: 2011-02-23 15:09

Message:
This implies the python install is pretty borked - how did you install it
and can you try reinstalling it?

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

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

[pywin32-bugs] [ pywin32-Bugs-2920507 ] Cannot register active scripting with pyscript.py

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: happyhondje ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot register active scripting with pyscript.py

Initial Comment:
Using Windows 7 Ultimate, I am having trouble installing active scripting for Python 3.1. I'm talking about the following installers:

python-3.1.1.msi
pywin32-214.win32-py3.1.exe

On WXP, it would usually install active scripting fine from the get-go, but I knew from experience that failed sometimes, which it did now. So I went to C:\Python31\Lib\site-packages\win32comext\axscript\client and ran pyscript.py. Whereas in the past, that would work, I get very colourful errors.

First one dialog that is littered with random characters that seem like chinese right after displaying the 'Requesting elevation and retrying...' line, once even a full page of that corrupted junk. Example:

'[Window Title]
㩃坜湩潤獷獜獹整㍭尲浣⹤硥e†ɛ础䫁湥耀ɂ洨ɂ欠ɂ쥨ɂ槠ɂ즸ɂ죈ɂ棈ɂ硋䫁睯耀ɂ辀ɂ輰ɂ쩘ɂ計ɂ뱠ɂ歯湥⠠⁡硎䫁汰耀 ɂ쭈ɂ苘ɂ莠ɂ쯨ɂ衸ɂ걨Ɂ靐Ɂ硑䫁杮耀%ɂ蟘ɂ蠀ɂ챠ɂ諸ɂ軠ɂ鿨ḟ雠Ɂ硔䫁漠耀*?痨?и?欰Ḝ畂汩偤瑡彨牟敶⹲硟䫁琊耀/ḟ锐Ɂ铠Ɂ钀Ɂ鑰ɁꮐɁꯀɁ隰Ɂ硢䫁敭耀4ḟ鿨ḟ需Ɂ鿨ḟ鿨ḟ陀Ɂ鿨ḟ靀Ɂ硥䫁⹳耀9ḟ鿨ḟ꤈Ɂ隐Ɂ鿨ḟ隀Ɂ鿨ḟ霰Ɂ硨䫁桴耀>久佃䥄䝎琠歯湥眊楨档琠汥獬礠畯硳䫁档耀C摯湩⁧慷⁳獵摥琠敤潣敤琠敨戠硶䫁猠耀H⹭᩵

[Content]
Windows cannot find '㩃坜湩潤獷獜獹整㍭尲浣⹤硥e†ɛ础䫁湥耀ɂ洨ɂ欠ɂ쥨ɂ槠ɂ즸ɂ죈ɂ棈ɂ硋䫁睯耀ɂ辀ɂ輰ɂ쩘ɂ計ɂ뱠ɂ歯湥⠠⁡硎䫁汰耀 ɂ쭈ɂ苘ɂ莠ɂ쯨ɂ衸ɂ걨Ɂ靐Ɂ硑䫁杮耀%ɂ蟘ɂ蠀ɂ챠ɂ諸ɂ軠ɂ鿨ḟ雠Ɂ硔䫁漠耀*?痨?и?欰Ḝ畂汩偤瑡彨牟敶⹲硟䫁琊耀/ḟ锐Ɂ铠Ɂ钀Ɂ鑰ɁꮐɁꯀɁ隰Ɂ硢䫁敭耀4ḟ鿨ḟ需Ɂ鿨ḟ鿨ḟ陀Ɂ鿨ḟ靀Ɂ硥䫁⹳耀9ḟ鿨ḟ꤈Ɂ隐Ɂ鿨ḟ隀Ɂ鿨ḟ霰Ɂ硨䫁桴耀>久佃䥄䝎琠歯湥眊楨档琠汥獬礠畯硳䫁档耀C摯湩⁧慷⁳獵摥琠敤潣敤琠敨戠硶䫁猠耀H⹭᩵'. Make sure you typed the name correctly, and then try again.

[OK]

This makes me think buffer overrun or some codepage/encoding issues.

After that I get an ordinary stacktrace:

Requesting elevation and retrying...
Failed to remove tempfile 'c:\users\me\appdata\local\temp\tmpx2_leopycomserverreg.out': [Error 2] The system cannot find the file specified: 'c:\\users\\me\\appdata\\local\\temp\\tmpx2_leopycomserverreg.out'
Traceback (most recent call last):
  File "C:\Python31\lib\site-packages\win32com\server\register.py", line 566, in UseCommandLine
    RegisterClasses(*classes, **flags)
  File "C:\Python31\lib\site-packages\win32com\server\register.py", line 421, in RegisterClasses
    addPyComCat, dispatcherSpec, clsctx, addnPath)
  File "C:\Python31\lib\site-packages\win32com\server\register.py", line 187, in RegisterServer
    _set_string(keyNameRoot, desc)
  File "C:\Python31\lib\site-packages\win32com\server\register.py", line 32, in _set_string
    value)
pywintypes.error: (5, 'RegSetValue', 'Access is denied.')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Python31\Lib\site-packages\win32comext\axscript\client\pyscript.py", line 372, in <module>
    Register()
  File "C:\Python31\Lib\site-packages\win32comext\axscript\client\pyscript.py", line 368, in Register
    finalize_register=DllRegisterServer)
  File "C:\Python31\lib\site-packages\win32com\server\register.py", line 574, in UseCommandLine
    ReExecuteElevated(flags)
  File "C:\Python31\lib\site-packages\win32com\server\register.py", line 531, in ReExecuteElevated
    nShow=win32con.SW_SHOW)
pywintypes.error: (2, 'ShellExecuteEx', 'The system cannot find the file specified.')

Are there any simple temporary fixes for this? I'd love to get this up and running. :)

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-27 20:56

Message:
I can't reproduce this with the current source tree - please re-open if it
still happens once build 217 comes out (which should be soon!)

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

Comment By: happyhondje ()
Date: 2009-12-23 23:43

Message:
Yeah I found that out myself after like one hour of code-sifting. Thanks :)

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

Comment By: Mark Hammond (mhammond)
Date: 2009-12-23 21:30

Message:
A work around may be to use an elevated command prompt (ie, started with
"Run as Administrator") and executing pyscript.py there.  If that fails
too, I suspect it will be a general problem with Python 3.x - trying Python
2.6 should also work.

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

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

[pywin32-bugs] [ pywin32-Bugs-2983917 ] Python AX script engine issue

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Marc-André Belzile (mabxsi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python AX script engine issue

Initial Comment:
My ActiveX object leaks when I submit it as a named item to the Python AX script engine (IActiveScript::AddNamedItem) with my AX site application.

I'm using build 214 on a Vista 64 bit machine. The leak is not there though with build 212, the regression seems to have been introduced with build 213. 


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

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-27 20:53

Message:
Please reopen this if you can provide the requested information.

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

Comment By: Mark Hammond (mhammond)
Date: 2010-10-22 18:33

Message:
I can't reproduce this - there is a 'axscript/test/leakTest.py script which
adds a 'Test' instance as a named item and the script indicates neither COM
objects nor Python objects are leaking.  Is there some way you can repro
this for me?

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

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

[pywin32-bugs] [ pywin32-Bugs-2920544 ] SetScriptSite() returns E_FAIL

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: happyhondje ()
Assigned to: Nobody/Anonymous (nobody)
Summary: SetScriptSite() returns E_FAIL

Initial Comment:
When using Python 3.0 or 3.1 (and the corresponding Pywin32 package) programs can't initialize the scripting engine properly. When using SetScriptSite, they get E_FAIL (80040005) thus preventing initalization. Using pywin32 with the 2.x tree works fine.

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-27 20:52

Message:
I can't reproduce this with the most recent builds (I'm about to release a
new one).  If this still happens with build 217, please re-open this issue.

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

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

[pywin32-bugs] [ pywin32-Bugs-3395490 ] blender python hard to install to

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: installation
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: dug9 (dug9)
Assigned to: Nobody/Anonymous (nobody)
Summary: blender python hard to install to

Initial Comment:
opensource Blender.org uses python and their current release B259 has a 'private copy' of python 31, complete with python and python/lib directories. I use the .zip download of blender, and unzip it to C:, so its python directory is like this: 
C:\blender-2.59-windows32\2.59\python
I also have python installed the usual way, to C:\Python31.
Your / the win32 extension installer sees the Registry value and path for regular python, and installs to that python, but does;t let me pick the blender path. If I copy site_packages from the regular python to the blender python, blender python can't find win32com.client - no module.
If I hack the registry entry 
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\3.1\InstallPath  > Default C:\Python31\
and change it to 
C:\blender-2.59-windows32\2.59\python
then your / the installer correctly gets the directory, and installs it to the blender python, but the installer bombs before finishing - something about 'string'. And so blender can't find the win32com.client module. (The regular python -run from IDLE- has no problem)
Thanks.
more...
I was using a .net thing http://pythonnet.sourceforge.net/  to wrap EarthLib (googleEarth http://earth.google.com/comapi/index.html) COM, but that pythondotnet has fallen behind (python27 is the last binary) and needs a Pro version of visual studio to build (I have free Express edition) so I can't hack it. The goal of using EarthLib from Blender is to do snapshots of the terrain, put them into blender as textured mesh, so artists can use Blender instead of Sketchup to model buildings for googleEarth or X3D deployment.

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-27 19:16

Message:
Sorry, but as mentioned, this bug is really in distutils rather than
pywin32

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

Comment By: dug9 (dug9)
Date: 2011-08-22 05:55

Message:
MH thanks for the quick response. Sorry you couldn't help.
For googleearth snapshot in blender I'll use swigged C wrapper calling
native COM instead of py win32com.client.

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

Comment By: Mark Hammond (mhammond)
Date: 2011-08-21 17:09

Message:
I can't fix the problem with the installer - that is built using distutils
which is built into Python itself, so any bugs related to that should be
filed there.

I also can't give you help on the problems you found after hacking the
install location as you didn't offer enough details, but I suspect I will
not be able to help there either and the issue will be with Blender itself.

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

Comment By: dug9 (dug9)
Date: 2011-08-20 14:11

Message:
PS to launch googleEarth using win32Com.client:
from win32com.client import Dispatch
ge = Dispatch('GoogleEarth.ApplicationGE')



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

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

[pywin32-bugs] [ pywin32-Bugs-3476736 ] Install error in pywin32-216.win32-py2.6

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

Bugs item #3476736, was opened at 2012-01-20 12:08
Message generated for change (Tracker Item Submitted) made by prapancham
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3476736&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Prasanna (prapancham)
Assigned to: Nobody/Anonymous (nobody)
Summary: Install error in pywin32-216.win32-py2.6

Initial Comment:
Hi,
 I am getting following error when trying to install pywin32-216.win32-py2.6


Traceback (most recent call last):
  File "<string>", line 604, in <module>
  File "<string>", line 314, in install
  File "<string>", line 152, in LoadSystemModule
ImportError: DLL load failed: The specified module could not be found.

I am on Win7 Enterprise 64 bit. First I installed the following:

VC++ 2008 Redistributable -x86 9.0.21022
VC++ 2010 x64 Redistributable - 10.0.30319

Then I installed Python 2.6 ( I need to use python 2.6 ONLY) 

Then I am trying to install the above. But it fails. Please advise.

regards,
prasanna.

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

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

[pywin32-bugs] [ pywin32-Patches-3438431 ] ImportFile (Ctrl-I) iter bug

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: ImportFile (Ctrl-I) iter bug

Initial Comment:
diff -ur --strip _orig/scriptutils.py ./scriptutils.py
--- _orig/scriptutils.py	2010-08-25 17:46:40 +0000
+++ ./scriptutils.py	2011-11-15 18:37:26 +0000
@@ -391,7 +391,7 @@
 	path, modName = os.path.split(pathName)
 	modName, modExt = os.path.splitext(modName)
 	newPath = None
-	for key, mod in sys.modules.iteritems():
+	for key, mod in list(sys.modules.iteritems()):
 		if hasattr(mod, '__file__'):
 			fname = mod.__file__
 			base, ext = os.path.splitext(fname)





solves:

Ctrl-I / FileImport: 

>>> Traceback (most recent call last):
  File "C:\Python27\Lib\site-packages\pythonwin\pywin\framework\intpyapp.py", line 330, in OnFileImport
    scriptutils.ImportFile()
  File "C:\Python27\Lib\site-packages\pythonwin\pywin\framework\scriptutils.py", line 394, in ImportFile
    for key, mod in sys.modules.iteritems():
RuntimeError: dictionary changed size during iteration
win32ui.error: Error in Command Message handler for command ID 36867, Code 0



Note: in pure Python2  "sys.modules.iteritems()" would be ok. But for 2to3 the list(sys.modules.iteritems())  should be consistent

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-18 18:56

Message:
Thanks - it is the "lazy importer" in the email package which is
responsible for this.  Fixed in 4184:8fc48a195771

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

Comment By: kxroberto (kxroberto)
Date: 2012-01-14 07:49

Message:
I removed the patch again - and it was quiet for a while.
But when e.g. the email.* package is somehow in sys.modules the error is
reproducable:

>>> import email
[press Ctrl-I for any source window]

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

Comment By: Mark Hammond (mhammond)
Date: 2012-01-01 18:15

Message:
Sorry it has taken me so long to get back to this, but I'm interested in
how sys,modules managed to change during this iteration.  Did you have some
other threads or similar running at the same time which may have imported
modules?  I can't repro it...

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

Comment By: kxroberto (kxroberto)
Date: 2011-11-16 02:40

Message:
well, I do not completely understand the comment and 2to3 and if/how its
used for pywin32 (auto-)maintenance ;-)

(I don't really use Py3 except a raw one for esoteric fun tests. The
problems start with my fingers not wanting to type all those extra braces
for the many print statements ...).

Isn't the problem that Py3 has only .items()  but that behaves (oversmart &
intransparently) like Py2's .iteritems().
Thus the problem of iteration over a dicts items while the dict itself
changes, remains.
But 2to3 I guess (?) doesn't auto-translate d.items()  to  list(d.items())
?
If so I see no other possib than "list(sys.modules.iteritems())"  to trick
it for working universal.



C:\Python23\Lib>python32
Python 3.2.2 (default, Sep  4 2011, 09:51:08) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
  File "C:\bin\pythonrc.py", line 19
    print "-------------- First: PRESS ENTER 2x in GDB! -------------"
                                                                     ^
SyntaxError: invalid syntax
>>> d={2:3,5:6}
>>> d.items
<built-in method items of dict object at 0x00B25930>
>>> d.iteritems
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'dict' object has no attribute 'iteritems'
>>> for x in d.keys(): del d[x]
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: dictionary changed size during iteration
>>> for x in list(d.keys()): del d[x]
...
>>>
>>>

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

Comment By: Mark Hammond (mhammond)
Date: 2011-11-16 01:46

Message:
oops - just saw your comment :)  I admit I like the items() version better
as it is more "consistent" WRT other existing code - the fact that 2to3
changes it is actually a feature

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

Comment By: Mark Hammond (mhammond)
Date: 2011-11-16 01:44

Message:
Wouldt sys,modules.items() be even better?

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

Comment By: kxroberto (kxroberto)
Date: 2011-11-15 10:46

Message:
Note: in pure Python2 "sys.modules.items()" would be ok. But for 2to3 the
list(sys.modules.iteritems()) should be consistent

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

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

[pywin32-bugs] [ pywin32-Patches-3438431 ] ImportFile (Ctrl-I) iter bug

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

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

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

Initial Comment:
diff -ur --strip _orig/scriptutils.py ./scriptutils.py
--- _orig/scriptutils.py	2010-08-25 17:46:40 +0000
+++ ./scriptutils.py	2011-11-15 18:37:26 +0000
@@ -391,7 +391,7 @@
 	path, modName = os.path.split(pathName)
 	modName, modExt = os.path.splitext(modName)
 	newPath = None
-	for key, mod in sys.modules.iteritems():
+	for key, mod in list(sys.modules.iteritems()):
 		if hasattr(mod, '__file__'):
 			fname = mod.__file__
 			base, ext = os.path.splitext(fname)





solves:

Ctrl-I / FileImport: 

>>> Traceback (most recent call last):
  File "C:\Python27\Lib\site-packages\pythonwin\pywin\framework\intpyapp.py", line 330, in OnFileImport
    scriptutils.ImportFile()
  File "C:\Python27\Lib\site-packages\pythonwin\pywin\framework\scriptutils.py", line 394, in ImportFile
    for key, mod in sys.modules.iteritems():
RuntimeError: dictionary changed size during iteration
win32ui.error: Error in Command Message handler for command ID 36867, Code 0



Note: in pure Python2  "sys.modules.iteritems()" would be ok. But for 2to3 the list(sys.modules.iteritems())  should be consistent

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

>Comment By: kxroberto (kxroberto)
Date: 2012-01-14 07:49

Message:
I removed the patch again - and it was quiet for a while.
But when e.g. the email.* package is somehow in sys.modules the error is
reproducable:

>>> import email
[press Ctrl-I for any source window]

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

Comment By: Mark Hammond (mhammond)
Date: 2012-01-01 18:15

Message:
Sorry it has taken me so long to get back to this, but I'm interested in
how sys,modules managed to change during this iteration.  Did you have some
other threads or similar running at the same time which may have imported
modules?  I can't repro it...

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

Comment By: kxroberto (kxroberto)
Date: 2011-11-16 02:40

Message:
well, I do not completely understand the comment and 2to3 and if/how its
used for pywin32 (auto-)maintenance ;-)

(I don't really use Py3 except a raw one for esoteric fun tests. The
problems start with my fingers not wanting to type all those extra braces
for the many print statements ...).

Isn't the problem that Py3 has only .items()  but that behaves (oversmart &
intransparently) like Py2's .iteritems().
Thus the problem of iteration over a dicts items while the dict itself
changes, remains.
But 2to3 I guess (?) doesn't auto-translate d.items()  to  list(d.items())
?
If so I see no other possib than "list(sys.modules.iteritems())"  to trick
it for working universal.



C:\Python23\Lib>python32
Python 3.2.2 (default, Sep  4 2011, 09:51:08) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
  File "C:\bin\pythonrc.py", line 19
    print "-------------- First: PRESS ENTER 2x in GDB! -------------"
                                                                     ^
SyntaxError: invalid syntax
>>> d={2:3,5:6}
>>> d.items
<built-in method items of dict object at 0x00B25930>
>>> d.iteritems
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'dict' object has no attribute 'iteritems'
>>> for x in d.keys(): del d[x]
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: dictionary changed size during iteration
>>> for x in list(d.keys()): del d[x]
...
>>>
>>>

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

Comment By: Mark Hammond (mhammond)
Date: 2011-11-16 01:46

Message:
oops - just saw your comment :)  I admit I like the items() version better
as it is more "consistent" WRT other existing code - the fact that 2to3
changes it is actually a feature

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

Comment By: Mark Hammond (mhammond)
Date: 2011-11-16 01:44

Message:
Wouldt sys,modules.items() be even better?

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

Comment By: kxroberto (kxroberto)
Date: 2011-11-15 10:46

Message:
Note: in pure Python2 "sys.modules.items()" would be ok. But for 2to3 the
list(sys.modules.iteritems()) should be consistent

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

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

[pywin32-bugs] [ pywin32-Bugs-3472307 ] 64-bit installation fails when using custom folder

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: craigjh (craigjh)
Assigned to: Nobody/Anonymous (nobody)
Summary: 64-bit installation fails when using custom folder

Initial Comment:
(Note:  I am new to Python but an experienced IT guy).  I installed Python 3.2.2 to C:\Program Files\Python32 instead of the default location of C:\Python32.  No apparent problems with the Python installation.  I then tried to install pywin32-216.  The installation program crashes hard every time.  I uninstalled Python and then re-installed in the default location.  pywin32-216 installed without a problem.  Thought I'd report this in case I'm not the only one experiencing a problem.

Just in case it matters, this is on a Windows PC running Windows 7 Professional with all updates.  The hardware is an i7-2600K CPU, ASUS P67 motherboard, 16 Gb of RAM, & 2x2Gb drives with lots of free space.

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-11 16:27

Message:
hmm - that exception code 0xc0000417 = STATUS_INVALID_CRUNTIME_PARAMETER. 
I'll try and reproduce this when I get back from vacation (ie, next week)

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

Comment By: craigjh (craigjh)
Date: 2012-01-11 16:13

Message:
Thanks for pointing out where the error log is.  I'm assuming that the
contents were written during the failed installation, not the subsequent
re-installation.  The log has the following:
   Traceback (most recent call last):
     File "<string>", line 604, in <module>
     File "<string>", line 332, in install
     File "<string>", line 15, in write
   AttributeError: 'NoneType' object has no attribute 'write'
   Exception AttributeError: "'NoneType' object has no attribute 'flush'"
in    <__main__.Tee object at 0x00000000040297B8> ignored

What I observed was that the installation program failed immediately after
starting it.  No user interface was displayed and I saw no error messages. 
Windows displayed a dialog box that the program was terminated.  The
WIndows Application Event Log has the following information:

Faulting application name: pywin32-216.win-amd64-py3.2.exe, version:
0.0.0.0, time stamp: 0x4981a90a
Faulting module name: pywin32-216.win-amd64-py3.2.exe, version: 0.0.0.0,
time stamp: 0x4981a90a
Exception code: 0xc0000417
Fault offset: 0x000000000000e668
Faulting process id: 0x35b4
Faulting application start time: 0x01ccd03843d887a5
Faulting application path:
Z:\Downloads\Python\pywin32-216.win-amd64-py3.2.exe
Faulting module path: Z:\Downloads\Python\pywin32-216.win-amd64-py3.2.exe
Report Id: 8d890608-3c2b-11e1-b689-00268313e1f6


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

Comment By: Mark Hammond (mhammond)
Date: 2012-01-11 15:38

Message:
What do you mean "crashes hard"?  Failure should write a
pywin32_postinstall.log to your temp directory if it is just a Python
exception...

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

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

[pywin32-bugs] [ pywin32-Bugs-3472307 ] 64-bit installation fails when using custom folder

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: craigjh (craigjh)
Assigned to: Nobody/Anonymous (nobody)
Summary: 64-bit installation fails when using custom folder

Initial Comment:
(Note:  I am new to Python but an experienced IT guy).  I installed Python 3.2.2 to C:\Program Files\Python32 instead of the default location of C:\Python32.  No apparent problems with the Python installation.  I then tried to install pywin32-216.  The installation program crashes hard every time.  I uninstalled Python and then re-installed in the default location.  pywin32-216 installed without a problem.  Thought I'd report this in case I'm not the only one experiencing a problem.

Just in case it matters, this is on a Windows PC running Windows 7 Professional with all updates.  The hardware is an i7-2600K CPU, ASUS P67 motherboard, 16 Gb of RAM, & 2x2Gb drives with lots of free space.

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

Comment By: craigjh (craigjh)
Date: 2012-01-11 16:13

Message:
Thanks for pointing out where the error log is.  I'm assuming that the
contents were written during the failed installation, not the subsequent
re-installation.  The log has the following:
   Traceback (most recent call last):
     File "<string>", line 604, in <module>
     File "<string>", line 332, in install
     File "<string>", line 15, in write
   AttributeError: 'NoneType' object has no attribute 'write'
   Exception AttributeError: "'NoneType' object has no attribute 'flush'"
in    <__main__.Tee object at 0x00000000040297B8> ignored

What I observed was that the installation program failed immediately after
starting it.  No user interface was displayed and I saw no error messages. 
Windows displayed a dialog box that the program was terminated.  The
WIndows Application Event Log has the following information:

Faulting application name: pywin32-216.win-amd64-py3.2.exe, version:
0.0.0.0, time stamp: 0x4981a90a
Faulting module name: pywin32-216.win-amd64-py3.2.exe, version: 0.0.0.0,
time stamp: 0x4981a90a
Exception code: 0xc0000417
Fault offset: 0x000000000000e668
Faulting process id: 0x35b4
Faulting application start time: 0x01ccd03843d887a5
Faulting application path:
Z:\Downloads\Python\pywin32-216.win-amd64-py3.2.exe
Faulting module path: Z:\Downloads\Python\pywin32-216.win-amd64-py3.2.exe
Report Id: 8d890608-3c2b-11e1-b689-00268313e1f6


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

Comment By: Mark Hammond (mhammond)
Date: 2012-01-11 15:38

Message:
What do you mean "crashes hard"?  Failure should write a
pywin32_postinstall.log to your temp directory if it is just a Python
exception...

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

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

[pywin32-bugs] [ pywin32-Feature Requests-3472494 ] New FILE_ATTRIBUTE Request

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Matt Wood (ybotspawn)
Assigned to: Nobody/Anonymous (nobody)
Summary: New FILE_ATTRIBUTE Request

Initial Comment:
After working with the win32con library, I have found it is missing the file attribute for offline files.  In order to meet my own projects deadline I have found the correct attribute integer and updated my local site package with FILE_ATTRIBUTE_OFFLINE = 5632.  I tested this attribute against archive, offline and hidden files with success.  Please let me know if you have any questions, thanks.

Matt

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-11 15:43

Message:
win32con in the next release will include this constant - but note the
value is 4096 (0x1000) - 5632 is FILE_ATTRIBUTE_OFFLINE |
FILE_ATTRIBUTE_REPARSE_POINT | FILE_ATTRIBUTE_SPARSE_FILE

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

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

[pywin32-bugs] [ pywin32-Bugs-3472307 ] 64-bit installation fails when using custom folder

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: craigjh (craigjh)
Assigned to: Nobody/Anonymous (nobody)
Summary: 64-bit installation fails when using custom folder

Initial Comment:
(Note:  I am new to Python but an experienced IT guy).  I installed Python 3.2.2 to C:\Program Files\Python32 instead of the default location of C:\Python32.  No apparent problems with the Python installation.  I then tried to install pywin32-216.  The installation program crashes hard every time.  I uninstalled Python and then re-installed in the default location.  pywin32-216 installed without a problem.  Thought I'd report this in case I'm not the only one experiencing a problem.

Just in case it matters, this is on a Windows PC running Windows 7 Professional with all updates.  The hardware is an i7-2600K CPU, ASUS P67 motherboard, 16 Gb of RAM, & 2x2Gb drives with lots of free space.

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-11 15:38

Message:
What do you mean "crashes hard"?  Failure should write a
pywin32_postinstall.log to your temp directory if it is just a Python
exception...

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

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

[pywin32-bugs] [ pywin32-Feature Requests-3472494 ] New FILE_ATTRIBUTE Request

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

Feature Requests item #3472494, was opened at 2012-01-11 09:59
Message generated for change (Tracker Item Submitted) made by ybotspawn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3472494&group_id=78018

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

Initial Comment:
After working with the win32con library, I have found it is missing the file attribute for offline files.  In order to meet my own projects deadline I have found the correct attribute integer and updated my local site package with FILE_ATTRIBUTE_OFFLINE = 5632.  I tested this attribute against archive, offline and hidden files with success.  Please let me know if you have any questions, thanks.

Matt

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

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

[pywin32-bugs] [ pywin32-Bugs-3472307 ] 64-bit installation fails when using custom folder

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

Bugs item #3472307, was opened at 2012-01-11 00:51
Message generated for change (Tracker Item Submitted) made by craigjh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3472307&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: craigjh (craigjh)
Assigned to: Nobody/Anonymous (nobody)
Summary: 64-bit installation fails when using custom folder

Initial Comment:
(Note:  I am new to Python but an experienced IT guy).  I installed Python 3.2.2 to C:\Program Files\Python32 instead of the default location of C:\Python32.  No apparent problems with the Python installation.  I then tried to install pywin32-216.  The installation program crashes hard every time.  I uninstalled Python and then re-installed in the default location.  pywin32-216 installed without a problem.  Thought I'd report this in case I'm not the only one experiencing a problem.

Just in case it matters, this is on a Windows PC running Windows 7 Professional with all updates.  The hardware is an i7-2600K CPU, ASUS P67 motherboard, 16 Gb of RAM, & 2x2Gb drives with lots of free space.

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

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

Re: [pywin32-bugs] String limitations on outlook email messages?

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

Note that this mailing list is for messages from the source-force bug 
tracker - please follow up on the pyt...@py... mailing list.

You might have luck if you open the property as a stream - the following 
code is from the spambayes source:

def GetPropFromStream(mapi_object, prop_id):
     try:
         stream = mapi_object.OpenProperty(prop_id,
                                           pythoncom.IID_IStream,
                                           0, 0)
         chunks = []
         while 1:
             chunk = stream.Read(4096)
             if not chunk:
                 break
             chunks.append(chunk)
         return "".join(chunks)
     except pythoncom.com_error, d:
         print "Error getting property", mapiutil.GetPropTagName(prop_id), \
               "from stream:", d
         return ""

HTH,

Mark

On 10/01/2012 12:18 PM, Miller, Mike F wrote:
> I seem to be hitting a problem where the body of outlook email messages
> are truncated at 255-ish characters when extracting the data. I’ve got
> scripts that send email to a known account with a single character
> separated values line of data. Then a python script collects the data
> from each email in the folder:
>
> for indexItem in indexRange:
>
> # collect an email, add to buffer, delete
>
> emailItem = emailItems.Item(indexItem)
>
> buffer.append(emailItem.Body)
>
> print emailItem.Body
>
> But I’m seeing truncation on the emailItem.Body data that is about the
> 255-char point.
>
> Is this a known issue of some kind? I’ve set emailItem.Body to much
> larger strings on a number of occasions, so I know that works.
>
> I can dig further on this, but I thought that checking with the experts
> first would be a good idea J
>
> - Mike Miller
>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
>
>
>
> _______________________________________________
> pywin32-bugs mailing list
> pyw...@li...
> https://lists.sourceforge.net/lists/listinfo/pywin32-bugs

[pywin32-bugs] String limitations on outlook email messages?

[Miller, M. F <mik...@in...>]

I seem to be hitting a problem where the body of outlook email messages are truncated at 255-ish characters when extracting the data. I've got scripts that send email to a known account with a single character separated values line of data. Then a python script collects the data from each email in the folder:

        for indexItem in indexRange:
            # collect an email, add to buffer, delete
            emailItem = emailItems.Item(indexItem)
            buffer.append(emailItem.Body)
            print emailItem.Body

But I'm seeing truncation on the emailItem.Body data that is about the 255-char point.

Is this a known issue of some kind? I've set emailItem.Body to much larger strings on a number of occasions, so I know that works.

I can dig further on this, but I thought that checking with the experts first would be a good idea :)

- Mike Miller

[pywin32-bugs] [ pywin32-Bugs-3026596 ] DLL files should not include manifest

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Farshid Lashkari (farshizzo)
Assigned to: Nobody/Anonymous (nobody)
Summary: DLL files should not include manifest

Initial Comment:
I just installed version 214 for Python 2.7 and noticed the included dll/pyd files have embedded manifests that specify the runtime library. This makes it difficult to distribute the files on machines that don't have the 9.0 runtime library already installed.

All the extension modules that come with the standard library are built without embedded manifests. Shouldn't pywin32 follow the same behavior?

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-07 18:09

Message:
This has been done.

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

Comment By: Farshid Lashkari (farshizzo)
Date: 2010-07-12 11:55

Message:
Thanks for the information! Are there any plans to provide an updated build
soon?

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

Comment By: Christoph Gohlke (cjgohlke)
Date: 2010-07-09 11:19

Message:
A rebuild with the final release of Python 2.7 should take care of that.
However, the pythoncom27.dll and pywintypes27.dll will likely fail to
register during installation and not function as COM server. See
http://bugs.python.org/issue7833. A build with embedded manifests removed
from the PYD (but not from DLL) files is at
http://www.lfd.uci.edu/~gohlke/pythonlibs/#pywin32.

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

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

[pywin32-bugs] [ pywin32-Bugs-3237838 ] cannot insert multi menu item into shell context menu

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: winterTTr (winterttr)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot insert multi menu item into shell context menu

Initial Comment:
I am trying to use pywin32 com to develop a shell extension which will add the menu item to shell context menu.
I do a lot test using win32gui.InsertMenu, but i can not add more than one item to the context menu, I can just add one menu item, the following call to InsertMenu seem to be no effect.

I tried use the context_menu.py under "C:\Python27\Lib\site-packages\win32comext\shell\demos\servers", and add one line like below:

39        items = []
40        items.append("balabala...")

But the result is that, only "balabala..." can be insert into the context menu, so the demo file also fail on my machine.

I think this maybe a problem of pywin32, so I report it and hope you to check.

Environment: windows 7 x86-32bit + python27 + pywin32-216.win32-py2.7.exe


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

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-07 18:06

Message:
For some reason, the fact the demo returns a constant string in
GetCommandString() causes only the first item to be displayed.  I've just
checked in the patch below which makes it work as expected.  Closing this
as invalid as there isn't really a pywin32 bug here.

--- a/com/win32comext/shell/demos/servers/context_menu.py
+++ b/com/win32comext/shell/demos/servers/context_menu.py
@@ -36,7 +36,7 @@
             fname = shell.DragQueryFile(sm.data_handle, 0)
             msg = "&Hello from Python (with '%s' selected)" % fname
         idCmd = idCmdFirst
-        items = []
+        items = ['First Python content menu item']
         if (uFlags & 0x000F) == shellcon.CMF_NORMAL: # Check == here,
since CMF_NORMAL=0
             print "CMF_NORMAL..."
             items.append(msg)
@@ -72,7 +72,11 @@
         win32gui.MessageBox(hwnd, "Hello", "Wow", win32con.MB_OK)

     def GetCommandString(self, cmd, typ):
-        return "Hello from Python!!"
+        # If GetCommandString returns the same string for all items then
+        # the shell seems to ignore all but one.  This is even true in
+        # Win7 etc where there is no status bar (and hence this string
seems
+        # ignored)
+        return "Hello from Python (cmd=%d)!!" % (cmd,)


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

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

[pywin32-bugs] [ pywin32-Bugs-3419597 ] Memory leak on SWbemRefresher

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: M@llon (mallon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak on SWbemRefresher

Initial Comment:
Got a memory leak problem on getting performance data from wmi. For example, when running code below, it can be found in windows task manager that memory usage continue grows.

import win32com.client

com = win32com.client.Dispatch("WbemScripting.SWbemRefresher")
obj = win32com.client.GetObject("winmgmts:\\root\cimv2")

while True:
    com.AddEnum(obj, "Win32_Process")
    com.DeleteAll()


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

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-07 17:06

Message:
We have some leak detection code in the win32com test suite and as the loop
you show is so simple (just 2 method calls), I'm afraid I must conclude the
leak is in WMI itself.  Maybe you could see if a WScript script does the
same thing?

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

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

[pywin32-bugs] [ pywin32-Bugs-3420417 ] PyTime value returned from FindFilesIterator is incorrect

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 6
Private: No
Submitted By: Caleb Constantine (calconst)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyTime value returned from FindFilesIterator is incorrect

Initial Comment:
The PyTime value in the WIN32_FIND_DATA object returned from FindFilesIterator() is incorrect. Say fdata is an instance returned from FindFilesIterator(), then time.localtime(int(fdata[3])) returns the UTC time, not the local time.

To reproduce:
(1) Create a new text file, say C:\test.txt
(2) Observe the modification date.
(3) Run the script on the command line with the path to the file created in (1) as the argument, e.g. pytimebug.py C:\test.txt
(4) Observe local time printed on screen is incorrect; in fact it is the UTC time.

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-07 16:59

Message:
Yeah - like 2831327, I'm reluctant to fix this as it may break people
already working around it and it doesn't exist in py3k.

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

Comment By: Caleb Constantine (calconst)
Date: 2011-10-07 13:09

Message:
It seems the PyTime value (returned from FindFilesIterator()) is offset
from the correct value by the value of the UTC offset. E.g, if I find the
UTC offset, and subtract this from the PyTime before converting to
localtime, I get the correct result:

            utc_offset = (datetime.utcnow() -
datetime.now()).total_seconds()
            ftime = time.localtime(int(finfo[3]) - utc_offset)

Now ftime is correct.


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

Comment By: Caleb Constantine (calconst)
Date: 2011-10-07 12:29

Message:
This bug might be related to bug ID 2831327, "GetProcessTimes converts
wrongly to PyTime".

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

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