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

[pywin32-bugs] [ pywin32-Bugs-3501250 ] Possible bug in win32file.SetFileTime()

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

Bugs item #3501250, was opened at 2012-03-10 10:34
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3501250&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: http://jamercee.myopenid.com/ ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible bug in win32file.SetFileTime()

Initial Comment:
It appears there may be a bug in the win32file.SetFileTime() method (or else there's a big bug in my understanding of how this pywin32 method is intended to work).

We needed the ability to set the ctime,atime,mtime tuple of windows files. The python standard library method os.utime() only works for ctime,mtime. So we turned to pywin32 -- and foudn the SetFileTime seemed to be exactly what we needed.

But it appears win32file.SetFileTime() performs time-zone related transformations that are tripping us up. Specifically, it alters the datetimes it is passed based on the local-system timezone.

As a test, we passed the results from win32file.GetFileTime() win32file.SetFileTime(). In our view, this should have done nothing -- but instead it altered the ctime,atime,mtime of the files by advancing the times. 

I think a quick example can highlight the issue more clearly. Assume the following code is filetest.py:

	import win32file
	hnd = win32file.CreateFile('file.txt',
			win32file.GENERIC_READ | win32file.GENERIC_WRITE,
			0, 
			None, 
			win32file.OPEN_EXISTING, 
			0, 
			None)
	ct, at, mt = win32file.GetFileTime(hnd)
	win32file.SetFileTime(hnd, ct, at, mt)
	hnd.close()

We run it like this:

	C:\> ECHO hi > file.txt
	C:\> DIR file.txt
	03/10/2012  12:55 PM     5 file.txt
               1 File(s)      5 bytes
	
	C:\> PYTHON filetest.py
	C:\> DIR file.txt
	03/10/2012  05:55 PM     5 file.txt
               1 File(s)      5 bytes	

Our local timezone is EST (which today is GMT-5). 

Notice the last-write time is now 5-hours in the future (note: so are ctime, and atime, but for brevity, I've omitted the listing). It looks like SetFileTime() assumed it was passed a collection of times that represented localtime, and performed local -> GMT conversion.

But this is counter to the documentation available with GetFileTime(). According to MSDN, a FILETIME structure (like those returned from GetFileTime()) is:

	"...a 64-bit value representing the number of 
	100-nanosecond intervals since January 1, 1601 (UTC)..."

	http://msdn.microsoft.com/en-us/library/windows/desktop/ms724284(v=vs.85).aspx

After spending some head scratching time on this, we hacked up a quick C version to confirm our understanding was correct about GetFileTime/SetFileTime:

	#include <stdio.h>
	#include <windows.h>
	int main() {
		HANDLE hnd = CreateFile("file.txt",
			GENERIC_READ | GENERIC_WRITE,
			0, 
			NULL, 
			OPEN_EXISTING, 
			0, 
			NULL);
		if (hnd == INVALID_HANDLE_VALUE) {
			printf("error, couldn't open file.txt\n");
			return -1;
			}
		FILETIME ctime, atime, mtime;
		if (GetFileTime(hnd, &ctime, &atime, &mtime) == 0) {
			printf("unable to retrieve filetime(s)");
			return -1;
			}
		if (SetFileTime(hnd, &ctime, &atime, &mtime) == 0) {
			printf("unable to set filetime(s)");
			return -1;
			}
		CloseHandle(hnd);
		return 0;
		}

This program works exactly as we expected and it does not alter any of the the file times.

So we spent some additional time drilling down in the win32file.i swig code.  The SetFileTime() declaration starts on line 718.  On line 740, it begins processing the arguments passed (with code sections for each of the three times).  Here's the one for ctime

	if (!PyWinObject_AsFILETIME(obTimeCreated, &LocalFileTime))
		  return NULL;
	// This sucks!  This code is the only code in pywin32 that
	// blindly converted the result of AsFILETIME to a localtime.
	// That doesn't make sense in a tz-aware datetime world...
	if (PyWinTime_DateTimeCheck(obTimeCreated))
		  TimeCreated = LocalFileTime;
	else
		  LocalFileTimeToFileTime(&LocalFileTime, &TimeCreated);
	lpTimeCreated= &TimeCreated;

(NOTE: we did NOT add the somewhat offensive "sucks" comment. That was left over from whoever edited this code last)

There's quite a bit of moving parts at this level of depth in the pywin32 code -- but it would appear to our superficial understanding that the pywin32 code at this point is converting the time passed to localtime.  Is that correct? 

Has anyone else encountered a problem with win32file.SetFileTime() -- or are we just completely off our nut here?

 
Our test setup:
	Windows 7 (64-bit)
	Running Python 2.7.2 (32-bit)
	pywin32-217
	
The filesystem we are writting to is NTFS



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

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

[pywin32-bugs] [ pywin32-Bugs-3496749 ] missing stdout.encoding

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

Bugs item #3496749, was opened at 2012-03-04 02:07
Message generated for change (Tracker Item Submitted) made by redoute
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3496749&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: Redoute (redoute)
Assigned to: Nobody/Anonymous (nobody)
Summary: missing stdout.encoding

Initial Comment:
In PythonWin stdout has no attribute encoding. Printing non-ascii chars mysteriously succeeds, but this is not transparent.
Example:

[PythonWin shell]
>>> from sys import stdout
>>> print 'stdout.encoding: ', stdout.encoding
stdout.encoding: Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Programme\Python27\Lib\site-packages\pythonwin\pywin\mfc\object.py", line 18, in __getattr__
    return getattr(o, attr)
AttributeError: 'PyCCtrlView' object has no attribute 'encoding'
>>> print u'äöüß'
 äöüß
[/PythonWin shell]

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

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

[pywin32-bugs] [ pywin32-Bugs-2905909 ] assert sys.modules[modname] is old_mod error in pywintypes

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

Bugs item #2905909, was opened at 2009-11-30 03:10
Message generated for change (Comment added) made by honyczek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2905909&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: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: assert sys.modules[modname] is old_mod error in pywintypes

Initial Comment:
When running Apache+Mod Python (Python 2.4), I was getting this error - 

[Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] Traceback (most recent call last):
[Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1]   File "C:\\Python24\\Lib\\site-packages\\mod_python\\importer.py", line 1537, in HandlerDispatch\n    default=default_handler, arg=req, silent=hlist.silent)
[Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1]   File "C:\\Python24\\Lib\\site-packages\\mod_python\\importer.py", line 1229, in _process_target\n    result = _execute_target(config, req, object, arg)
[Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1]   File "C:\\Python24\\Lib\\site-packages\\mod_python\\importer.py", line 1128, in _execute_target\n    result = object(arg)
[Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1]   File "c:\\python24\\Lib\\site-packages\\django\\core\\handlers\\modpython.py", line 228, in handler\n    return ModPythonHandler()(req)
[Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1]   File "c:\\python24\\Lib\\site-packages\\django\\core\\handlers\\modpython.py", line 201, in __call__\n    response = self.get_response(request)
[Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1]   File "c:\\python24\\Lib\\site-packages\\django\\core\\handlers\\base.py", line 73, in get_response\n    response = middleware_method(request)
[Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1]   File "c:\\python24\\Lib\\site-packages\\django\\contrib\\sessions\\middleware.py", line 10, in process_request\n    engine = import_module(settings.SESSION_ENGINE)
[Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1]   File "c:\\python24\\Lib\\site-packages\\django\\utils\\importlib.py", line 35, in import_module\n    __import__(name)
[Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1]   File "c:\\python24\\Lib\\site-packages\\django\\contrib\\sessions\\backends\\db.py", line 2, in ?\n    from django.contrib.sessions.models import Session
[Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1]   File "c:\\python24\\Lib\\site-packages\\django\\contrib\\sessions\\models.py", line 4, in ?\n    from django.db import models
[Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1]   File "c:\\python24\\Lib\\site-packages\\django\\db\\models\\__init__.py", line 12, in ?\n    from django.db.models.fields.files import FileField, ImageField
[Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1]   File "c:\\python24\\Lib\\site-packages\\django\\db\\models\\fields\\files.py", line 8, in ?\n    from django.core.files.storage import default_storage
[Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1]   File "c:\\python24\\Lib\\site-packages\\django\\core\\files\\storage.py", line 7, in ?\n    from django.core.files import locks, File
[Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1]   File "c:\\python24\\Lib\\site-packages\\django\\core\\files\\locks.py", line 25, in ?\n    import pywintypes
[Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1]   File "C:\\Python24\\Lib\\site-packages\\win32\\lib\\pywintypes.py", line 124, in ?\n    __import_pywin32_system_module__("pywintypes", globals())
[Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1]   File "C:\\Python24\\Lib\\site-packages\\win32\\lib\\pywintypes.py", line 114, in __import_pywin32_system_module__\n    assert sys.modules[modname] is old_mod
[Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] AssertionError

With PythonDebug = On, assert took effect. I removed it and it worked without any issues.
I found that another user - <a href="http://markmail.org/message/hqnf6obaillzspxj#query:assert%20sys.modules[modname]%20is%20old_mod+page:1+mid:nahkqunchycwqtd4+state:results">here</a> also has the same issue.
He solved it by going back a version.

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

Comment By: honyczek (honyczek)
Date: 2012-03-02 00:42

Message:
I attached, what is in old_mod and mod variables in new bug report at
https://sourceforge.net/support/tracker.php?aid=3496224

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

Comment By: ChaosKCW (chaoskcw)
Date: 2010-12-06 03:43

Message:
Hi,

I am experiencing this issue as well, are there any solutions? 

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

Comment By: Ian Rolfe (slothie2)
Date: 2010-04-27 08:11

Message:
I "got this working" by just commenting out the 2 asserts and replacing
them with a 'pass'

I put some debugs in, it seems that the same module is being used, but
different instances:

[Tue Apr 27 15:49:31 2010] [error]
C:\\Python26\\lib\\site-packages\\MySQLdb\\__init__.py:34:
DeprecationWarning: the sets module is deprecated
[Tue Apr 27 15:49:31 2010] [error] from sets import ImmutableSet
[Tue Apr 27 15:49:31 2010] [error] Version is < 3
[Tue Apr 27 15:49:31 2010] [error] sys.modules = <module 'pywintypes' from
'C:\\Windows\\system32\\pywintypes26.dll'> id=50175152
file=C:\\Windows\\system32\\pywintypes26.dll
[Tue Apr 27 15:49:31 2010] [error] mod = <module 'pywintypes' from
'C:\\Windows\\system32\\pywintypes26.dll'> id=50175152
file=C:\\Windows\\system32\\pywintypes26.dll
[Tue Apr 27 15:49:31 2010] [error] old_mod = <module 'pywintypes' from
'C:\\Windows\\system32\\pywintypes26.dll'> id=50175152
file=C:\\Windows\\system32\\pywintypes26.dll
[Tue Apr 27 15:49:34 2010] [error] [client 127.0.0.1] File does not exist:
C:/Program Files/Apache Software
Foundation/Apache2.2/htdocs/san/media/css/san.css, referer:
http://localhost/san/letters/
[Tue Apr 27 15:53:57 2010] [error]
C:\\Python26\\lib\\site-packages\\MySQLdb\\__init__.py:34:
DeprecationWarning: the sets module is deprecated
[Tue Apr 27 15:53:57 2010] [error] from sets import ImmutableSet
[Tue Apr 27 15:53:57 2010] [error] Version is < 3
[Tue Apr 27 15:53:57 2010] [error] sys.modules = <module 'pywintypes' from
'C:\\Windows\\system32\\pywintypes26.dll'> id=50175152
file=C:\\Windows\\system32\\pywintypes26.dll
[Tue Apr 27 15:53:57 2010] [error] mod = <module 'pywintypes' from
'C:\\Windows\\system32\\pywintypes26.dll'> id=61248048
file=C:\\Windows\\system32\\pywintypes26.dll
[Tue Apr 27 15:53:57 2010] [error] old_mod = <module 'pywintypes' from
'C:\\Windows\\system32\\pywintypes26.dll'> id=61248048
file=C:\\Windows\\system32\\pywintypes26.dll

Note that the 1st request was OK but the second had a different instance of
the same dll. 

Is this likely to cause problems?

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

Comment By: Steve McCusker (stevemccusker)
Date: 2009-12-10 19:10

Message:
I have just come across this problem. I am using Apache 2.2, Django 1.1,
Python 2.6.2 and mod_wsgi (mod_wsgi-win32-ap22py26-2.5.so) on Win XP Pro
(SP3). It allworked fine until PayPal POSTed a notification. This was , of
course, from a different IP address from the previous GETs and POSTs. It
caused the above error. After I read this bug report I simple commented out
the two Assert statements and it then seemed to work OK.

I did do a debug dump from pywintypes just before the assert statements
just using the python unicode() function on the two modules (old_mod and
mod) and they looked the same from that. 

Changing back to the older version as reported above did not help.

Cheers

Steve McCusker

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

Comment By: Mark Hammond (mhammond)
Date: 2009-11-30 15:25

Message:
My concern is that assertion may be indicating pywintypesxx.dll has been
loaded twice by the process, causing subtle problems with the types.  It
would be interesting to know what the __file__ attribute is on the 2
objects.

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

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

[pywin32-bugs] [ pywin32-Bugs-3496224 ] AssertionError: assert sys.modules[modname] is old_mod

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

Bugs item #3496224, was opened at 2012-03-02 00:38
Message generated for change (Tracker Item Submitted) made by honyczek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3496224&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: honyczek (honyczek)
Assigned to: Nobody/Anonymous (nobody)
Summary: AssertionError: assert sys.modules[modname] is old_mod

Initial Comment:
This problem is opened at ID #2905909.

I want to attach file, which tells what is in old_mod and mod variables.

This problem has been described by me at: http://stackoverflow.com/questions/9479239/running-two-django-apps-on-apache-with-mod-auth-sspi-and-mod-wsgi

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

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

[pywin32-bugs] [ pywin32-Bugs-896502 ] key mapping fails on non-us-kb for calltips

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Norbert Ferchen (nferchen)
Assigned to: Nobody/Anonymous (nobody)
Summary: key mapping fails on non-us-kb for calltips

Initial Comment:
on an german keyboard you will not get the calltip by
pressing the opening bracket, but on pressing the
closing bracket instead.

It seems, that the key mapping doesn't recognise the
keyboard layout. On the german kbd the brackes or on
the keys 8 and 9. By replacing the "Shift-(" by
"Shift-8" - as an workaround - the mapping will work.

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

Comment By: https://www.google.com/accounts ()
Date: 2012-02-29 03:46

Message:
rev d668dc3f1549 breaking pythonwin.exe

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

Comment By: Mark Hammond (mhammond)
Date: 2010-10-27 18:56

Message:
After 6 years I've checked a fix in that works for me

Checking in CHANGES.txt;
new revision: 1.65; previous revision: 1.64
Checking in Pythonwin/pywin/default.cfg;
new revision: 1.11; previous revision: 1.10
Checking in Pythonwin/pywin/scintilla/bindings.py;
new revision: 1.10; previous revision: 1.9
Checking in Pythonwin/pywin/scintilla/config.py;
new revision: 1.11; previous revision: 1.10
Checking in Pythonwin/pywin/scintilla/keycodes.py;
new revision: 1.8; previous revision: 1.7


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

Comment By: Oleg Noga (oleg_noga)
Date: 2005-09-21 07:46

Message:
Logged In: YES 
user_id=551440

Same bug with dot character mapping
pressing dot key allways produces dot character in editor
but in non-us keyboard locales it is not dot but letter :(
here is the a patch for pythonwin\pywin\scintilla\view.py 
KeyDotEvent function. 
patch needs ctypes package to work
http://starship.python.net/crew/theller/ctypes/
------------------------------
	def KeyDotEvent(self, event):
		
		# begin of patch
		try:
			import ctypes
		except ImportError:
			pass
		else:
			if 
(ctypes.windll.user32.GetKeyboardLayout(ctypes.c_int(0))
				& 0xFFFF != 
0x0409):
				return 1
		# end of patch

		self.SCIAddText('.')
		if self.bAutoCompleteAttributes:
			self._AutoComplete()



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

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

[pywin32-bugs] [ pywin32-Bugs-3495033 ] Incorrect Handling of adGUID

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

Bugs item #3495033, was opened at 2012-02-27 08:06
Message generated for change (Comment added) made by alkamo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3495033&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: adodbapi
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Allan (alkamo)
Assigned to: Vernon Cole (kf7xm)
Summary: Incorrect Handling of adGUID

Initial Comment:
When a GUID value is written to a SQL Server database, it is truncated to 16 characters. This means that when you try to write "{71A4F49E-39F3-42B1-A41E-48FF154996E6}", only "{71A4F49E-39F3-4" is actually passed to the database (which, naturally, raises an error). This seems that it may be an issue with the ADO interface: when the parameters are refreshed from the "ADODB.Command" object, the size is returned as 16 and that is used to format the parameters later.

I have worked around this by creating changing the _buildADOparameterList procedure of the cursor class to set the size of UUID fields after the parameter list is refreshed, as demonstrated in the attached code. The size is set to 38, to account for the 32-character UUID with 2 curly braces and four dashes, which is the format returned by a SQL Server database.

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

>Comment By: Allan (alkamo)
Date: 2012-02-28 07:53

Message:
I've uploaded a zip file containing a revised unit test that will test
GUIDs on SQL Server. I had to make a small change to adodbapi.py to make
the unit test work (it's also included in the archive).

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

Comment By: Allan (alkamo)
Date: 2012-02-28 05:49

Message:
Vernon's recommendation of moving adGUID from adoStringTypes to
adoRemainingTypes resolves this issue.

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

Comment By: Vernon Cole (kf7xm)
Date: 2012-02-27 19:48

Message:
It seems that the solution might be as simple as changing the definition of
how adGUID is handled.
Around line 1237, change
adoStringTypes=(adc.adBSTR,adc.adChar,adc.adLongVarChar,adc.adLongVarWChar,
                adc.adVarChar,adc.adVarWChar,adc.adWChar,adc.adGUID)
to
adoStringTypes=(adc.adBSTR,adc.adChar,adc.adLongVarChar,adc.adLongVarWChar,
                adc.adVarChar,adc.adVarWChar,adc.adWChar)
and near line 1241 change
adoRemainingTypes=(adc.adEmpty,adc.adIDispatch,adc.adIUnknown,
                   adc.adPropVariant,adc.adArray,adc.adUserDefined,
                   adc.adVariant)
to
adoRemainingTypes=(adc.adEmpty,adc.adIDispatch,adc.adIUnknown,
                   adc.adPropVariant,adc.adArray,adc.adUserDefined,
                   adc.adVariant,adc.adGUID)
--
Hopefully that will avoid explicit code in _configure_parameter which
truncates some strings.
Please try it and tell me if it works.  I have never mucked with GUIDs so
have no idea how to create one to test with.  [Feel free to add a test to
the suite.]
--
Vernon


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

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

[pywin32-bugs] [ pywin32-Bugs-3495033 ] Incorrect Handling of adGUID

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

Bugs item #3495033, was opened at 2012-02-27 08:06
Message generated for change (Comment added) made by alkamo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3495033&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: adodbapi
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Allan (alkamo)
Assigned to: Vernon Cole (kf7xm)
Summary: Incorrect Handling of adGUID

Initial Comment:
When a GUID value is written to a SQL Server database, it is truncated to 16 characters. This means that when you try to write "{71A4F49E-39F3-42B1-A41E-48FF154996E6}", only "{71A4F49E-39F3-4" is actually passed to the database (which, naturally, raises an error). This seems that it may be an issue with the ADO interface: when the parameters are refreshed from the "ADODB.Command" object, the size is returned as 16 and that is used to format the parameters later.

I have worked around this by creating changing the _buildADOparameterList procedure of the cursor class to set the size of UUID fields after the parameter list is refreshed, as demonstrated in the attached code. The size is set to 38, to account for the 32-character UUID with 2 curly braces and four dashes, which is the format returned by a SQL Server database.

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

>Comment By: Allan (alkamo)
Date: 2012-02-28 05:49

Message:
Vernon's recommendation of moving adGUID from adoStringTypes to
adoRemainingTypes resolves this issue.

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

Comment By: Vernon Cole (kf7xm)
Date: 2012-02-27 19:48

Message:
It seems that the solution might be as simple as changing the definition of
how adGUID is handled.
Around line 1237, change
adoStringTypes=(adc.adBSTR,adc.adChar,adc.adLongVarChar,adc.adLongVarWChar,
                adc.adVarChar,adc.adVarWChar,adc.adWChar,adc.adGUID)
to
adoStringTypes=(adc.adBSTR,adc.adChar,adc.adLongVarChar,adc.adLongVarWChar,
                adc.adVarChar,adc.adVarWChar,adc.adWChar)
and near line 1241 change
adoRemainingTypes=(adc.adEmpty,adc.adIDispatch,adc.adIUnknown,
                   adc.adPropVariant,adc.adArray,adc.adUserDefined,
                   adc.adVariant)
to
adoRemainingTypes=(adc.adEmpty,adc.adIDispatch,adc.adIUnknown,
                   adc.adPropVariant,adc.adArray,adc.adUserDefined,
                   adc.adVariant,adc.adGUID)
--
Hopefully that will avoid explicit code in _configure_parameter which
truncates some strings.
Please try it and tell me if it works.  I have never mucked with GUIDs so
have no idea how to create one to test with.  [Feel free to add a test to
the suite.]
--
Vernon


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

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

[pywin32-bugs] [ pywin32-Bugs-3495033 ] Incorrect Handling of adGUID

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

Bugs item #3495033, was opened at 2012-02-27 08:06
Message generated for change (Comment added) made by kf7xm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3495033&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: adodbapi
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Allan (alkamo)
Assigned to: Vernon Cole (kf7xm)
Summary: Incorrect Handling of adGUID

Initial Comment:
When a GUID value is written to a SQL Server database, it is truncated to 16 characters. This means that when you try to write "{71A4F49E-39F3-42B1-A41E-48FF154996E6}", only "{71A4F49E-39F3-4" is actually passed to the database (which, naturally, raises an error). This seems that it may be an issue with the ADO interface: when the parameters are refreshed from the "ADODB.Command" object, the size is returned as 16 and that is used to format the parameters later.

I have worked around this by creating changing the _buildADOparameterList procedure of the cursor class to set the size of UUID fields after the parameter list is refreshed, as demonstrated in the attached code. The size is set to 38, to account for the 32-character UUID with 2 curly braces and four dashes, which is the format returned by a SQL Server database.

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

>Comment By: Vernon Cole (kf7xm)
Date: 2012-02-27 19:48

Message:
It seems that the solution might be as simple as changing the definition of
how adGUID is handled.
Around line 1237, change
adoStringTypes=(adc.adBSTR,adc.adChar,adc.adLongVarChar,adc.adLongVarWChar,
                adc.adVarChar,adc.adVarWChar,adc.adWChar,adc.adGUID)
to
adoStringTypes=(adc.adBSTR,adc.adChar,adc.adLongVarChar,adc.adLongVarWChar,
                adc.adVarChar,adc.adVarWChar,adc.adWChar)
and near line 1241 change
adoRemainingTypes=(adc.adEmpty,adc.adIDispatch,adc.adIUnknown,
                   adc.adPropVariant,adc.adArray,adc.adUserDefined,
                   adc.adVariant)
to
adoRemainingTypes=(adc.adEmpty,adc.adIDispatch,adc.adIUnknown,
                   adc.adPropVariant,adc.adArray,adc.adUserDefined,
                   adc.adVariant,adc.adGUID)
--
Hopefully that will avoid explicit code in _configure_parameter which
truncates some strings.
Please try it and tell me if it works.  I have never mucked with GUIDs so
have no idea how to create one to test with.  [Feel free to add a test to
the suite.]
--
Vernon


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

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

[pywin32-bugs] [ pywin32-Bugs-3495033 ] Incorrect Handling of adGUID

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

Bugs item #3495033, was opened at 2012-02-27 08:06
Message generated for change (Tracker Item Submitted) made by alkamo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3495033&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: adodbapi
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Allan (alkamo)
Assigned to: Vernon Cole (kf7xm)
Summary: Incorrect Handling of adGUID

Initial Comment:
When a GUID value is written to a SQL Server database, it is truncated to 16 characters. This means that when you try to write "{71A4F49E-39F3-42B1-A41E-48FF154996E6}", only "{71A4F49E-39F3-4" is actually passed to the database (which, naturally, raises an error). This seems that it may be an issue with the ADO interface: when the parameters are refreshed from the "ADODB.Command" object, the size is returned as 16 and that is used to format the parameters later.

I have worked around this by creating changing the _buildADOparameterList procedure of the cursor class to set the size of UUID fields after the parameter list is refreshed, as demonstrated in the attached code. The size is set to 38, to account for the 32-character UUID with 2 curly braces and four dashes, which is the format returned by a SQL Server database.

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

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

[pywin32-bugs] [ pywin32-Feature Requests-3488154 ] QueryServiceConfig() not exist

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

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

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

Initial Comment:
Please implement method QueryServiceConfig() method to win32serviceutil library.
I have example:
		>>> scm = win32service.OpenSCManager(None, None, win32service.SC_QUERY_CONFIG)
		>>> svc = win32service.OpenService(scm, "TestQueueMgrSvc", win32service.SC_QUERY_CONFIG)
		>>> svccfg = win32service.QueryServiceConfig(svc)
		>>> svccfg
Thanks,

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-02-16 14:08

Message:
QueryServiceConfig is in win32service.  If you mean it should be exposed in
win32serviceutil then you probably need to provide a patch to demonstrate
what it should do.

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

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

[pywin32-bugs] [ pywin32-Bugs-3488187 ] Starts with Traceback error

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

Bugs item #3488187, was opened at 2012-02-16 03:50
Message generated for change (Tracker Item Submitted) made by noamroze
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3488187&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: Griffin (noamroze)
Assigned to: Nobody/Anonymous (nobody)
Summary: Starts with Traceback error 

Initial Comment:
When I open Pythonwin, I have Traceback error, and alot of problematic files. I tried uninstall, delete, and install again, but it didn't work.
I've attached print screen.
Appreciate any help

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

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

[pywin32-bugs] [ pywin32-Feature Requests-3488154 ] QueryServiceConfig() not exist

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

Feature Requests item #3488154, was opened at 2012-02-16 01:55
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3488154&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: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: QueryServiceConfig() not exist

Initial Comment:
Please implement method QueryServiceConfig() method to win32serviceutil library.
I have example:
		>>> scm = win32service.OpenSCManager(None, None, win32service.SC_QUERY_CONFIG)
		>>> svc = win32service.OpenService(scm, "TestQueueMgrSvc", win32service.SC_QUERY_CONFIG)
		>>> svccfg = win32service.QueryServiceConfig(svc)
		>>> svccfg
Thanks,

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

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

[pywin32-bugs] [ pywin32-Bugs-3314345 ] dde module initialization failing

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

Bugs item #3314345, was opened at 2011-06-09 11:00
Message generated for change (Comment added) made by eltinou
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3314345&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: ajs (ajssf)
Assigned to: Nobody/Anonymous (nobody)
Summary: dde module initialization failing

Initial Comment:
If I import the dde module after importing the win32ui module, the error generated tells me to import the win32ui module.

I get the same behaviour for builds 215 and 216

Below is a copy of a real session

    C:\>c:\Python31\python.exe
    Python 3.1.3 (r313:86834, Nov 27 2010, 17:20:37) [MSC v.1500 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import win32ui
    >>> import dde
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ImportError: This must be an MFC application - try loading win32ui first
    >>> win32ui.GetApp()
    object 'PyCWinApp' - assoc is 000000000247D150, vi=<None>, notify=0,ch/u=0/0
    >>> 

Looking at the source code, the import error from the dde module appears to be generated because there is no CWinApp being created
by the win32ui import, but the call to win32ui.GetApp() seems to show that there is one created.



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

Comment By: Étienne Labaume (eltinou)
Date: 2012-02-13 08:33

Message:
I have seen the same behaviour as [jonvspython] on build 215 and 216.
Following the latest release, I have made a comparison of build 214 and
build 217 on the platforms that I have:

Windows 7 (64 bit)
 - build 217
    * Python 2.7.2 win32: "import dde" returns "ImportError: This must be
an MFC application - try 'import win32ui' first", but even doing so fails
    * Python 2.7.2 amd64: "import dde" returns "ImportError: This must be
an MFC application - try 'import win32ui' first", but even doing so fails
    * Python 3.2.2 win32: "import dde" returns "ImportError: This must be
an MFC application - try 'import win32ui' first", but even doing so fails
    * Python 3.2.2 amd64: "import dde" returns "ImportError: This must be
an MFC application - try 'import win32ui' first", but even doing so fails
 - build 214
    * Python 2.7.2 win32: OK
    * Python 2.7.2 amd64: import dde returns "No module named dde".
    * Python 3.1.4 win32: OK
    * Python 3.1.4 amd64: import dde returns "No module named dde".

Windows 7 (32 bit)
 - build 217
    * Python 2.7.2 win32: "import dde" returns "ImportError: This must be
an MFC application - try 'import win32ui' first", but even doing so fails
    * Python 3.2.2 win32: "import dde" returns "ImportError: This must be
an MFC application - try 'import win32ui' first", but even doing so fails
 - build 214
    * Python 2.7.2 win32: OK
    * Python 3.1.4 win32: OK

Mark, please let me know if you need someone to test anything regarding
this issue.

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

Comment By: kxroberto (kxroberto)
Date: 2011-11-08 01:36

Message:
Unlike in build 216, pywin 212's dde.pyd here seems to have the same
embedded manifest as win32ui.pyd.  The problem is not with win32uiole.pyd. 

So I guess from 214 -> 215 a sort of bug entered into the build files
regarding the dde.pyd lacking a embedded manifest.

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

Comment By: kxroberto (kxroberto)
Date: 2011-11-06 13:33

Message:
I have the same problem "ImportError: This must be an MFC application - try
loading win32ui first" with py2.6 / pywin 216 ,  when the application
starts through python.exe or pythonw.exe.

The problem is not in the IDE when started through Pythonwin.exe !

When I start the IDE through python(w).exe and the script below, then the
problem is there in the IDE as well.

Nothing changes when I copy&use python(w).exe  next to Pythonwin.exe (and
the mfc dll's there), or when I copy&use Pythonwin.exe at C:\Python :  
Pythonwin.exe always allows dde. python(w).exe not.

What does Pythonwin.exe do/have special? What can be done to get dde
loading without Pythonwin.exe?


--
#######################################################################################
## 
## Fires up the PythonWin framework via normal python(w).exe (1.5.2 tested)
## 
#######################################################################################

import sys, win32ui, win32api, win32con
wc=win32con

# store original console stdout/in 
constdout=sys.constdout=sys.stdout
constdin=sys.constdin=sys.stdin

def do(*paths):
    import pywin.framework.startup
    from pywin.framework.intpyapp import thisApp
    thisApp.MakeExistingDDEConnection = lambda:None # we can have more
Pythonwin's this way
    app=thisApp
    app.InitInstance()
    try: win32api.SetConsoleTitle('PyWin Console')
    except: pass
    #for path in args:
    #    app.OpenDocumentFile(path)
    app.Run()

def do2():
    import pywin.framework.startup
    from pywin.framework.intpyapp import thisApp
    thisApp.MakeExistingDDEConnection = lambda:None        
    app=self=thisApp
    win32ui.LoadStdProfileSettings=lambda x:None
    app.InitInstance()
    app.frame.ShowWindow(wc.SW_SHOW)
    try: win32api.SetConsoleTitle('PyWin Console')
    except: pass
    #app.OpenDocumentFile("hello.py")
    #app.Run()

def do3():
    import thread
    thread.start_new_thread( do2, () )

if __name__=='__main__' :
    try: del sys.argv[0] # prevent this script from being loaded into the
editor
    except: pass
    do()


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

Comment By: chrisparks (chrisparks)
Date: 2011-10-19 11:10

Message:
Thanks for the tip jonvspython, I could not get dde to import from the
bundle that came with pythonxy 2.7.2 (build 216 of pywin32).  

Dependency walker showed MSVCR90.DLL was missing from the distribution.  I
installed the missing DLL but dde still failed to import.  

I then installed build 214 of pywin32 and it is now working.  Something
broke dde on the way to build 216.


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

Comment By: jon vs. python (jonvspython)
Date: 2011-07-06 03:33

Message:
I had the same problem with Python 2.7.2 (default, Jun 12 2011, 15:08:59)
[MSC v.1500 32 bit (Intel)] on win32 and build 216.

The problem did not arise with Python 2.7.2 (default, Jun 12 2011,
15:08:59) [MSC v.1500 32 bit (Intel)] on win32 and build 214, though.

Hope it helps.

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

Comment By: Mark Hammond (mhammond)
Date: 2011-06-09 16:27

Message:
I'll fix the message later, but I don't think I will be able to fix the
behaviour.

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

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

[pywin32-bugs] [ pywin32-Bugs-3486836 ] Installation of pywin32-216.win32-py2.7.exe fails on Win7

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

Bugs item #3486836, was opened at 2012-02-11 12:26
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3486836&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: Frank Niessink (fniessink)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installation of pywin32-216.win32-py2.7.exe fails on Win7

Initial Comment:
Hi, 

I have Python 2.7 (32 bits) installed on Windows 7. I downloaded the pywin32-216.win32-py2.7.exe installer and started it. The installer shows the first Wizard page (This wizard will install pywin32 ...). I click Next. The wizard says: "Python 2.7 is required for this package. Select installation to use:". It shows one installation: "Python Version 2.7 (found in registry)". I click Next. Wizard says it "Ready to install". I click Next. Wizard stops responding and Windows tells me "pywin32-216.win32-py2.7.exe stopped working. A problem occurred causing the program to stop working correctly." The only option is to close the program. 

Thanks, Frank

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-02-12 14:04

Message:
The root bug is captured in http://bugs.python.org/issue13038 - I'll close
this as there is nothing pywin32 can do about it (even though it definitely
sucks!)

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

Comment By: Frank Niessink (fniessink)
Date: 2012-02-12 06:14

Message:
Hi Mark,

Running the installer as administrator does indeed help and successfully
installs pywin32. It would be nice if the installer gave a permission
denied error message instead of crashing. Should I report a bug with the
installer? Which one is it?

Thanks, Frank

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

Comment By: Mark Hammond (mhammond)
Date: 2012-02-11 22:25

Message:
I've seen this happen if the python directory isn't writable by the user
installing pywin32 - is that possible?

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

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

[pywin32-bugs] [ pywin32-Bugs-2065850 ] Some typelibs have non integer versions

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: Some typelibs have non integer versions

Initial Comment:
From python-win32:
"""
When using the makepy utility I noticed it used to crash out with the following traceback:

line 148, in SelectTlb
    i.major = int(i.major, 16)
ValueError: invalid literal for int() with base 16: 'CS2'
...
Most likely this (last line of traceback) refers to the version number of Adobe Photoshop Creative Suite 2.
"""
There is some existing confusion between hex and int in that file, but it doesn't expect strings!  Note that GetTypeLibInfo() etc all use integers for the version info - which probably means the typelib can't be directly loaded - but that isn't really our problem - we shouldn't die.

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

Comment By: Brenda Trist (tristb)
Date: 2012-02-12 07:04

Message:
I know I have run COM Makepy Utility before because it is in my
installation notes for installing/upgrading Python onto my system.  I have
been using Python since version 2.   COM Makepy Utility was inserted as one
of my procedures when I started using win32com in order to edit WORD and
EXCEL documents.  Which is when I upgrade from 2.3 to 2.5 a few years ago. 
So it has been awhile since an upgrade at my end.   When I was using
Python2.5 I was also using pywin32-210.win32-py2.5.  With Python2.6 I am
trying to use pywin32-216.win32-py2.6.  Found pywin32-210.win32-py2.6.exe. 
Downloaded and installed.  That other error went away.  so I can at least
build the COM Makepy Utility it seems.  So there is something with 216
build of pywin32.  So far I only receive a warning when I run COM Makepy
Utility

PythonWin 2.6.7 (r267:88850, Jun 27 2011, 13:56:33) [MSC v.1500 32 bit
(Intel)] on win32.
Portions Copyright 1994-2006 Mark Hammond - see 'Help/About PythonWin' for
further copyright information.
>>> C:\Python26\Lib\site-packages\pythonwin\pywin\framework\intpyapp.py:87:
DeprecationWarning: catching of string exceptions is deprecated
  except (win32ui.error, AttributeError):

Hope this sheds some light.
Thank you

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

Comment By: Mark Hammond (mhammond)
Date: 2012-02-10 18:12

Message:
So yeah, you do have the same root problem, but I suspect it would also
happen in Python 2.5.  Are you sure you tried to generate a makepy stub in
Python 2.5?  It may be that you can use the COM object without a makepy
stub.

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

Comment By: Brenda Trist (tristb)
Date: 2012-02-10 05:58

Message:
When I run COM Makepy utility from PythonWin (version 2.6.7) I get the
following message which I did not get when I was using PythonWin 2.5.

Failed to execute command:
from win32com.client import makepy;makepy.main()
Traceback (most recent call last):
  File
"C:\Python26\Lib\site-packages\pythonwin\pywin\framework\toolmenu.py", line
103, in HandleToolCommand
    exec "%s\n" % pyCmd
  File "<string>", line 1, in <module>
  File "C:\Python26\lib\site-packages\win32com\client\makepy.py", line 362,
in main
    rc = selecttlb.SelectTlb()
  File "C:\Python26\lib\site-packages\win32com\client\selecttlb.py", line
150, in SelectTlb
    i.major = int(i.major, 16)
ValueError: invalid literal for int() with base 16: 'CS2'

I got this same message when I tried to upgrade to Python2.7.  Gave up and
went back to Python 2.5.  Now I really need to upgrade because the
nitro-nitf I am trying to use was compiled with Python2.6.  There is a good
chance that I do not have something set up correctly I am just unsure where
to look.

Thank you.

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

Comment By: Mark Hammond (mhammond)
Date: 2012-02-09 14:40

Message:
> My question is why would Python2.5 have no problem but Python2.6 and up
does.

Are you sure it is the same problem?  The original problem is that pywin32
assumes a typelib version is an integer, but in some cases it is a string
that can't be converted to an integer.   Also, the original problem must
have been pre 2.6 as 2.6 wasn't out then.  Therefore, I'd be really
surprised if this is the same issue you are facing.  Can you give a few
more details?

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

Comment By: Brenda Trist (tristb)
Date: 2012-02-09 05:14

Message:
I am having the same issue as the person who brought this up a few years
ago.  I noticed it was closed recently with no resolution.  You mention in
your comments that it has to do with the original typelib.  My question is
why would Python2.5 have no problem but Python2.6 and up does.  I would
like to upgrade because the nitro-nitf has been compiled with Python2.6 but
yet I still need to be able to run COM Makepy Utility to obtain the Excel
and Word libraries of wincom32.  Is there anything I can do to work around
this problem.  Thank you.

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

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

Message:
I'm rejecting this as it seems limited to just the original typelib and
hasn't since been reported again.

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

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

[pywin32-bugs] [ pywin32-Bugs-3486836 ] Installation of pywin32-216.win32-py2.7.exe fails on Win7

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

Bugs item #3486836, was opened at 2012-02-11 12:26
Message generated for change (Comment added) made by fniessink
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3486836&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: Frank Niessink (fniessink)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installation of pywin32-216.win32-py2.7.exe fails on Win7

Initial Comment:
Hi, 

I have Python 2.7 (32 bits) installed on Windows 7. I downloaded the pywin32-216.win32-py2.7.exe installer and started it. The installer shows the first Wizard page (This wizard will install pywin32 ...). I click Next. The wizard says: "Python 2.7 is required for this package. Select installation to use:". It shows one installation: "Python Version 2.7 (found in registry)". I click Next. Wizard says it "Ready to install". I click Next. Wizard stops responding and Windows tells me "pywin32-216.win32-py2.7.exe stopped working. A problem occurred causing the program to stop working correctly." The only option is to close the program. 

Thanks, Frank

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

>Comment By: Frank Niessink (fniessink)
Date: 2012-02-12 06:14

Message:
Hi Mark,

Running the installer as administrator does indeed help and successfully
installs pywin32. It would be nice if the installer gave a permission
denied error message instead of crashing. Should I report a bug with the
installer? Which one is it?

Thanks, Frank

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

Comment By: Mark Hammond (mhammond)
Date: 2012-02-11 22:25

Message:
I've seen this happen if the python directory isn't writable by the user
installing pywin32 - is that possible?

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

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

[pywin32-bugs] [ pywin32-Bugs-3486836 ] Installation of pywin32-216.win32-py2.7.exe fails on Win7

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

Bugs item #3486836, was opened at 2012-02-11 12:26
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3486836&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: Frank Niessink (fniessink)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installation of pywin32-216.win32-py2.7.exe fails on Win7

Initial Comment:
Hi, 

I have Python 2.7 (32 bits) installed on Windows 7. I downloaded the pywin32-216.win32-py2.7.exe installer and started it. The installer shows the first Wizard page (This wizard will install pywin32 ...). I click Next. The wizard says: "Python 2.7 is required for this package. Select installation to use:". It shows one installation: "Python Version 2.7 (found in registry)". I click Next. Wizard says it "Ready to install". I click Next. Wizard stops responding and Windows tells me "pywin32-216.win32-py2.7.exe stopped working. A problem occurred causing the program to stop working correctly." The only option is to close the program. 

Thanks, Frank

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-02-11 22:25

Message:
I've seen this happen if the python directory isn't writable by the user
installing pywin32 - is that possible?

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

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

[pywin32-bugs] [ pywin32-Bugs-3486836 ] Installation of pywin32-216.win32-py2.7.exe fails on Win7

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

Bugs item #3486836, was opened at 2012-02-11 12:26
Message generated for change (Tracker Item Submitted) made by fniessink
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3486836&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: Frank Niessink (fniessink)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installation of pywin32-216.win32-py2.7.exe fails on Win7

Initial Comment:
Hi, 

I have Python 2.7 (32 bits) installed on Windows 7. I downloaded the pywin32-216.win32-py2.7.exe installer and started it. The installer shows the first Wizard page (This wizard will install pywin32 ...). I click Next. The wizard says: "Python 2.7 is required for this package. Select installation to use:". It shows one installation: "Python Version 2.7 (found in registry)". I click Next. Wizard says it "Ready to install". I click Next. Wizard stops responding and Windows tells me "pywin32-216.win32-py2.7.exe stopped working. A problem occurred causing the program to stop working correctly." The only option is to close the program. 

Thanks, Frank

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

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

[pywin32-bugs] [ pywin32-Bugs-2065850 ] Some typelibs have non integer versions

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
>Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: Some typelibs have non integer versions

Initial Comment:
From python-win32:
"""
When using the makepy utility I noticed it used to crash out with the following traceback:

line 148, in SelectTlb
    i.major = int(i.major, 16)
ValueError: invalid literal for int() with base 16: 'CS2'
...
Most likely this (last line of traceback) refers to the version number of Adobe Photoshop Creative Suite 2.
"""
There is some existing confusion between hex and int in that file, but it doesn't expect strings!  Note that GetTypeLibInfo() etc all use integers for the version info - which probably means the typelib can't be directly loaded - but that isn't really our problem - we shouldn't die.

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-02-10 18:12

Message:
So yeah, you do have the same root problem, but I suspect it would also
happen in Python 2.5.  Are you sure you tried to generate a makepy stub in
Python 2.5?  It may be that you can use the COM object without a makepy
stub.

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

Comment By: Brenda Trist (tristb)
Date: 2012-02-10 05:58

Message:
When I run COM Makepy utility from PythonWin (version 2.6.7) I get the
following message which I did not get when I was using PythonWin 2.5.

Failed to execute command:
from win32com.client import makepy;makepy.main()
Traceback (most recent call last):
  File
"C:\Python26\Lib\site-packages\pythonwin\pywin\framework\toolmenu.py", line
103, in HandleToolCommand
    exec "%s\n" % pyCmd
  File "<string>", line 1, in <module>
  File "C:\Python26\lib\site-packages\win32com\client\makepy.py", line 362,
in main
    rc = selecttlb.SelectTlb()
  File "C:\Python26\lib\site-packages\win32com\client\selecttlb.py", line
150, in SelectTlb
    i.major = int(i.major, 16)
ValueError: invalid literal for int() with base 16: 'CS2'

I got this same message when I tried to upgrade to Python2.7.  Gave up and
went back to Python 2.5.  Now I really need to upgrade because the
nitro-nitf I am trying to use was compiled with Python2.6.  There is a good
chance that I do not have something set up correctly I am just unsure where
to look.

Thank you.

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

Comment By: Mark Hammond (mhammond)
Date: 2012-02-09 14:40

Message:
> My question is why would Python2.5 have no problem but Python2.6 and up
does.

Are you sure it is the same problem?  The original problem is that pywin32
assumes a typelib version is an integer, but in some cases it is a string
that can't be converted to an integer.   Also, the original problem must
have been pre 2.6 as 2.6 wasn't out then.  Therefore, I'd be really
surprised if this is the same issue you are facing.  Can you give a few
more details?

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

Comment By: Brenda Trist (tristb)
Date: 2012-02-09 05:14

Message:
I am having the same issue as the person who brought this up a few years
ago.  I noticed it was closed recently with no resolution.  You mention in
your comments that it has to do with the original typelib.  My question is
why would Python2.5 have no problem but Python2.6 and up does.  I would
like to upgrade because the nitro-nitf has been compiled with Python2.6 but
yet I still need to be able to run COM Makepy Utility to obtain the Excel
and Word libraries of wincom32.  Is there anything I can do to work around
this problem.  Thank you.

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

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

Message:
I'm rejecting this as it seems limited to just the original typelib and
hasn't since been reported again.

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

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

[pywin32-bugs] [ pywin32-Bugs-2065850 ] Some typelibs have non integer versions

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Pending
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: Some typelibs have non integer versions

Initial Comment:
From python-win32:
"""
When using the makepy utility I noticed it used to crash out with the following traceback:

line 148, in SelectTlb
    i.major = int(i.major, 16)
ValueError: invalid literal for int() with base 16: 'CS2'
...
Most likely this (last line of traceback) refers to the version number of Adobe Photoshop Creative Suite 2.
"""
There is some existing confusion between hex and int in that file, but it doesn't expect strings!  Note that GetTypeLibInfo() etc all use integers for the version info - which probably means the typelib can't be directly loaded - but that isn't really our problem - we shouldn't die.

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

Comment By: Brenda Trist (tristb)
Date: 2012-02-10 05:58

Message:
When I run COM Makepy utility from PythonWin (version 2.6.7) I get the
following message which I did not get when I was using PythonWin 2.5.

Failed to execute command:
from win32com.client import makepy;makepy.main()
Traceback (most recent call last):
  File
"C:\Python26\Lib\site-packages\pythonwin\pywin\framework\toolmenu.py", line
103, in HandleToolCommand
    exec "%s\n" % pyCmd
  File "<string>", line 1, in <module>
  File "C:\Python26\lib\site-packages\win32com\client\makepy.py", line 362,
in main
    rc = selecttlb.SelectTlb()
  File "C:\Python26\lib\site-packages\win32com\client\selecttlb.py", line
150, in SelectTlb
    i.major = int(i.major, 16)
ValueError: invalid literal for int() with base 16: 'CS2'

I got this same message when I tried to upgrade to Python2.7.  Gave up and
went back to Python 2.5.  Now I really need to upgrade because the
nitro-nitf I am trying to use was compiled with Python2.6.  There is a good
chance that I do not have something set up correctly I am just unsure where
to look.

Thank you.

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

Comment By: Mark Hammond (mhammond)
Date: 2012-02-09 14:40

Message:
> My question is why would Python2.5 have no problem but Python2.6 and up
does.

Are you sure it is the same problem?  The original problem is that pywin32
assumes a typelib version is an integer, but in some cases it is a string
that can't be converted to an integer.   Also, the original problem must
have been pre 2.6 as 2.6 wasn't out then.  Therefore, I'd be really
surprised if this is the same issue you are facing.  Can you give a few
more details?

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

Comment By: Brenda Trist (tristb)
Date: 2012-02-09 05:14

Message:
I am having the same issue as the person who brought this up a few years
ago.  I noticed it was closed recently with no resolution.  You mention in
your comments that it has to do with the original typelib.  My question is
why would Python2.5 have no problem but Python2.6 and up does.  I would
like to upgrade because the nitro-nitf has been compiled with Python2.6 but
yet I still need to be able to run COM Makepy Utility to obtain the Excel
and Word libraries of wincom32.  Is there anything I can do to work around
this problem.  Thank you.

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

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

Message:
I'm rejecting this as it seems limited to just the original typelib and
hasn't since been reported again.

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

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

[pywin32-bugs] [ pywin32-Bugs-2065850 ] Some typelibs have non integer versions

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
>Status: Pending
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: Some typelibs have non integer versions

Initial Comment:
From python-win32:
"""
When using the makepy utility I noticed it used to crash out with the following traceback:

line 148, in SelectTlb
    i.major = int(i.major, 16)
ValueError: invalid literal for int() with base 16: 'CS2'
...
Most likely this (last line of traceback) refers to the version number of Adobe Photoshop Creative Suite 2.
"""
There is some existing confusion between hex and int in that file, but it doesn't expect strings!  Note that GetTypeLibInfo() etc all use integers for the version info - which probably means the typelib can't be directly loaded - but that isn't really our problem - we shouldn't die.

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-02-09 14:40

Message:
> My question is why would Python2.5 have no problem but Python2.6 and up
does.

Are you sure it is the same problem?  The original problem is that pywin32
assumes a typelib version is an integer, but in some cases it is a string
that can't be converted to an integer.   Also, the original problem must
have been pre 2.6 as 2.6 wasn't out then.  Therefore, I'd be really
surprised if this is the same issue you are facing.  Can you give a few
more details?

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

Comment By: Brenda Trist (tristb)
Date: 2012-02-09 05:14

Message:
I am having the same issue as the person who brought this up a few years
ago.  I noticed it was closed recently with no resolution.  You mention in
your comments that it has to do with the original typelib.  My question is
why would Python2.5 have no problem but Python2.6 and up does.  I would
like to upgrade because the nitro-nitf has been compiled with Python2.6 but
yet I still need to be able to run COM Makepy Utility to obtain the Excel
and Word libraries of wincom32.  Is there anything I can do to work around
this problem.  Thank you.

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

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

Message:
I'm rejecting this as it seems limited to just the original typelib and
hasn't since been reported again.

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

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

[pywin32-bugs] [ pywin32-Bugs-2065850 ] Some typelibs have non integer versions

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

Bugs item #2065850, was opened at 2008-08-21 15:59
Message generated for change (Comment added) made by tristb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2065850&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: Invalid
Priority: 5
Private: No
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: Some typelibs have non integer versions

Initial Comment:
From python-win32:
"""
When using the makepy utility I noticed it used to crash out with the following traceback:

line 148, in SelectTlb
    i.major = int(i.major, 16)
ValueError: invalid literal for int() with base 16: 'CS2'
...
Most likely this (last line of traceback) refers to the version number of Adobe Photoshop Creative Suite 2.
"""
There is some existing confusion between hex and int in that file, but it doesn't expect strings!  Note that GetTypeLibInfo() etc all use integers for the version info - which probably means the typelib can't be directly loaded - but that isn't really our problem - we shouldn't die.

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

Comment By: Brenda Trist (tristb)
Date: 2012-02-09 05:14

Message:
I am having the same issue as the person who brought this up a few years
ago.  I noticed it was closed recently with no resolution.  You mention in
your comments that it has to do with the original typelib.  My question is
why would Python2.5 have no problem but Python2.6 and up does.  I would
like to upgrade because the nitro-nitf has been compiled with Python2.6 but
yet I still need to be able to run COM Makepy Utility to obtain the Excel
and Word libraries of wincom32.  Is there anything I can do to work around
this problem.  Thank you.

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

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

Message:
I'm rejecting this as it seems limited to just the original typelib and
hasn't since been reported again.

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

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

[pywin32-bugs] [ pywin32-Bugs-3486072 ] PyCWnd.SetActiveWindow raises invalid error

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

Bugs item #3486072, was opened at 2012-02-09 00:05
Message generated for change (Tracker Item Submitted) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3486072&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: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyCWnd.SetActiveWindow raises invalid error

Initial Comment:
PyCWnd.SetActiveWindow()  sometimes fails with "The window was created in a different thread and can not be mapped.", though the function did its job.

Thats obviously (just) because it tries to convert the return value (previous window / CWnd* may be temporary according MSDN) with
"return PyCWnd::make( UITypeFromCObject(pRel), pRel)->GetGoodRet();"   which uses FromHandlePermanent and some thread check or so.
Perhaps it needs a less rigid converter or return Non instead of failure.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3486072&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: Invalid
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-02-08 16:59

Message:
I re-installed today and I had no problems.  I actually went through the
uninstall & reinstall process twice and each time there were no problems. 
My apologies for the false alarm.

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

Comment By: ghostd0g (ghostd0g)
Date: 2012-02-08 06:15

Message:
the same happened to me (win7 sp1 x64 spanish, python 2.72 already
installed in non-default folder). running the installer as admin did not
work. but i found out that the permissions on my python folder were
apparently restricted. so i installed python again (this time for all
users) and it worked.

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

Comment By: Mark Hammond (mhammond)
Date: 2012-02-03 21:20

Message:
To be clear, the problem shouldn't be caused by running the installer
without elevated permissions as the installer will attempt to elevate.  The
problem is likely to be caused by a completely different user account. 
IOW, it should happen when the elevated user can't write to the directory.

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

Comment By: craigjh (craigjh)
Date: 2012-02-03 19:42

Message:
That could indeed be the problem.  My account has administrator privileges
but installs often need to be run as administrator, which I didn't do.

I am in the midst of a busy week but next week I'll have more time and will
see if this is the problem.

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

Comment By: Mark Hammond (mhammond)
Date: 2012-02-03 19:35

Message:
This sounds alot like http://bugs.python.org/issue13038 - if the target
directory isn't writable you get that crash.  Is it possible the user
trying to install pywin32 doesn't have permission to write to program
files?

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

Comment By: Mark Hammond (mhammond)
Date: 2012-01-28 20:23

Message:
I can't reproduce the hard-crash (and the 'Exception AttributeError:
"'NoneType' object has no attribute 'flush'"' error has already been
fixed).  I should have build 217 available any day now so if it can be
reproduced with that, please reopen this bug.

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

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 ghostd0g
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: Works For Me
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: ghostd0g (ghostd0g)
Date: 2012-02-08 06:15

Message:
the same happened to me (win7 sp1 x64 spanish, python 2.72 already
installed in non-default folder). running the installer as admin did not
work. but i found out that the permissions on my python folder were
apparently restricted. so i installed python again (this time for all
users) and it worked.

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

Comment By: Mark Hammond (mhammond)
Date: 2012-02-03 21:20

Message:
To be clear, the problem shouldn't be caused by running the installer
without elevated permissions as the installer will attempt to elevate.  The
problem is likely to be caused by a completely different user account. 
IOW, it should happen when the elevated user can't write to the directory.

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

Comment By: craigjh (craigjh)
Date: 2012-02-03 19:42

Message:
That could indeed be the problem.  My account has administrator privileges
but installs often need to be run as administrator, which I didn't do.

I am in the midst of a busy week but next week I'll have more time and will
see if this is the problem.

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

Comment By: Mark Hammond (mhammond)
Date: 2012-02-03 19:35

Message:
This sounds alot like http://bugs.python.org/issue13038 - if the target
directory isn't writable you get that crash.  Is it possible the user
trying to install pywin32 doesn't have permission to write to program
files?

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

Comment By: Mark Hammond (mhammond)
Date: 2012-01-28 20:23

Message:
I can't reproduce the hard-crash (and the 'Exception AttributeError:
"'NoneType' object has no attribute 'flush'"' error has already been
fixed).  I should have build 217 available any day now so if it can be
reproduced with that, please reopen this bug.

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

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