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

[pywin32-bugs] [ pywin32-Bugs-3438213 ] astimezone could not process time on Pythonwin for 3.2

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

Bugs item #3438213, was opened at 2011-11-15 02:12
Message generated for change (Comment added) made by hovea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3438213&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: win32timezone
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Anthony (hovea)
Assigned to: Nobody/Anonymous (nobody)
Summary: astimezone could not process time  on Pythonwin for 3.2

Initial Comment:
Runing the testPersist.py 
Timezone processing failed on python32

returning Stat 1
pythoncom error: Unexpected exception in gateway method '<unknown>'

ValueError: astimezone() cannot be applied to a naive datetime
pythoncom error: Unexpected gateway error

ValueError: astimezone() cannot be applied to a naive datetime
Set Size0
Traceback (most recent call last):
  File "C:\Python32\Lib\site-packages\win32com\test\testPersist.py", line 204, in <module>
    test()
  File "C:\Python32\Lib\site-packages\win32com\test\testPersist.py", line 134, in test
    stcom = pythoncom.StgCreateDocfileOnILockBytes(lbcom, storagecon.STGM_DIRECT| storagecon.STGM_CREATE | storagecon.STGM_READWRITE | storagecon.STGM_SHARE_EXCLUSIVE, 0)
pywintypes.com_error: (-2147467259, 'Unspecified error', None, None)



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

>Comment By: Anthony (hovea)
Date: 2011-11-22 00:49

Message:
This issue could be fixed by change win32\src\PywinTypes.h from line 470 to
484 as follwings:

#if (PY_VERSION_HEX < 0x03000000)
#   define NO_PYWINTYPES_TIME
#endif

// Python 2.3 doesn't have C Api for datetime, so can't have our new funky
// support.
#if (PY_VERSION_HEX >= 0x02040000)
#   define PYWIN_HAVE_DATETIME_CAPI
#endif

// XXX - fixme - ack - we don't yet like *both* defines existing - and for
now
// its only enabled in py3k
#if (PY_VERSION_HEX > 0x03000000)
#   undef PYWIN_HAVE_DATETIME_CAPI
#endif

###########################################
This issue is caused by old, crap, custom time object, using standard one
will be OK

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

Comment By: Anthony (hovea)
Date: 2011-11-21 19:26

Message:
It's the same bug as
https://sourceforge.net/tracker/?func=detail&aid=2831327&group_id=78018&atid=551954

Pytime in py3k does not work .

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

Comment By: Anthony (hovea)
Date: 2011-11-19 06:02

Message:
This issues is cause in PyObject *PyIPropertyStorage::SetTimes(PyObject
*self, PyObject *args). 
File PyIpropertyStorage.cpp line 622, which is called by Com Storage
creation.

PyWinObject_AsFILETIME not set the timezone information will cause failed
of SetTimes.

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

Comment By: Anthony (hovea)
Date: 2011-11-16 01:02

Message:
The Error is generated by pythoncom.StgCreateDocfileOnILockBytes call from
testPersist.py" . Which is located in PyTime.cpp. line 806. 
I am building pywin by using VisualStudio 2008sp1. Simply Run setup.py
build in the source code directory.
When I am tracking down, it seems that from python3, astimezone should
function should have timezone information to convert the correct time. 
I did not yet indentify where PyWinObject_AsSYSTEMTIME is called.



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

Comment By: Jason R. Coombs (jaraco)
Date: 2011-11-15 06:30

Message:
I'm not familiar with building pywin32 from scratch. Are there instructions
somewhere on how to build pywin32 on Python 3? I don't have VS2008 handy,
so I tried using VS2010 and patched msvc9compilermodule with
jaraco.develop.msvc
(https://bitbucket.org/jaraco/jaraco.develop/src/5d0574e79d6f/jaraco/develop/msvc.py),
but I'm still unable to build.

Furthermore, I don't think this is an issue with win32timezone.
"astimezone()" is a method on a datetime.datetime object (part of the
stdlib). I don't think win32timezone comes into play.

Furthermore, the text 'timezone' doesn't appear in testPersist.py. I don't
understand what testPersist.py is trying to do. I think the errors about
naive datetimes are coming from some other code which is opaque to
testPersist.

I don't feel qualified to address this issue, so I'm going to re-assign
this to no one.

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

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

[pywin32-bugs] [ pywin32-Bugs-3438213 ] astimezone could not process time on Pythonwin for 3.2

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

Bugs item #3438213, was opened at 2011-11-15 02:12
Message generated for change (Comment added) made by hovea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3438213&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: win32timezone
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Anthony (hovea)
Assigned to: Nobody/Anonymous (nobody)
Summary: astimezone could not process time  on Pythonwin for 3.2

Initial Comment:
Runing the testPersist.py 
Timezone processing failed on python32

returning Stat 1
pythoncom error: Unexpected exception in gateway method '<unknown>'

ValueError: astimezone() cannot be applied to a naive datetime
pythoncom error: Unexpected gateway error

ValueError: astimezone() cannot be applied to a naive datetime
Set Size0
Traceback (most recent call last):
  File "C:\Python32\Lib\site-packages\win32com\test\testPersist.py", line 204, in <module>
    test()
  File "C:\Python32\Lib\site-packages\win32com\test\testPersist.py", line 134, in test
    stcom = pythoncom.StgCreateDocfileOnILockBytes(lbcom, storagecon.STGM_DIRECT| storagecon.STGM_CREATE | storagecon.STGM_READWRITE | storagecon.STGM_SHARE_EXCLUSIVE, 0)
pywintypes.com_error: (-2147467259, 'Unspecified error', None, None)



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

>Comment By: Anthony (hovea)
Date: 2011-11-21 19:26

Message:
It's the same bug as
https://sourceforge.net/tracker/?func=detail&aid=2831327&group_id=78018&atid=551954

Pytime in py3k does not work .

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

Comment By: Anthony (hovea)
Date: 2011-11-19 06:02

Message:
This issues is cause in PyObject *PyIPropertyStorage::SetTimes(PyObject
*self, PyObject *args). 
File PyIpropertyStorage.cpp line 622, which is called by Com Storage
creation.

PyWinObject_AsFILETIME not set the timezone information will cause failed
of SetTimes.

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

Comment By: Anthony (hovea)
Date: 2011-11-16 01:02

Message:
The Error is generated by pythoncom.StgCreateDocfileOnILockBytes call from
testPersist.py" . Which is located in PyTime.cpp. line 806. 
I am building pywin by using VisualStudio 2008sp1. Simply Run setup.py
build in the source code directory.
When I am tracking down, it seems that from python3, astimezone should
function should have timezone information to convert the correct time. 
I did not yet indentify where PyWinObject_AsSYSTEMTIME is called.



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

Comment By: Jason R. Coombs (jaraco)
Date: 2011-11-15 06:30

Message:
I'm not familiar with building pywin32 from scratch. Are there instructions
somewhere on how to build pywin32 on Python 3? I don't have VS2008 handy,
so I tried using VS2010 and patched msvc9compilermodule with
jaraco.develop.msvc
(https://bitbucket.org/jaraco/jaraco.develop/src/5d0574e79d6f/jaraco/develop/msvc.py),
but I'm still unable to build.

Furthermore, I don't think this is an issue with win32timezone.
"astimezone()" is a method on a datetime.datetime object (part of the
stdlib). I don't think win32timezone comes into play.

Furthermore, the text 'timezone' doesn't appear in testPersist.py. I don't
understand what testPersist.py is trying to do. I think the errors about
naive datetimes are coming from some other code which is opaque to
testPersist.

I don't feel qualified to address this issue, so I'm going to re-assign
this to no one.

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

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

[pywin32-bugs] [ pywin32-Bugs-1590399 ] Refcounting / GIL problems (dual)

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

Bugs item #1590399, was opened at 2006-11-04 02:12
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1590399&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: 9
Private: No
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Refcounting / GIL problems (dual)

Initial Comment:
I wonder if the below patch possibly addresses a
refcount/memory problem. Think its possible, that
DODECREF(this) frees <*this> from memory, another
released threads malloc uses the memory and
this->virtualInst is bogus?

( In preceding function  ui_assoc_object::DoKillAssoc
there is a simlar technique to do "PyObject *vi =
virtualInst;" - but for reverse reason )

( I'm still in search of memory leaks/crashes on dual
cores and fast CPUs when other threads are going on
parallel to win32ui GUI mainthread. )



--- win32assoc.cpp.orig	2005-04-12 17:01:00.000000000 +0200
+++ win32assoc.cpp	2006-11-04 10:59:46.326646400 +0100
@@ -252,9 +252,10 @@
 {
 	if (this==NULL) return NULL;
 	if (virtualInst) {
+		PyObject *vi = virtualInst;
+		DOINCREF(vi);
 		DODECREF(this);
-		DOINCREF(virtualInst);
-		return virtualInst;
+		return vi;
 	} else
 		return this;
 }


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

Comment By: kxroberto (kxroberto)
Date: 2011-11-21 05:57

Message:
(its not possible to attach files here anymore, so I opened it as new patch
ID 3440738)

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

Comment By: kxroberto (kxroberto)
Date: 2011-11-21 05:47

Message:
I still have nasty problems with Python objects magically changing /
loosing attributes shortly after creation, while using win32ui and heavy
threading. Mainly on machines with many Cores/CPUs. 

Patch below: I found 2 strongly smelling locations in win32ui, which are
probably responsible: where objects are DECREF'ed  and possibly INCREF'ed
soon after - while "hoping" that they do not disappear. But I guess this is
not valid (today). A new Python object somewhere may use this memory
meanwhile and then the object may be stolen back and going hybrid ...

(Unfortunately I don't have the MS full version compilers to compile
current MFC based stuff.  (Or is this possible somehow with VC Express
versions?)  I could make quick tests of win32ui.pyd   (py2.3 and py2.6)


diff -ur --strip _orig/win32assoc.cpp ./win32assoc.cpp
--- _orig/win32assoc.cpp	2009-03-04 11:52:00 +0000
+++ ./win32assoc.cpp	2011-11-21 13:10:42 +0000
@@ -228,11 +228,11 @@
 	// So set the instance to NULL _before_ we decref it!
 	PyObject *old = pAssoc->virtualInst;
 	pAssoc->virtualInst = NULL;
-	XDODECREF(old);
 	if (ob!=Py_None) {
 		pAssoc->virtualInst = ob;
 		DOINCREF(ob);
 	}
+	XDODECREF(old);
 	RETURN_NONE;
 }
 
diff -ur --strip _orig/win32cmd.cpp ./win32cmd.cpp
--- _orig/win32cmd.cpp	2009-01-08 22:33:00 +0000
+++ ./win32cmd.cpp	2011-11-21 13:10:26 +0000
@@ -208,17 +208,20 @@
 		RETURN_ERR("The parameter must be a callable object or None");
 
 	void *oldMethod = NULL;
-	// note I maybe decref, then maybe incref.  I assume object wont be
destroyed
-	// (ie, ref go to zero) between the 2 calls!)
+	// we need incref's early in order to avoid a ref erronously going to
zero during DEDECREF
+	if (method!=Py_None) {
+		Py_INCREF(method);
+		Py_INCREF(hookedObject);
+	}
 	if (pList->Lookup(message, oldMethod)) {
 		pList->RemoveKey(message);
 		// oldMethod is returned - don't drop its reference.
 		DODECREF(hookedObject);
 	}
 	if (method!=Py_None) {
-		Py_INCREF(method);
+		// already done above: Py_INCREF(method);
 		pList->SetAt(message,method);
-		Py_INCREF(hookedObject);
+		// already done above: Py_INCREF(hookedObject);
 	}
 	if (oldMethod)
 		return (PyObject *)oldMethod;


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

Comment By: Mark Hammond (mhammond)
Date: 2006-11-20 04:37

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

(Very slightly modified version) checked in - thanks!

Checking in win32assoc.cpp;
new revision: 1.8; previous revision: 1.7
Checking in win32virt.cpp;
new revision: 1.4; previous revision: 1.3


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

Comment By: kxroberto (kxroberto)
Date: 2006-11-08 01:12

Message:
Logged In: YES 
user_id=972995

Meanwhile there is significant feedback that
c_GIL_bugs.patch in fact solved all the crash problems with
threaded apps on all (dual core) machines.

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

Comment By: kxroberto (kxroberto)
Date: 2006-11-05 12:00

Message:
Logged In: YES 
user_id=972995

In attachment a patch candidate I've so far in action for
all these things.
(That issue around "pExistingAppObject" was nonsense.
pExistingAppObject seems to be not set to anything at all)

Notes:

The speed DECREF's in ~CVirtualHelper are switched all off
by this patch - as it seems to not be valid so outside of
the GIL. Would require a __asm LOCK INC/DEC or so. Have not
seen serious speed issues in apps so far. 
Yet I've seen: most often CVirtualHelp is instanciated -
costing a enter/leave python state switch - and then
immediately a helper.call(..) with again a enter/leave state
switch. If optimization necessary, possibly by a
CVirtualHelpE does it which enters Python in constructor
until destruction and the .call's do not again have to
enter. Only few locations, where the intermediate
PythonLeave/GUI_BGN_SAVE is necessary.


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

Comment By: kxroberto (kxroberto)
Date: 2006-11-04 07:49

Message:
Logged In: YES 
user_id=972995

Think I found other serious potential refcount/GIL problems
which cause crashes here in apps with threads - mainly on
dual core - and set priority to 9:

I looked over GUI_BGN_SAVE's
=> Py_XINC/DECREF's outside of the GIL. this causes probably
the special problems only on dual cores when multiple threads:


win32cmdui/Line120:
					GUI_BGN_SAVE;
					Python_delete_assoc(ob);
					GUI_END_SAVE;
win32uimodule/Line650:
void Python_delete_assoc( void *ob )
{
	// Notify Python object of my attached object removal.
	{
	CVirtualHelper helper ("OnAttachedObjectDeath", ob);
<================
	helper.call();                                      
<================
	}
	ui_assoc_object *pObj;
	if ((pObj=ui_assoc_object::GetPyObject(ob)) &&
!bInFatalShutdown) {
		CEnterLeavePython _celp; // KillAssoc requires it is held!
		pObj->KillAssoc();
	}
}

win32virt.cpp/Line22
CVirtualHelper::CVirtualHelper(const char *iname, const void
*iassoc, EnumVirtualErrorHandling veh/* = VEH_PRINT_ERROR */)
{
	handler=NULL;
	py_ob = NULL;
...
	py_ob = py_bob;
	Py_INCREF(py_ob);            <================
//	Py_XINCREF(handler);
}


The gross hack for speed in
CVirtualHelper::~CVirtualHelper() will not work for dual cores. 
A fast "ZDODECREF/ZDODECREF" independent of GIL (unless it
went to 0) would be possible on x86 with "__asm LOCK DEC
<(op)->ob_refcnt>" or so.
see:
http://groups.google.de/group/comp.lang.python/msg/ef530d4448814391


CVirtualHelper::~CVirtualHelper()
{
	// XXX - Gross hack for speed.  This is called for eachh
window message
	// so only grabs the Python lock if the objects need Python,
	if ((retVal && retVal->ob_refcnt==1) ||    
<================ DECREF not atomic on multi-core CPU's
		(handler && handler->ob_refcnt==1) || 
		(py_ob && py_ob->ob_refcnt==1)) {
		CEnterLeavePython _celp;
		XDODECREF(retVal);
		XDODECREF(handler);
		XDODECREF(py_ob);
	} else {
		XDODECREF(retVal);          <================ DECREF not
atomic on multi-core CPU's
		XDODECREF(handler);
		XDODECREF(py_ob);
	}
}


Maybe there are other loose INCREFS / DECREFS in win32 code?


And I found - probably most serious in this list - : 
Only CVirtualHelper::do_call  is CEnterLeavePython protected:

BOOL CVirtualHelper::do_call(PyObject *args)
{
	CEnterLeavePython _celp;
	XDODECREF(retVal);	// our old one.
	retVal = NULL;


but all entrace call functions are not - but they are
bulding up Python Values ! 
Think that is serious (even on single cores where I have
very rare crashes):
e.g.:

BOOL CVirtualHelper::call()
{
	if (!handler) return FALSE;
	PyObject *arglst = Py_BuildValue("()");      <================
	return do_call(arglst);
}


=>Probably the CEnterleave protection should be moved out of
do_call to all entrance call(...)'s & call_args()  ?



Looked in a rush over the 200 base DECREFs in Pythonwin.
Found so far no other smelling refcounting.
Only maybe this is invalid  :

--- win32app.cpp.orig   2006-01-10 15:38:00.000000000 +0100
+++ win32app.cpp        2006-11-04 16:44:24.009694400 +0100
@@ -412,6 +412,7 @@
 {
        PyCWinThread::cleanup();
        // total hack!
-       while (pExistingAppObject)
+       while (pExistingAppObject->ob_refcnt>1)
                DODECREF(pExistingAppObject); // this may
delete it.
+       DODECREF(pExistingAppObject);
 }



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

Comment By: kxroberto (kxroberto)
Date: 2006-11-04 02:22

Message:
Logged In: YES 
user_id=972995

(repeated)

--- win32assoc.cpp.orig	2005-04-12 17:01:00.000000000 +0200
+++ win32assoc.cpp	2006-11-04 10:59:46.326646400 +0100
@@ -252,9 +252,10 @@
 {
 	if (this==NULL) return NULL;
 	if (virtualInst) {
+		PyObject *vi = virtualInst;
+		DOINCREF(vi);
 		DODECREF(this);
-		DOINCREF(virtualInst);
-		return virtualInst;
+		return vi;
 	} else
 		return this;
 }


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

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

[pywin32-bugs] [ pywin32-Patches-3440738 ] DECREF INCREF Problem (probably severe)

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

Patches item #3440738, was opened at 2011-11-21 05:54
Message generated for change (Settings changed) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3440738&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: 9
Private: No
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: DECREF INCREF Problem (probably severe)

Initial Comment:
See also bug #1590399

I still have nasty problems with Python objects magically changing / loosing attributes shortly after creation, while using win32ui and heavy threading. Mainly on machines with many Cores/CPUs. 

Patch below: I found 2 strongly smelling locations in win32ui, which are probably responsible: where objects are DECREF'ed  and possibly INCREF'ed soon after - while "hoping" that they do not disappear. But I guess this is not valid (today). A new Python object somewhere may use this memory meanwhile and then the object may be stolen back and going hybrid ...

(Unfortunately I don't have the MS full version compilers to compile current MFC based stuff.  (Or is this possible somehow with VC Express versions?)  I could make quick tests of win32ui.pyd   (py2.3 and py2.6)


diff -ur --strip _orig/win32assoc.cpp ./win32assoc.cpp
--- _orig/win32assoc.cpp	2009-03-04 11:52:00 +0000
+++ ./win32assoc.cpp	2011-11-21 13:10:42 +0000
@@ -228,11 +228,11 @@
 	// So set the instance to NULL _before_ we decref it!
 	PyObject *old = pAssoc->virtualInst;
 	pAssoc->virtualInst = NULL;
-	XDODECREF(old);
 	if (ob!=Py_None) {
 		pAssoc->virtualInst = ob;
 		DOINCREF(ob);
 	}
+	XDODECREF(old);
 	RETURN_NONE;
 }
 
diff -ur --strip _orig/win32cmd.cpp ./win32cmd.cpp
--- _orig/win32cmd.cpp	2009-01-08 22:33:00 +0000
+++ ./win32cmd.cpp	2011-11-21 13:10:26 +0000
@@ -208,17 +208,20 @@
 		RETURN_ERR("The parameter must be a callable object or None");
 
 	void *oldMethod = NULL;
-	// note I maybe decref, then maybe incref.  I assume object wont be destroyed
-	// (ie, ref go to zero) between the 2 calls!)
+	// we need incref's early in order to avoid a ref erronously going to zero during DEDECREF
+	if (method!=Py_None) {
+		Py_INCREF(method);
+		Py_INCREF(hookedObject);
+	}
 	if (pList->Lookup(message, oldMethod)) {
 		pList->RemoveKey(message);
 		// oldMethod is returned - don't drop its reference.
 		DODECREF(hookedObject);
 	}
 	if (method!=Py_None) {
-		Py_INCREF(method);
+		// already done above: Py_INCREF(method);
 		pList->SetAt(message,method);
-		Py_INCREF(hookedObject);
+		// already done above: Py_INCREF(hookedObject);
 	}
 	if (oldMethod)
 		return (PyObject *)oldMethod;


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

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

[pywin32-bugs] [ pywin32-Patches-3440738 ] DECREF INCREF Problem (probably severe)

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

Patches item #3440738, was opened at 2011-11-21 05:54
Message generated for change (Tracker Item Submitted) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3440738&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: DECREF INCREF Problem (probably severe)

Initial Comment:
See also bug #1590399

I still have nasty problems with Python objects magically changing / loosing attributes shortly after creation, while using win32ui and heavy threading. Mainly on machines with many Cores/CPUs. 

Patch below: I found 2 strongly smelling locations in win32ui, which are probably responsible: where objects are DECREF'ed  and possibly INCREF'ed soon after - while "hoping" that they do not disappear. But I guess this is not valid (today). A new Python object somewhere may use this memory meanwhile and then the object may be stolen back and going hybrid ...

(Unfortunately I don't have the MS full version compilers to compile current MFC based stuff.  (Or is this possible somehow with VC Express versions?)  I could make quick tests of win32ui.pyd   (py2.3 and py2.6)


diff -ur --strip _orig/win32assoc.cpp ./win32assoc.cpp
--- _orig/win32assoc.cpp	2009-03-04 11:52:00 +0000
+++ ./win32assoc.cpp	2011-11-21 13:10:42 +0000
@@ -228,11 +228,11 @@
 	// So set the instance to NULL _before_ we decref it!
 	PyObject *old = pAssoc->virtualInst;
 	pAssoc->virtualInst = NULL;
-	XDODECREF(old);
 	if (ob!=Py_None) {
 		pAssoc->virtualInst = ob;
 		DOINCREF(ob);
 	}
+	XDODECREF(old);
 	RETURN_NONE;
 }
 
diff -ur --strip _orig/win32cmd.cpp ./win32cmd.cpp
--- _orig/win32cmd.cpp	2009-01-08 22:33:00 +0000
+++ ./win32cmd.cpp	2011-11-21 13:10:26 +0000
@@ -208,17 +208,20 @@
 		RETURN_ERR("The parameter must be a callable object or None");
 
 	void *oldMethod = NULL;
-	// note I maybe decref, then maybe incref.  I assume object wont be destroyed
-	// (ie, ref go to zero) between the 2 calls!)
+	// we need incref's early in order to avoid a ref erronously going to zero during DEDECREF
+	if (method!=Py_None) {
+		Py_INCREF(method);
+		Py_INCREF(hookedObject);
+	}
 	if (pList->Lookup(message, oldMethod)) {
 		pList->RemoveKey(message);
 		// oldMethod is returned - don't drop its reference.
 		DODECREF(hookedObject);
 	}
 	if (method!=Py_None) {
-		Py_INCREF(method);
+		// already done above: Py_INCREF(method);
 		pList->SetAt(message,method);
-		Py_INCREF(hookedObject);
+		// already done above: Py_INCREF(hookedObject);
 	}
 	if (oldMethod)
 		return (PyObject *)oldMethod;


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

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

[pywin32-bugs] [ pywin32-Bugs-1590399 ] Refcounting / GIL problems (dual)

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

Bugs item #1590399, was opened at 2006-11-04 02:12
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1590399&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: 9
Private: No
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Refcounting / GIL problems (dual)

Initial Comment:
I wonder if the below patch possibly addresses a
refcount/memory problem. Think its possible, that
DODECREF(this) frees <*this> from memory, another
released threads malloc uses the memory and
this->virtualInst is bogus?

( In preceding function  ui_assoc_object::DoKillAssoc
there is a simlar technique to do "PyObject *vi =
virtualInst;" - but for reverse reason )

( I'm still in search of memory leaks/crashes on dual
cores and fast CPUs when other threads are going on
parallel to win32ui GUI mainthread. )



--- win32assoc.cpp.orig	2005-04-12 17:01:00.000000000 +0200
+++ win32assoc.cpp	2006-11-04 10:59:46.326646400 +0100
@@ -252,9 +252,10 @@
 {
 	if (this==NULL) return NULL;
 	if (virtualInst) {
+		PyObject *vi = virtualInst;
+		DOINCREF(vi);
 		DODECREF(this);
-		DOINCREF(virtualInst);
-		return virtualInst;
+		return vi;
 	} else
 		return this;
 }


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

Comment By: kxroberto (kxroberto)
Date: 2011-11-21 05:47

Message:
I still have nasty problems with Python objects magically changing /
loosing attributes shortly after creation, while using win32ui and heavy
threading. Mainly on machines with many Cores/CPUs. 

Patch below: I found 2 strongly smelling locations in win32ui, which are
probably responsible: where objects are DECREF'ed  and possibly INCREF'ed
soon after - while "hoping" that they do not disappear. But I guess this is
not valid (today). A new Python object somewhere may use this memory
meanwhile and then the object may be stolen back and going hybrid ...

(Unfortunately I don't have the MS full version compilers to compile
current MFC based stuff.  (Or is this possible somehow with VC Express
versions?)  I could make quick tests of win32ui.pyd   (py2.3 and py2.6)


diff -ur --strip _orig/win32assoc.cpp ./win32assoc.cpp
--- _orig/win32assoc.cpp	2009-03-04 11:52:00 +0000
+++ ./win32assoc.cpp	2011-11-21 13:10:42 +0000
@@ -228,11 +228,11 @@
 	// So set the instance to NULL _before_ we decref it!
 	PyObject *old = pAssoc->virtualInst;
 	pAssoc->virtualInst = NULL;
-	XDODECREF(old);
 	if (ob!=Py_None) {
 		pAssoc->virtualInst = ob;
 		DOINCREF(ob);
 	}
+	XDODECREF(old);
 	RETURN_NONE;
 }
 
diff -ur --strip _orig/win32cmd.cpp ./win32cmd.cpp
--- _orig/win32cmd.cpp	2009-01-08 22:33:00 +0000
+++ ./win32cmd.cpp	2011-11-21 13:10:26 +0000
@@ -208,17 +208,20 @@
 		RETURN_ERR("The parameter must be a callable object or None");
 
 	void *oldMethod = NULL;
-	// note I maybe decref, then maybe incref.  I assume object wont be
destroyed
-	// (ie, ref go to zero) between the 2 calls!)
+	// we need incref's early in order to avoid a ref erronously going to
zero during DEDECREF
+	if (method!=Py_None) {
+		Py_INCREF(method);
+		Py_INCREF(hookedObject);
+	}
 	if (pList->Lookup(message, oldMethod)) {
 		pList->RemoveKey(message);
 		// oldMethod is returned - don't drop its reference.
 		DODECREF(hookedObject);
 	}
 	if (method!=Py_None) {
-		Py_INCREF(method);
+		// already done above: Py_INCREF(method);
 		pList->SetAt(message,method);
-		Py_INCREF(hookedObject);
+		// already done above: Py_INCREF(hookedObject);
 	}
 	if (oldMethod)
 		return (PyObject *)oldMethod;


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

Comment By: Mark Hammond (mhammond)
Date: 2006-11-20 04:37

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

(Very slightly modified version) checked in - thanks!

Checking in win32assoc.cpp;
new revision: 1.8; previous revision: 1.7
Checking in win32virt.cpp;
new revision: 1.4; previous revision: 1.3


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

Comment By: kxroberto (kxroberto)
Date: 2006-11-08 01:12

Message:
Logged In: YES 
user_id=972995

Meanwhile there is significant feedback that
c_GIL_bugs.patch in fact solved all the crash problems with
threaded apps on all (dual core) machines.

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

Comment By: kxroberto (kxroberto)
Date: 2006-11-05 12:00

Message:
Logged In: YES 
user_id=972995

In attachment a patch candidate I've so far in action for
all these things.
(That issue around "pExistingAppObject" was nonsense.
pExistingAppObject seems to be not set to anything at all)

Notes:

The speed DECREF's in ~CVirtualHelper are switched all off
by this patch - as it seems to not be valid so outside of
the GIL. Would require a __asm LOCK INC/DEC or so. Have not
seen serious speed issues in apps so far. 
Yet I've seen: most often CVirtualHelp is instanciated -
costing a enter/leave python state switch - and then
immediately a helper.call(..) with again a enter/leave state
switch. If optimization necessary, possibly by a
CVirtualHelpE does it which enters Python in constructor
until destruction and the .call's do not again have to
enter. Only few locations, where the intermediate
PythonLeave/GUI_BGN_SAVE is necessary.


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

Comment By: kxroberto (kxroberto)
Date: 2006-11-04 07:49

Message:
Logged In: YES 
user_id=972995

Think I found other serious potential refcount/GIL problems
which cause crashes here in apps with threads - mainly on
dual core - and set priority to 9:

I looked over GUI_BGN_SAVE's
=> Py_XINC/DECREF's outside of the GIL. this causes probably
the special problems only on dual cores when multiple threads:


win32cmdui/Line120:
					GUI_BGN_SAVE;
					Python_delete_assoc(ob);
					GUI_END_SAVE;
win32uimodule/Line650:
void Python_delete_assoc( void *ob )
{
	// Notify Python object of my attached object removal.
	{
	CVirtualHelper helper ("OnAttachedObjectDeath", ob);
<================
	helper.call();                                      
<================
	}
	ui_assoc_object *pObj;
	if ((pObj=ui_assoc_object::GetPyObject(ob)) &&
!bInFatalShutdown) {
		CEnterLeavePython _celp; // KillAssoc requires it is held!
		pObj->KillAssoc();
	}
}

win32virt.cpp/Line22
CVirtualHelper::CVirtualHelper(const char *iname, const void
*iassoc, EnumVirtualErrorHandling veh/* = VEH_PRINT_ERROR */)
{
	handler=NULL;
	py_ob = NULL;
...
	py_ob = py_bob;
	Py_INCREF(py_ob);            <================
//	Py_XINCREF(handler);
}


The gross hack for speed in
CVirtualHelper::~CVirtualHelper() will not work for dual cores. 
A fast "ZDODECREF/ZDODECREF" independent of GIL (unless it
went to 0) would be possible on x86 with "__asm LOCK DEC
<(op)->ob_refcnt>" or so.
see:
http://groups.google.de/group/comp.lang.python/msg/ef530d4448814391


CVirtualHelper::~CVirtualHelper()
{
	// XXX - Gross hack for speed.  This is called for eachh
window message
	// so only grabs the Python lock if the objects need Python,
	if ((retVal && retVal->ob_refcnt==1) ||    
<================ DECREF not atomic on multi-core CPU's
		(handler && handler->ob_refcnt==1) || 
		(py_ob && py_ob->ob_refcnt==1)) {
		CEnterLeavePython _celp;
		XDODECREF(retVal);
		XDODECREF(handler);
		XDODECREF(py_ob);
	} else {
		XDODECREF(retVal);          <================ DECREF not
atomic on multi-core CPU's
		XDODECREF(handler);
		XDODECREF(py_ob);
	}
}


Maybe there are other loose INCREFS / DECREFS in win32 code?


And I found - probably most serious in this list - : 
Only CVirtualHelper::do_call  is CEnterLeavePython protected:

BOOL CVirtualHelper::do_call(PyObject *args)
{
	CEnterLeavePython _celp;
	XDODECREF(retVal);	// our old one.
	retVal = NULL;


but all entrace call functions are not - but they are
bulding up Python Values ! 
Think that is serious (even on single cores where I have
very rare crashes):
e.g.:

BOOL CVirtualHelper::call()
{
	if (!handler) return FALSE;
	PyObject *arglst = Py_BuildValue("()");      <================
	return do_call(arglst);
}


=>Probably the CEnterleave protection should be moved out of
do_call to all entrance call(...)'s & call_args()  ?



Looked in a rush over the 200 base DECREFs in Pythonwin.
Found so far no other smelling refcounting.
Only maybe this is invalid  :

--- win32app.cpp.orig   2006-01-10 15:38:00.000000000 +0100
+++ win32app.cpp        2006-11-04 16:44:24.009694400 +0100
@@ -412,6 +412,7 @@
 {
        PyCWinThread::cleanup();
        // total hack!
-       while (pExistingAppObject)
+       while (pExistingAppObject->ob_refcnt>1)
                DODECREF(pExistingAppObject); // this may
delete it.
+       DODECREF(pExistingAppObject);
 }



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

Comment By: kxroberto (kxroberto)
Date: 2006-11-04 02:22

Message:
Logged In: YES 
user_id=972995

(repeated)

--- win32assoc.cpp.orig	2005-04-12 17:01:00.000000000 +0200
+++ win32assoc.cpp	2006-11-04 10:59:46.326646400 +0100
@@ -252,9 +252,10 @@
 {
 	if (this==NULL) return NULL;
 	if (virtualInst) {
+		PyObject *vi = virtualInst;
+		DOINCREF(vi);
 		DODECREF(this);
-		DOINCREF(virtualInst);
-		return virtualInst;
+		return vi;
 	} else
 		return this;
 }


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

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

[pywin32-bugs] [ pywin32-Bugs-3438213 ] astimezone could not process time on Pythonwin for 3.2

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

Bugs item #3438213, was opened at 2011-11-15 02:12
Message generated for change (Comment added) made by hovea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3438213&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: win32timezone
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Anthony (hovea)
Assigned to: Nobody/Anonymous (nobody)
Summary: astimezone could not process time  on Pythonwin for 3.2

Initial Comment:
Runing the testPersist.py 
Timezone processing failed on python32

returning Stat 1
pythoncom error: Unexpected exception in gateway method '<unknown>'

ValueError: astimezone() cannot be applied to a naive datetime
pythoncom error: Unexpected gateway error

ValueError: astimezone() cannot be applied to a naive datetime
Set Size0
Traceback (most recent call last):
  File "C:\Python32\Lib\site-packages\win32com\test\testPersist.py", line 204, in <module>
    test()
  File "C:\Python32\Lib\site-packages\win32com\test\testPersist.py", line 134, in test
    stcom = pythoncom.StgCreateDocfileOnILockBytes(lbcom, storagecon.STGM_DIRECT| storagecon.STGM_CREATE | storagecon.STGM_READWRITE | storagecon.STGM_SHARE_EXCLUSIVE, 0)
pywintypes.com_error: (-2147467259, 'Unspecified error', None, None)



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

>Comment By: Anthony (hovea)
Date: 2011-11-19 06:02

Message:
This issues is cause in PyObject *PyIPropertyStorage::SetTimes(PyObject
*self, PyObject *args). 
File PyIpropertyStorage.cpp line 622, which is called by Com Storage
creation.

PyWinObject_AsFILETIME not set the timezone information will cause failed
of SetTimes.

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

Comment By: Anthony (hovea)
Date: 2011-11-16 01:02

Message:
The Error is generated by pythoncom.StgCreateDocfileOnILockBytes call from
testPersist.py" . Which is located in PyTime.cpp. line 806. 
I am building pywin by using VisualStudio 2008sp1. Simply Run setup.py
build in the source code directory.
When I am tracking down, it seems that from python3, astimezone should
function should have timezone information to convert the correct time. 
I did not yet indentify where PyWinObject_AsSYSTEMTIME is called.



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

Comment By: Jason R. Coombs (jaraco)
Date: 2011-11-15 06:30

Message:
I'm not familiar with building pywin32 from scratch. Are there instructions
somewhere on how to build pywin32 on Python 3? I don't have VS2008 handy,
so I tried using VS2010 and patched msvc9compilermodule with
jaraco.develop.msvc
(https://bitbucket.org/jaraco/jaraco.develop/src/5d0574e79d6f/jaraco/develop/msvc.py),
but I'm still unable to build.

Furthermore, I don't think this is an issue with win32timezone.
"astimezone()" is a method on a datetime.datetime object (part of the
stdlib). I don't think win32timezone comes into play.

Furthermore, the text 'timezone' doesn't appear in testPersist.py. I don't
understand what testPersist.py is trying to do. I think the errors about
naive datetimes are coming from some other code which is opaque to
testPersist.

I don't feel qualified to address this issue, so I'm going to re-assign
this to no one.

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

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

[pywin32-bugs] [ pywin32-Patches-3439279 ] Add missing LOGON32 constants

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

Patches item #3439279, was opened at 2011-11-17 01:08
Message generated for change (Tracker Item Submitted) made by dieterv1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3439279&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: Dieter Verfaillie (dieterv1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add missing LOGON32 constants

Initial Comment:
While trying to get LogonUser/ImpersonateLoggedOnUser to work with cashed credentials, I noticed
win32con is missing LOGON32_PROVIDER_WINNT40 and LOGON32_PROVIDER_WINNT50.
I've also added some missing LOGON32_LOGON constants while at it.

Relevant documentation:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa378184%28v=vs.85%29.aspx
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/winbase.h?rev=1.114&content-type=text/x-cvsweb-markup&cvsroot=src


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3439279&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: 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 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: 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: 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 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: 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: 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-3438213 ] astimezone could not process time on Pythonwin for 3.2

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

Bugs item #3438213, was opened at 2011-11-15 02:12
Message generated for change (Comment added) made by hovea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3438213&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: win32timezone
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Anthony (hovea)
Assigned to: Nobody/Anonymous (nobody)
Summary: astimezone could not process time  on Pythonwin for 3.2

Initial Comment:
Runing the testPersist.py 
Timezone processing failed on python32

returning Stat 1
pythoncom error: Unexpected exception in gateway method '<unknown>'

ValueError: astimezone() cannot be applied to a naive datetime
pythoncom error: Unexpected gateway error

ValueError: astimezone() cannot be applied to a naive datetime
Set Size0
Traceback (most recent call last):
  File "C:\Python32\Lib\site-packages\win32com\test\testPersist.py", line 204, in <module>
    test()
  File "C:\Python32\Lib\site-packages\win32com\test\testPersist.py", line 134, in test
    stcom = pythoncom.StgCreateDocfileOnILockBytes(lbcom, storagecon.STGM_DIRECT| storagecon.STGM_CREATE | storagecon.STGM_READWRITE | storagecon.STGM_SHARE_EXCLUSIVE, 0)
pywintypes.com_error: (-2147467259, 'Unspecified error', None, None)



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

>Comment By: Anthony (hovea)
Date: 2011-11-16 01:02

Message:
The Error is generated by pythoncom.StgCreateDocfileOnILockBytes call from
testPersist.py" . Which is located in PyTime.cpp. line 806. 
I am building pywin by using VisualStudio 2008sp1. Simply Run setup.py
build in the source code directory.
When I am tracking down, it seems that from python3, astimezone should
function should have timezone information to convert the correct time. 
I did not yet indentify where PyWinObject_AsSYSTEMTIME is called.



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

Comment By: Jason R. Coombs (jaraco)
Date: 2011-11-15 06:30

Message:
I'm not familiar with building pywin32 from scratch. Are there instructions
somewhere on how to build pywin32 on Python 3? I don't have VS2008 handy,
so I tried using VS2010 and patched msvc9compilermodule with
jaraco.develop.msvc
(https://bitbucket.org/jaraco/jaraco.develop/src/5d0574e79d6f/jaraco/develop/msvc.py),
but I'm still unable to build.

Furthermore, I don't think this is an issue with win32timezone.
"astimezone()" is a method on a datetime.datetime object (part of the
stdlib). I don't think win32timezone comes into play.

Furthermore, the text 'timezone' doesn't appear in testPersist.py. I don't
understand what testPersist.py is trying to do. I think the errors about
naive datetimes are coming from some other code which is opaque to
testPersist.

I don't feel qualified to address this issue, so I'm going to re-assign
this to no one.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3438213&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: 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 (Tracker Item Submitted) 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

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

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

[pywin32-bugs] [ pywin32-Bugs-3438213 ] astimezone could not process time on Pythonwin for 3.2

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

Bugs item #3438213, was opened at 2011-11-15 02:12
Message generated for change (Comment added) made by jaraco
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3438213&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: win32timezone
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Anthony (hovea)
>Assigned to: Nobody/Anonymous (nobody)
Summary: astimezone could not process time  on Pythonwin for 3.2

Initial Comment:
Runing the testPersist.py 
Timezone processing failed on python32

returning Stat 1
pythoncom error: Unexpected exception in gateway method '<unknown>'

ValueError: astimezone() cannot be applied to a naive datetime
pythoncom error: Unexpected gateway error

ValueError: astimezone() cannot be applied to a naive datetime
Set Size0
Traceback (most recent call last):
  File "C:\Python32\Lib\site-packages\win32com\test\testPersist.py", line 204, in <module>
    test()
  File "C:\Python32\Lib\site-packages\win32com\test\testPersist.py", line 134, in test
    stcom = pythoncom.StgCreateDocfileOnILockBytes(lbcom, storagecon.STGM_DIRECT| storagecon.STGM_CREATE | storagecon.STGM_READWRITE | storagecon.STGM_SHARE_EXCLUSIVE, 0)
pywintypes.com_error: (-2147467259, 'Unspecified error', None, None)



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

>Comment By: Jason R. Coombs (jaraco)
Date: 2011-11-15 06:30

Message:
I'm not familiar with building pywin32 from scratch. Are there instructions
somewhere on how to build pywin32 on Python 3? I don't have VS2008 handy,
so I tried using VS2010 and patched msvc9compilermodule with
jaraco.develop.msvc
(https://bitbucket.org/jaraco/jaraco.develop/src/5d0574e79d6f/jaraco/develop/msvc.py),
but I'm still unable to build.

Furthermore, I don't think this is an issue with win32timezone.
"astimezone()" is a method on a datetime.datetime object (part of the
stdlib). I don't think win32timezone comes into play.

Furthermore, the text 'timezone' doesn't appear in testPersist.py. I don't
understand what testPersist.py is trying to do. I think the errors about
naive datetimes are coming from some other code which is opaque to
testPersist.

I don't feel qualified to address this issue, so I'm going to re-assign
this to no one.

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

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

[pywin32-bugs] [ pywin32-Bugs-3438213 ] astimezone could not process time on Pythonwin for 3.2

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

Bugs item #3438213, was opened at 2011-11-15 02:12
Message generated for change (Tracker Item Submitted) made by hovea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3438213&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: win32timezone
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Anthony (hovea)
Assigned to: Jason R. Coombs (jaraco)
Summary: astimezone could not process time  on Pythonwin for 3.2

Initial Comment:
Runing the testPersist.py 
Timezone processing failed on python32

returning Stat 1
pythoncom error: Unexpected exception in gateway method '<unknown>'

ValueError: astimezone() cannot be applied to a naive datetime
pythoncom error: Unexpected gateway error

ValueError: astimezone() cannot be applied to a naive datetime
Set Size0
Traceback (most recent call last):
  File "C:\Python32\Lib\site-packages\win32com\test\testPersist.py", line 204, in <module>
    test()
  File "C:\Python32\Lib\site-packages\win32com\test\testPersist.py", line 134, in test
    stcom = pythoncom.StgCreateDocfileOnILockBytes(lbcom, storagecon.STGM_DIRECT| storagecon.STGM_CREATE | storagecon.STGM_READWRITE | storagecon.STGM_SHARE_EXCLUSIVE, 0)
pywintypes.com_error: (-2147467259, 'Unspecified error', None, None)



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3438213&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 kxroberto
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: 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-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 kxroberto
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: 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-Patches-3433953 ] Auto complete methods of all implemented types for IDispatch

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

Patches item #3433953, was opened at 2011-11-05 14:19
Message generated for change (Comment added) made by otengler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3433953&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: Oliver (otengler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Auto complete methods of all implemented types for IDispatch

Initial Comment:
The auto completion for IDispatch COM objects only processes the methods of the implemented type but not the types this type implements. E.g. when trying to auto complete a "Shell.Application" object only "WindowSwitcher" is shown (Windows 7). "Shell.Application" implements IShellApplication5. IShellApplication5 implements IShellApplication4 and so on. The patch collects all methods in a none recursive way.

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

Comment By: Oliver (otengler)
Date: 2011-11-06 10:30

Message:
Yes, that would be nice.

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

Comment By: Mark Hammond (mhammond)
Date: 2011-11-05 18:35

Message:
That looks pretty good to me - although I might move the pythoncom import
locally to the new function.  How would you like to be credited in the hg
log and CHANGES.txt - "Oliver Tengler"?

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

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

[pywin32-bugs] [ pywin32-Patches-3203451 ] Incorrect/missing file attribute constants

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

Patches item #3203451, was opened at 2011-03-08 15:18
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3203451&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: Fredrik Orderud (fredrior)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect/missing file attribute constants

Initial Comment:
The seems to be some issues with the windows file attribute constants in win32/Lib/winnt.py.
* FILE_ATTRIBUTE_ENCRYPTED seems to have incorrect value.
* FILE_ATTRIBUTE_DEVICE, FILE_ATTRIBUTE_NOT_CONTENT_INDEXED and FILE_ATTRIBUTE_VIRTUAL are missing.

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

>Comment By: Mark Hammond (mhammond)
Date: 2011-11-05 21:56

Message:
Thanks - the win32con patch already seems to have been applied, but I just
imported and pushed your winnt change.

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

Comment By: Fredrik Orderud (fredrior)
Date: 2011-03-14 07:08

Message:
The constants are retrieved from my local Windows SDK in:
C:\Program Files\Microsoft SDKs\Windows\v7.1\Include\WinNT.h

I don't know if redistributing this fille is allowed, but you can find
identical typedefs in (with the exception of FILE_ATTRIBUTE_VIRTUAL):
http://source.winehq.org/source/include/winnt.h


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

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

[pywin32-bugs] [ pywin32-Patches-3433953 ] Auto complete methods of all implemented types for IDispatch

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

Patches item #3433953, was opened at 2011-11-05 14:19
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3433953&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: Oliver (otengler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Auto complete methods of all implemented types for IDispatch

Initial Comment:
The auto completion for IDispatch COM objects only processes the methods of the implemented type but not the types this type implements. E.g. when trying to auto complete a "Shell.Application" object only "WindowSwitcher" is shown (Windows 7). "Shell.Application" implements IShellApplication5. IShellApplication5 implements IShellApplication4 and so on. The patch collects all methods in a none recursive way.

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

>Comment By: Mark Hammond (mhammond)
Date: 2011-11-05 18:35

Message:
That looks pretty good to me - although I might move the pythoncom import
locally to the new function.  How would you like to be credited in the hg
log and CHANGES.txt - "Oliver Tengler"?

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

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

[pywin32-bugs] [ pywin32-Patches-3433953 ] Auto complete methods of all implemented types for IDispatch

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

Patches item #3433953, was opened at 2011-11-05 14:19
Message generated for change (Tracker Item Submitted) made by otengler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3433953&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: Oliver (otengler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Auto complete methods of all implemented types for IDispatch

Initial Comment:
The auto completion for IDispatch COM objects only processes the methods of the implemented type but not the types this type implements. E.g. when trying to auto complete a "Shell.Application" object only "WindowSwitcher" is shown (Windows 7). "Shell.Application" implements IShellApplication5. IShellApplication5 implements IShellApplication4 and so on. The patch collects all methods in a none recursive way.

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

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

[pywin32-bugs] [ pywin32-Feature Requests-3433757 ] Full LOGFONT struct implementation

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

Feature Requests item #3433757, was opened at 2011-11-04 20:29
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3433757&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: Kris Hardy (krishardy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Full LOGFONT struct implementation

Initial Comment:
The current implementation of the LOGFONT struct in Pythonwin/win32util.cpp is not complete, relative to the WinGDI.h in the Windows 7.1 SDK.  Attached is a proposed patch to support the full LOGFONT struct.

Notes:
I reordered the szFont* static strings, the documentation, the dict building order in LogFontToDict(), and the LOGFONT packing order in DictToLogFont().  This was done purely for asthetics in order to have the orders match that of the LOGFONT struct.

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

>Comment By: Mark Hammond (mhammond)
Date: 2011-11-04 22:23

Message:
Checked in as rev 4169:2113b637ed40 - thanks!

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

Comment By: Kris Hardy (krishardy)
Date: 2011-11-04 21:56

Message:
The combined patch, complete with fixes, is attached.

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

Comment By: Kris Hardy (krishardy)
Date: 2011-11-04 21:05

Message:
Thanks for the review.  Will do.

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

Comment By: Mark Hammond (mhammond)
Date: 2011-11-04 21:00

Message:
Thanks for the patches - a couple of notes:

* CHANGES.txt should have these in the "Since 216" section - 217 is yet to
be released.  In that same file, please wrap the lines to 80 chars, remove
the URL to MSDN and if you like, add your name at the end of the paragraph
- something like "(feature request 3433757 by Kris Hardy)

* Please remove the notes similar to "2011-11-02 Extended by Kris Hardy
..." - I prefer keeping those notes out of the code and let hg tell us that
- if similar notes were added for every change it would get messy pretty
quickly :)  It is fine in the CHANGES file though, as mentioned above.

* Pythonwin/win32util.cpp is indented with tabs where you have used
spaces.  Tabs should be used for consistency (oh - I see now the second
patch does that)

* In that same file, the existing comment:
 	// ??? This is missing a lot of members ???
  is now out of date, right?  If so it should be removed.

If you can generate a single new patch with those changes I'll check it
in!

Thanks,

Mark

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

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

[pywin32-bugs] [ pywin32-Feature Requests-3433757 ] Full LOGFONT struct implementation

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

Feature Requests item #3433757, was opened at 2011-11-04 20:29
Message generated for change (Comment added) made by krishardy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3433757&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: Kris Hardy (krishardy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Full LOGFONT struct implementation

Initial Comment:
The current implementation of the LOGFONT struct in Pythonwin/win32util.cpp is not complete, relative to the WinGDI.h in the Windows 7.1 SDK.  Attached is a proposed patch to support the full LOGFONT struct.

Notes:
I reordered the szFont* static strings, the documentation, the dict building order in LogFontToDict(), and the LOGFONT packing order in DictToLogFont().  This was done purely for asthetics in order to have the orders match that of the LOGFONT struct.

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

>Comment By: Kris Hardy (krishardy)
Date: 2011-11-04 21:56

Message:
The combined patch, complete with fixes, is attached.

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

Comment By: Kris Hardy (krishardy)
Date: 2011-11-04 21:05

Message:
Thanks for the review.  Will do.

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

Comment By: Mark Hammond (mhammond)
Date: 2011-11-04 21:00

Message:
Thanks for the patches - a couple of notes:

* CHANGES.txt should have these in the "Since 216" section - 217 is yet to
be released.  In that same file, please wrap the lines to 80 chars, remove
the URL to MSDN and if you like, add your name at the end of the paragraph
- something like "(feature request 3433757 by Kris Hardy)

* Please remove the notes similar to "2011-11-02 Extended by Kris Hardy
..." - I prefer keeping those notes out of the code and let hg tell us that
- if similar notes were added for every change it would get messy pretty
quickly :)  It is fine in the CHANGES file though, as mentioned above.

* Pythonwin/win32util.cpp is indented with tabs where you have used
spaces.  Tabs should be used for consistency (oh - I see now the second
patch does that)

* In that same file, the existing comment:
 	// ??? This is missing a lot of members ???
  is now out of date, right?  If so it should be removed.

If you can generate a single new patch with those changes I'll check it
in!

Thanks,

Mark

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

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

[pywin32-bugs] [ pywin32-Feature Requests-3433757 ] Full LOGFONT struct implementation

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

Feature Requests item #3433757, was opened at 2011-11-04 20:29
Message generated for change (Comment added) made by krishardy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3433757&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: Kris Hardy (krishardy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Full LOGFONT struct implementation

Initial Comment:
The current implementation of the LOGFONT struct in Pythonwin/win32util.cpp is not complete, relative to the WinGDI.h in the Windows 7.1 SDK.  Attached is a proposed patch to support the full LOGFONT struct.

Notes:
I reordered the szFont* static strings, the documentation, the dict building order in LogFontToDict(), and the LOGFONT packing order in DictToLogFont().  This was done purely for asthetics in order to have the orders match that of the LOGFONT struct.

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

>Comment By: Kris Hardy (krishardy)
Date: 2011-11-04 21:05

Message:
Thanks for the review.  Will do.

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

Comment By: Mark Hammond (mhammond)
Date: 2011-11-04 21:00

Message:
Thanks for the patches - a couple of notes:

* CHANGES.txt should have these in the "Since 216" section - 217 is yet to
be released.  In that same file, please wrap the lines to 80 chars, remove
the URL to MSDN and if you like, add your name at the end of the paragraph
- something like "(feature request 3433757 by Kris Hardy)

* Please remove the notes similar to "2011-11-02 Extended by Kris Hardy
..." - I prefer keeping those notes out of the code and let hg tell us that
- if similar notes were added for every change it would get messy pretty
quickly :)  It is fine in the CHANGES file though, as mentioned above.

* Pythonwin/win32util.cpp is indented with tabs where you have used
spaces.  Tabs should be used for consistency (oh - I see now the second
patch does that)

* In that same file, the existing comment:
 	// ??? This is missing a lot of members ???
  is now out of date, right?  If so it should be removed.

If you can generate a single new patch with those changes I'll check it
in!

Thanks,

Mark

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

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