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

[pywin32-bugs] [ pywin32-Patches-1446700 ] 4 (+1) Patches to speed up edit-help-debug-run-cycle

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

Patches item #1446700, was opened at 2006-03-10 06:32
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1446700&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
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: 4 (+1) Patches to speed up edit-help-debug-run-cycle

Initial Comment:
Patches:

4 (+1) Patches to speed up the
edit-help-debug-run-cycle significantly

================================

pywin.framework.interact :
* Ctrl-RETURN in interactive window executes the
command directly in debugger
  ( very nice to speedup edit-run-cycle 2x; don't know
how to live without; 
    very helpful also to enter quickly into source code
of imported modules )


pywin.scintilla.view :

* Ctrl-E : "Execute region" : runs code snippet
(auto-unindented), which is marked currently in editor,
in interactive namespace
  ( very nice to speedup edit-run-cycle 2x; don't know
how to live without; )
  ( similar to Python mode in XEmacs: "Execute Region" )
  ( executes currently in __main__.__dict__  ;  to be
consistent during debugging 
    the current interp-namespace should be used; found
no easy link to get this namespace )

* Ctrl-Y : context senitive Python help for smartly
guessed words/funcs around cursor in 
"c:/python23/Doc/Python23.chm"
  ( is hardwired as of now :-( .  should take the
CHM-location out of registry )
  ( should be put to Ctrl-F1 and maybe to a framework
module; Don't know how to bind keys like Ctrl-F1 )

* Ctrl-Q : context senitive PythonWin help for smartly
guessed words/funcs around cursor parallel in 	
  hf= "c:/python23/lib/site-packages/pywin32.chm" and
  hf=r"C:\Programme\Microsoft Visual
Studio\MSDN98\98VSa\1033\msdnvs6a.col"
  (hard wiring still to be virtualized; )
  ( win32help.HtmlHelp doesn't raise if file
non-existing, but returns 0; not checked/no error
action as of now )


pywin.mfc.docview , pywin.framework.intpyapp :
* repairs the fatal call from
pywin.mfc.docview.DocTemplate._SetupSharedMenu_  into a
framework module 
  ( that problem crashed py2exe'd apps without
Pythonwin framework, but which use the DocTemplate )


=================
apply:


cd C:/python23/lib/site-packages/pythonwin/pywin
patch -b -p 4 <pywrk.diff



created with:

diff -ur  . /iBase/python/pywin-framework-patched-files
 >pywrk.diff



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

>Comment By: Mark Hammond (mhammond)
Date: 2006-03-22 21:00

Message:
Logged In: YES 
user_id=14198

Interesting - this has potential! :)

* I'm not that keen on adopting Ctrl+Enter - that is what I
personally use for 'insert \n into code' - how about
Ctrl+Shift+Enter

* OnKeyCtrlE - print statements should be removed, but a
nice concept!

* hf="c:/python23/Doc/Python23.chm" etc - as you say, "hard
wiring still to be virtualized" - please do! :)

The block:
+			else:
+				hf=r"C:\Programme\Microsoft Visual
Studio\MSDN98\98VSa\1033\msdnvs6a.col"
+				win32help.HtmlHelp(0, hf, win32help.HH_DISPLAY_INDEX, word)
+				hf= "c:/python23/lib/site-packages/pywin32.chm"
+				win32help.HtmlHelp(0, hf, win32help.HH_DISPLAY_INDEX, word)

doesn't look right as it calls HtmlHelp twice.  It would be
great to work out how to do that help properly!

* re "repairs the fatal call from
pywin.mfc.docview.DocTemplate._SetupSharedMenu_" - can you
be more specific about the problem you see?  I'm not that
happy with that patch - a patch that just changes all
refernces to _SetupSharedMenu, rather than "injecting" it,
would be preferred.

I'm happy to see the interest, and hope you can update your
patch!  Just the .diff file is fine (.patch is my
preference, but either is fine :) - no need to .zip, nor to
attach the modified files.

Cheers,

Mark

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

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

[pywin32-bugs] [ pywin32-Bugs-1449208 ] CTRL+'i' doesn't update PYTHONPATH.

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

Bugs item #1449208, was opened at 2006-03-14 10:07
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1449208&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
Submitted By: Christopher (chrism1)
Assigned to: Nobody/Anonymous (nobody)
Summary: CTRL+'i' doesn't update PYTHONPATH.

Initial Comment:



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

>Comment By: Mark Hammond (mhammond)
Date: 2006-03-22 20:41

Message:
Logged In: YES 
user_id=14198

I'm short on time, so if you could help me dig further it
would be great.

The problem will be related to the fact Pythonwin does
everything in-process, and does a simple inspection of
sys.modules to determine if a 'reload' should be done
instead of a simple import.  Its not obvious from your
package hierarchy what is going wrong - if all else fails,
I'll try and get to this myself later.

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

Comment By: Christopher (chrism1)
Date: 2006-03-14 10:10

Message:
Logged In: YES 
user_id=1471341




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

Comment By: Christopher (chrism1)
Date: 2006-03-14 10:09

Message:
Logged In: YES 
user_id=1471341

Once PYTHONPATH has been augmented for a given PythonWin 
session, the original PYTHONPATH doesn't get recreated 
until you close and reopen PythonWin.

The steps to replicate this are documented in the file "
runme.py" in the attached zip file.



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

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

[pywin32-bugs] [ pywin32-Bugs-1455181 ] makepy fails for "Spotfire.Application"

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

Bugs item #1455181, was opened at 2006-03-21 17:43
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1455181&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: Fixed
Priority: 5
Submitted By: newgene (newgene)
Assigned to: Nobody/Anonymous (nobody)
Summary: makepy fails for "Spotfire.Application"

Initial Comment:
When I run makepy from "Tools" menu for "Spotfire 
DecisionSite 8.1 Object library (1.9)", it generate 
the following error message:
=========================================
>>> Generating to C:\Python24\lib\site-
packages\win32com\gen_py\EE299BA0-BA43-11D0-96FA-
00A0C9011445x0x1x9.py
Failed to execute command:
from win32com.client import makepy;makepy.main()
Traceback (most recent call last):
  File "C:\Python24\Lib\site-
packages\pythonwin\pywin\framework\toolmenu.py", line 
103, in HandleToolCommand
    exec "%s\n" % pyCmd
  File "<string>", line 1, in ?
  File "C:\Python24\lib\site-
packages\win32com\client\makepy.py", line 362, in main
    GenerateFromTypeLibSpec(arg, f, verboseLevel = 
verboseLevel, bForDemand = bForDemand, bBuildHidden = 
hiddenSpec)
  File "C:\Python24\lib\site-
packages\win32com\client\makepy.py", line 273, in 
GenerateFromTypeLibSpec
    gencache.AddModuleToCache(info.clsid, info.lcid, 
info.major, info.minor)
  File "C:\Python24\lib\site-
packages\win32com\client\gencache.py", line 550, in 
AddModuleToCache
    mod = _GetModule(fname)
  File "C:\Python24\lib\site-
packages\win32com\client\gencache.py", line 629, in 
_GetModule
    mod = __import__(mod_name)
  File "C:\Python24\lib\site-
packages\win32com\gen_py\EE299BA0-BA43-11D0-96FA-
00A0C9011445x0x1x9.py", line 6382
     def None(self):
 SyntaxError: assignment to None
=============================================

This the piece of the code with syntax error:

=========================================
	def None(self):
		"""Puts the query device in the None 
state"""
		return self._oleobj_.InvokeTypes(3, 
LCID, 1, (24, 0), (),)
=========================================

Apparently, the problem occurs because the name 
conflict with "None". Somehow makepy.py should be able 
to catch it and get it around, or just ignore 
this "None" method.

Thanks.

Chunlei

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

>Comment By: Mark Hammond (mhammond)
Date: 2006-03-22 19:35

Message:
Logged In: YES 
user_id=14198

You can apply the following patch to win32com\build.py and
delete the generated file - or just move back to Python 2.3!
 I'll check this change in:

Index: build.py
===================================================================
RCS file:
/cvsroot/pywin32/pywin32/com/win32com/client/build.py,v
retrieving revision 1.28
diff -u -r1.28 build.py
--- build.py    13 Feb 2005 12:05:46 -0000      1.28
+++ build.py    22 Mar 2006 08:32:18 -0000
@@ -518,6 +518,10 @@
                return demunge_leading_underscores(className)
        elif iskeyword(className): # all keywords are lower case
                return string.capitalize(className)
+       elif className == 'None':
+               # assign to None is evil (and SyntaxError in
2.4) - note
+               # that if it was a global it would get
picked up below
+               className = 'NONE'
        elif is_global and __builtins__.has_key(className):
                # builtins may be mixed case.  If
capitalizing it doesn't change it,
                # force to all uppercase (eg, "None", "True"
become "NONE", "TRUE"


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

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

[pywin32-bugs] [ pywin32-Bugs-1455181 ] makepy fails for "Spotfire.Application"

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

Bugs item #1455181, was opened at 2006-03-20 22:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1455181&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: None
Priority: 5
Submitted By: newgene (newgene)
Assigned to: Nobody/Anonymous (nobody)
Summary: makepy fails for "Spotfire.Application"

Initial Comment:
When I run makepy from "Tools" menu for "Spotfire 
DecisionSite 8.1 Object library (1.9)", it generate 
the following error message:
=========================================
>>> Generating to C:\Python24\lib\site-
packages\win32com\gen_py\EE299BA0-BA43-11D0-96FA-
00A0C9011445x0x1x9.py
Failed to execute command:
from win32com.client import makepy;makepy.main()
Traceback (most recent call last):
  File "C:\Python24\Lib\site-
packages\pythonwin\pywin\framework\toolmenu.py", line 
103, in HandleToolCommand
    exec "%s\n" % pyCmd
  File "<string>", line 1, in ?
  File "C:\Python24\lib\site-
packages\win32com\client\makepy.py", line 362, in main
    GenerateFromTypeLibSpec(arg, f, verboseLevel = 
verboseLevel, bForDemand = bForDemand, bBuildHidden = 
hiddenSpec)
  File "C:\Python24\lib\site-
packages\win32com\client\makepy.py", line 273, in 
GenerateFromTypeLibSpec
    gencache.AddModuleToCache(info.clsid, info.lcid, 
info.major, info.minor)
  File "C:\Python24\lib\site-
packages\win32com\client\gencache.py", line 550, in 
AddModuleToCache
    mod = _GetModule(fname)
  File "C:\Python24\lib\site-
packages\win32com\client\gencache.py", line 629, in 
_GetModule
    mod = __import__(mod_name)
  File "C:\Python24\lib\site-
packages\win32com\gen_py\EE299BA0-BA43-11D0-96FA-
00A0C9011445x0x1x9.py", line 6382
     def None(self):
 SyntaxError: assignment to None
=============================================

This the piece of the code with syntax error:

=========================================
	def None(self):
		"""Puts the query device in the None 
state"""
		return self._oleobj_.InvokeTypes(3, 
LCID, 1, (24, 0), (),)
=========================================

Apparently, the problem occurs because the name 
conflict with "None". Somehow makepy.py should be able 
to catch it and get it around, or just ignore 
this "None" method.

Thanks.

Chunlei

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

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

[pywin32-bugs] [ pywin32-Bugs-1445947 ] NMAKE : U1073: don't know how to make 'and'

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christopher (chrism1)
Assigned to: Nobody/Anonymous (nobody)
Summary: NMAKE :  U1073: don't know how to make 'and'

Initial Comment:
Got the following build error:

NMAKE :  U1073: don't know how to make 'and'

This was using 207, python 2.4.2 (self-built), VS 
2003, and today's Platform SDK. This came immediately 
after copying scintilla.dll. Attached is the build log.

Christopher




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

>Comment By: Mark Hammond (mhammond)
Date: 2006-03-20 12:18

Message:
Logged In: YES 
user_id=14198

Thanks - will be fixed in the next release

Checking in setup.py;
new revision: 1.39; previous revision: 1.38


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

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

[pywin32-bugs] [ pywin32-Bugs-1048355 ] PyCWnd.DestroyWindow causes memory access & stack faults

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

Bugs item #1048355, was opened at 2004-10-17 01:30
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1048355&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: 8
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyCWnd.DestroyWindow causes memory access & stack faults

Initial Comment:
(b203 and all previous builds I know)
win32ui does or causes indirectly something odd with
memory in PyCWnd.DestroyWindow or WM_NCDESTROY handling.

I watch this problem for years with different win32ui
based apps, yet I'm afraid that I cannot manage to
deliver a reproducable minimalistic crashing app,
though I tried. Its a nasty stochastical memory damage
problem I think. I can reproduce the crash here with
different bigger apps in different situations. Now I
have one where I manage to crash it >90% and did 100's
of tests to isolate the problem and track it down. Thus
I found it to be caused (here) by a
PyCWnd.DestroyWindow call, but the actual crash takes
place far later when the operative message handler has
returned to the message loop. Some damage in memory. 

Some users maybe know that PythonWin itself sometimes
crashes over the year at the end of some sessions, when
debug windows were open or complex (own) window
situations or randomly. Maybe there is a connection to
the windows destroying & memory problem here.

I'm quite sure there is a unresolved nasty bug in the
DestroyWindow Process or with WM_NCDESTROY handling in
win32ui. (Think is doesn't have to do with bug 906305 -
in ui_window_destroy_window there is no CEnterLeave..
but GUI_BGN_SAVE/END_SAVE which seem to be correct )

I tell what I know about the bug:

- I use win32ui for some GUI based tools since years. I
get occasional crashes on certain window and non-modal
dialog closings in different situations. memory
problems of other code can be excluded. I traced it
down to certain window destroyings going on

- latest crash traces with registers far below
(b203/py2.3.4), yet that will probably not tell much as
there are indirect memory effects

- the example code snipet below is the final handler of
a autocompletion drop-down SysListCtrl32 in
PyCFrameWnd: Upon certain key events the window has to
be destroyed explicitely and after that some simple
computation/and pasting to clipboard occurs - then
return to message loop When
self.aclstbase.DestroyWindow() is really done then in
certain memory constellations the app crashes. Its very
sensitive and abviously random. E.g. when i start the
app and use it to a certain extent, then the bug will
not show for long etc etc.
Yet when alternative
self.aclstbase.PostMessage(WM_CLOSE) is used in that
case, the app crashes never ever in that situation.

- the memory address of access fault changes in
reproducible cases, when more or less python
computations are done after the .DestroyWindow().

- The crash bug is more often on my Win98 than my WinXP
- maybe because there is less memory ....

- In other apps (mainly on my Win98) similar problems
occur, when progress dialogs (non-modal) are destroyed
or certain othe non-modal dialogs with commctrl childs.

-In other apps (mainly on my Win98) a crash when
multiple modal dialogs have the same parent and one is
closed manually. 

- I think there are always other complex childs
(window.Wnd hooked) inside the window/dialog that shows
the closing crash. If its a simple plain dialog/window
the bug maybe doesn't show at all (but Im not sure)

- Always when the suspicios .DestroyWindow() or manual
window closing methods call can be replaces by
PostMessage(WM_CLOSE) or  PostWM_USER- or 
timer-delayed .DestroyWindow() the crash can be
99%..100% (not completely sure) eliminated.
Unfortunately .DestroyWindow() cannot be replaced always.

Suspicions/Guesses:

- Certain things are going on with the invalid CWnd*
after DestroyWindow - Cannot oversee this

- Problem when WM_NCDESTROY is handled.
 ( not sure if make sens but when I run a certain
bigger app window (lots of childs and toolbars in) and
do on the open mainframe the following
>>> mainframe.SendMessage(wc.WM_DESTROY)
0
>>> mainframe.SendMessage(wc.WM_NCDESTROY)
0
...Window focus change to still existing mainframe ->
crash. Think no matter if it makes sense, win32ui
should not raise a seg fault.?)

- Invalide Message Routing / Calling
  ( the crash is always from win32ui at bottom of the
call stack one or 3 or 2 calls later (randomly going
somewhere into the open memory)  )

- ThreadState Problems
  (Yet I reproduce the bug in apps with no extra
threads or so going on)

-  Py/C AttachObject/Detach Problem 
   ( Yet I played around on CmdTarget._obj_ level. The
problem seems not to be there. )

My debugging knowledge not enough to find out more for
now. I could make suggested tests in the crashing
apps+computers if that helps? The bug is a constant,
rare but unforseable instability problem with many of
my tools.

###########

    def AutoCompleteTake(self,sn=None):
        ....
        #cleanup auto-c window
        ##self.aclstbase.PostMessage(WM_CLOSE)
        self.aclstbase.DestroyWindow()
        ...


##############
(b203/py2.3.4 stack traces memory access errors after
crash)

MFC42! 73d99c2a()
WIN32UI! 1002a268()

MFC42! 73d99c2a()
WIN32UI! 1002a268()

008253dc()
WIN32UI! 0117f7b8()

8801129b()
MFC42! 73d332fe()
WIN32UI! 0117f7b8()

MFC42! 73d332fb()
WIN32UI! 0117f7b8()

 EAX = 00000000 EBX = 007A075A
 ECX = 01499FD8 EDX = 00000000
 ESI = 0012F4CC EDI = 01499FD8
 EIP = 73D332FB ESP = 0012F0C8
 EBP = 0012F0F0 EFL = 00000206 CS = 001B
 DS = 0023 ES = 0023 SS = 0023 FS = 0038
 GS = 0000 OV=0 UP=0 EI=1 PL=0 ZR=0 AC=0
 PE=1 CY=0

 00000014 = ????????

 ST0 = -0.14695186589127226e+1843
 ST1 = +0.00000000000000000e+0000
 ST2 = +4.30166298621518843e+3581
 ST3 = +0.00000000000000000e+0000
 ST4 = +0.00000000000000000e+0000
 ST5 = +2.10999965667724609e-0001
 ST6 = +0.00000000000000000e+0000
 ST7 = +0.00000000000000000e+0000
 CTRL = 027F STAT = 4020 TAGS = FFFF
 EIP = 1E04B200 CS = 001B DS = 0023
 EDO = 0012E3E0



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

>Comment By: Mark Hammond (mhammond)
Date: 2006-03-20 11:30

Message:
Logged In: YES 
user_id=14198

Thanks!

Checking in pythonpsheet.cpp;
new revision: 1.3; previous revision: 1.2
Checking in win32uiExt.h;
new revision: 1.9; previous revision: 1.8

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

Comment By: kxroberto (kxroberto)
Date: 2004-10-25 04:28

Message:
Logged In: YES 
user_id=972995

After getting a debug version of win32ui work, I found the
location of the problem in my case (see below) and a
temporary patch of win32uiExt.h.
The Error was in the second location: OnNotify; the change
in OnCmdMsg is just a analog guess (reasonable?). Maybe
there are even more Python-callback occasions after which a
destroyed window causes mem.acces errors.
My guess: A Pythonic Notification Handler destroys the
Window itself with .DestroyWindow()   [and also the child
yielding the notification]. Then the CWnd's "this" or the
window handle or whatever become invalid/unusable and
T::OnNotify crashes. Yet I have no complete overview why. My
patch maybe only cures the symptom on a high level.? Maybe
there are even more Python-callback calls after which a
destroyed window can cause mem.acces errors? 
Don't know if adalx's hook-less windowproc solution also
cures the problem. Also dont know if there is still another
problem with WM_NCDESTROY? 

Yet, so far all my obscure win32ui window handling crashes 
(as described) disapeared and lately maybe I can fullfill my
statement to a collage: Pythonic MFC apps never crash hard
but only yield pleasant python exceptions...

cvs diff win32uiExt.h (in directory
C:\devel\pywin\pywin32\Pythonwin\)
Index: win32uiExt.h
===================================================================
RCS file: /cvsroot/pywin32/pywin32/Pythonwin/win32uiExt.h,v
retrieving revision 1.5
diff -r1.5 win32uiExt.h
70c70,72
< 		 else
---
> 		else {
> 			if (!IsWindow( this->m_hWnd ))
> 				return TRUE;			
71a74
> 		}
77c80,82
< 		else
---
> 		else {
> 			if (!IsWindow( ((NMHDR*)lParam)->hwndFrom ))
> 				return TRUE;			
78a84
> 		}

*****CVS exited normally with code 1*****





MSVC6++ Debugger stopped here (2nd function from top of stack):
--------

	virtual BOOL OnNotify (WPARAM wParam, LPARAM lParam,
LRESULT *pResult) {
		// yield to Python first
		if (Python_OnNotify (this, wParam, lParam, pResult))
			return TRUE;
		else
====> return T::OnNotify (wParam, lParam, pResult);
	}

MFC42! 73d332fb()
CPythonWndFramework<CFrameWnd>::OnNotify(CPythonWndFramework<CFrameWnd>
* const 0x00e8ef38 {CPythonWndFramework<CFrameWnd>
hWnd=0x0082558c}, unsigned int 1943215600, long 777, long *
0x0012f4cc) line 78 + 10 bytes
MFC42! 73d31df0()
MFC42! 73d31cea()
MFC42! 73d31c73()
MFC42! 73d31bfb()
MFC42! 73d31bba()
USER32! 77d13a50()
USER32! 77d13b1f()
USER32! 77d144f5()
USER32! 77d14525()
NTDLL! 77f65da3()
USER32! 77d154b4()
COMCTL32! 773156f8()
COMCTL32! 773272ed()
COMCTL32! 77327406()
USER32! 77d13a50()
USER32! 77d13b1f()
USER32! 77d15b2c()
USER32! 77d15f73()
MFC42! 73d320f2()
MFC42! 73d31d01()
MFC42! 73d31c73()
MFC42! 73d31bfb()
MFC42! 73d31bba()
USER32! 77d13a50()
USER32! 77d13b1f()
USER32! 77d13d79()
USER32! 77d14374()


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

Comment By: Adal Chiriliuc (adalx)
Date: 2004-10-21 08:54

Message:
Logged In: YES 
user_id=1067739

Since I can't upload the patch here I'll put it into the
Patches section.

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

Comment By: Mark Hammond (mhammond)
Date: 2004-10-20 10:11

Message:
Logged In: YES 
user_id=14198

I'd be interested in a look at the patch.

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

Comment By: Adal Chiriliuc (adalx)
Date: 2004-10-20 09:48

Message:
Logged In: YES 
user_id=1067739

WM_NCDESTROY is handled in a funny way by Pythonwin.
Actually, if I recall correctly, ALL messages are handled
differently that you would normally expect in a MFC app.

Messages are not received the usual way, using MFC message
handlers. Instead a Windows message hook is installed which
intercepts messages and dispatches them.

I also had problems because WM_NCDESTORY, but they were of a
different nature (so I remember). To solve them I removed
the message hooks (which the Platform SDK says it can
significantly slow you down) and converted win32ui to use
normal message dispatching. This was kind of hard and I'm
not sure I did it 100% correctly.

If you want, I can make a patch against pywin32 build 203
for you to try and see if it solves your problem.


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

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

[pywin32-bugs] [ pywin32-Patches-1449736 ] Patch for #1048355: DestroyWindow causes memory access err..

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

Patches item #1449736, was opened at 2006-03-15 04:09
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1449736&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
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for #1048355: DestroyWindow causes memory access err..

Initial Comment:
This small patch solves #1048355 :

After e.g. a call  to Python_OnNotify or
Python_OnCmdMsg  the MFC window may be already gone (by
WM_DESTROY stuff etc.) and a call to "return
T::OnNotify (wParam, lParam, pResult);"  crashes with
mem.access error etc. 

Solves reproducably problems with win32ui-apps which
use PyCWnd.DestroyWindow etc.
(and most probably solves also some crashes on
Pythonwin IDE exits with certain windows open regarding
my statistical brain as I got those crashes no more
after applying this patch )

patches 4 locations

Robert


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

>Comment By: Mark Hammond (mhammond)
Date: 2006-03-20 11:28

Message:
Logged In: YES 
user_id=14198

Thanks!

Checking in pythonpsheet.cpp;
new revision: 1.3; previous revision: 1.2
Checking in win32uiExt.h;
new revision: 1.9; previous revision: 1.8

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

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

[pywin32-bugs] [ pywin32-Patches-1449736 ] Patch for #1048355: DestroyWindow causes memory access err..

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

Patches item #1449736, was opened at 2006-03-14 18:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1449736&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
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for #1048355: DestroyWindow causes memory access err..

Initial Comment:
This small patch solves #1048355 :

After e.g. a call  to Python_OnNotify or
Python_OnCmdMsg  the MFC window may be already gone (by
WM_DESTROY stuff etc.) and a call to "return
T::OnNotify (wParam, lParam, pResult);"  crashes with
mem.access error etc. 

Solves reproducably problems with win32ui-apps which
use PyCWnd.DestroyWindow etc.
(and most probably solves also some crashes on
Pythonwin IDE exits with certain windows open regarding
my statistical brain as I got those crashes no more
after applying this patch )

patches 4 locations

Robert


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

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

[pywin32-bugs] [ pywin32-Bugs-1448160 ] Win2003 dual-core crash on startup

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

Bugs item #1448160, was opened at 2006-03-12 07:09
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1448160&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
Submitted By: Darren (zaphod72)
Assigned to: Nobody/Anonymous (nobody)
Summary: Win2003 dual-core crash on startup

Initial Comment:
I have a dual-core Windows Server 2003 and a single-
core server also running Windows Server 2003.

On the dual-core pythonwin crashes on startup, shortly 
after displaying the UI.

On the single-core it works fine.

Here's the crash info from WinDbg -
(ee8.8b8): Access violation - code c0000005 (!!! 
second chance !!!)
eax=00000000 ebx=773e20e0 ecx=000080a2 edx=001668d8 
esi=0013fcf8 edi=7ffdf6cc
eip=00a0180c esp=0013fcd4 ebp=0013fd04 iopl=0         
nv up ei pl zr na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  
gs=0000             efl=00010246
00a0180c 58               pop     eax

And the stack trace -
ChildEBP RetAddr  Args to Child              
WARNING: Frame IP not in any known module. Following 
frames may be wrong.
0013fcd0 77387050 000080a2 00000000 00000000 0xa0180c
0013fd04 77387dc3 00a0180c 000080a2 00000000 USER32!
UserCallDDECallback+0x23
0013fd3c 77387101 0015ca78 000080a2 00000000 USER32!
DoCallback+0x6a
0013fd74 7738e3f0 0015ca78 000004c8 0000c02c USER32!
ProcessRegistrationMessage+0xa4
0013fd8c 7739c3b7 001500ce 000004c8 0000c02c USER32!
DDEMLMotherWndProc+0x2c
0013fdb8 7739c484 7738e3ad 001500ce 000004c8 USER32!
InternalCallWinProc+0x28
0013fe30 7739c73c 00000000 7738e3ad 001500ce USER32!
UserCallWinProcCheckWow+0x151
0013fe98 7738e406 00155998 00000001 00000000 USER32!
DispatchMessageWorker+0x327
0013fea8 7c169076 00155998 00155998 00403040 USER32!
DispatchMessageA+0xf
0013feb8 7c16913e 00403040 1e055870 0013ffc0 MFC71!
AfxInternalPumpMessage+0x3e
0013fed4 1e2b6767 00403040 ffffffff 00000000 MFC71!
CWinThread::Run+0x54
0013ffc0 77e523cd 00000000 00000000 7ffdc000 win32ui!
Python_callback+0x1247
0013fff0 00000000 0040186c 00000000 78746341 kernel32!
BaseProcessStart+0x23


I didn't try to build the source. But if I can get the 
pdb files then I'd be happy to try and get some more 
information (darrenk at yahoo).
Thanks

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

Comment By: kxroberto (kxroberto)
Date: 2006-03-14 17:57

Message:
Logged In: YES 
user_id=972995

Good to get more about this dual core bug (following
#1442426 & #1441884 )

Can you maybe try this bug also with py2.3.5 / build 205 ? 
(build 207 doesn't work for py2.3). You can simply run a
second py2.3 installation parallel on your computer. Such
test would exclude the py2.4/MFC7.1 scheme as reason for the
crash. 
I sent you that win32ui with .pdb:  That should provide
detailed stack traces.

---
related:

#1442426 ,  #1441884

http://sourceforge.net/tracker/index.php?func=detail&aid=1441884&group_id=5470&atid=105470

---

I got similar user reports for a win32ui-app (build
203/MFC4.2/py2.3.5; even without pythonwin IDE). 
Unfortunately I got no stack traces.


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

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

[pywin32-bugs] [ pywin32-Bugs-1449453 ] IDE: AttributeError: butAcrossFiles

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

Bugs item #1449453, was opened at 2006-03-14 10:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1449453&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
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDE: AttributeError: butAcrossFiles

Initial Comment:
build205 / py2.3.5 :

>>> Traceback (most recent call last):
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py",
line 169, in OnInitDialog
    self.butKeepDialogOpen = self.GetDlgItem(115)
win32ui: Internal error - existing object has type
'PyCWinThread', but 'PyCButton' was requested.
win32ui: OnInitDialog() virtual handler (<bound method
FindDialog.OnInitDialog of
<pywin.scintilla.find.FindDialog instance at
0x01555828>>) raised an exception
Traceback (most recent call last):
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py",
line 209, in OnFindNext
    if self.DoFindNext() != FOUND_NOTHING and not
self.butKeepDialogOpen.GetCheck():
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py",
line 201, in DoFindNext
    params.acrossFiles = self.butAcrossFiles.GetCheck()
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\mfc\object.py",
line 18, in __getattr__
    return getattr(o, attr)
AttributeError: butAcrossFiles
win32ui: Error in Command Message handler for command
ID 109, Code 0


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

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

[pywin32-bugs] [ pywin32-Bugs-1449208 ] CTRL+'i' doesn't update PYTHONPATH.

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

Bugs item #1449208, was opened at 2006-03-13 15:07
Message generated for change (Comment added) made by chrism1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1449208&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
Submitted By: Christopher (chrism1)
Assigned to: Nobody/Anonymous (nobody)
>Summary: CTRL+'i' doesn't update PYTHONPATH.

Initial Comment:



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

>Comment By: Christopher (chrism1)
Date: 2006-03-13 15:10

Message:
Logged In: YES 
user_id=1471341




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

Comment By: Christopher (chrism1)
Date: 2006-03-13 15:09

Message:
Logged In: YES 
user_id=1471341

Once PYTHONPATH has been augmented for a given PythonWin 
session, the original PYTHONPATH doesn't get recreated 
until you close and reopen PythonWin.

The steps to replicate this are documented in the file "
runme.py" in the attached zip file.



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

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

[pywin32-bugs] [ pywin32-Bugs-1449208 ] CTRL+'i' doesn't always work.

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

Bugs item #1449208, was opened at 2006-03-13 15:07
Message generated for change (Comment added) made by chrism1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1449208&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
Submitted By: Christopher (chrism1)
Assigned to: Nobody/Anonymous (nobody)
>Summary: CTRL+'i' doesn't always work.

Initial Comment:



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

>Comment By: Christopher (chrism1)
Date: 2006-03-13 15:09

Message:
Logged In: YES 
user_id=1471341

Once PYTHONPATH has been augmented for a given PythonWin 
session, the original PYTHONPATH doesn't get recreated 
until you close and reopen PythonWin.

The steps to replicate this are documented in the file "
runme.py" in the attached zip file.



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

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

[pywin32-bugs] [ pywin32-Bugs-1449208 ] <CTRL>+'i' doesn't always work.

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

Bugs item #1449208, was opened at 2006-03-13 15:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1449208&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
Submitted By: Christopher (chrism1)
Assigned to: Nobody/Anonymous (nobody)
Summary: <CTRL>+'i' doesn't always work.

Initial Comment:



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

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

[pywin32-bugs] [ pywin32-Bugs-1448160 ] Win2003 dual-core crash on startup

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

Bugs item #1448160, was opened at 2006-03-12 01:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1448160&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
Submitted By: Darren (zaphod72)
Assigned to: Nobody/Anonymous (nobody)
Summary: Win2003 dual-core crash on startup

Initial Comment:
I have a dual-core Windows Server 2003 and a single-
core server also running Windows Server 2003.

On the dual-core pythonwin crashes on startup, shortly 
after displaying the UI.

On the single-core it works fine.

Here's the crash info from WinDbg -
(ee8.8b8): Access violation - code c0000005 (!!! 
second chance !!!)
eax=00000000 ebx=773e20e0 ecx=000080a2 edx=001668d8 
esi=0013fcf8 edi=7ffdf6cc
eip=00a0180c esp=0013fcd4 ebp=0013fd04 iopl=0         
nv up ei pl zr na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  
gs=0000             efl=00010246
00a0180c 58               pop     eax

And the stack trace -
ChildEBP RetAddr  Args to Child              
WARNING: Frame IP not in any known module. Following 
frames may be wrong.
0013fcd0 77387050 000080a2 00000000 00000000 0xa0180c
0013fd04 77387dc3 00a0180c 000080a2 00000000 USER32!
UserCallDDECallback+0x23
0013fd3c 77387101 0015ca78 000080a2 00000000 USER32!
DoCallback+0x6a
0013fd74 7738e3f0 0015ca78 000004c8 0000c02c USER32!
ProcessRegistrationMessage+0xa4
0013fd8c 7739c3b7 001500ce 000004c8 0000c02c USER32!
DDEMLMotherWndProc+0x2c
0013fdb8 7739c484 7738e3ad 001500ce 000004c8 USER32!
InternalCallWinProc+0x28
0013fe30 7739c73c 00000000 7738e3ad 001500ce USER32!
UserCallWinProcCheckWow+0x151
0013fe98 7738e406 00155998 00000001 00000000 USER32!
DispatchMessageWorker+0x327
0013fea8 7c169076 00155998 00155998 00403040 USER32!
DispatchMessageA+0xf
0013feb8 7c16913e 00403040 1e055870 0013ffc0 MFC71!
AfxInternalPumpMessage+0x3e
0013fed4 1e2b6767 00403040 ffffffff 00000000 MFC71!
CWinThread::Run+0x54
0013ffc0 77e523cd 00000000 00000000 7ffdc000 win32ui!
Python_callback+0x1247
0013fff0 00000000 0040186c 00000000 78746341 kernel32!
BaseProcessStart+0x23


I didn't try to build the source. But if I can get the 
pdb files then I'd be happy to try and get some more 
information (darrenk at yahoo).
Thanks

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

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

[pywin32-bugs] [ pywin32-Patches-1446700 ] 4 (+1) Patches to speed up edit-help-debug-run-cycle

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

Patches item #1446700, was opened at 2006-03-09 20:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1446700&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
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: 4 (+1) Patches to speed up edit-help-debug-run-cycle

Initial Comment:
Patches:

4 (+1) Patches to speed up the
edit-help-debug-run-cycle significantly

================================

pywin.framework.interact :
* Ctrl-RETURN in interactive window executes the
command directly in debugger
  ( very nice to speedup edit-run-cycle 2x; don't know
how to live without; 
    very helpful also to enter quickly into source code
of imported modules )


pywin.scintilla.view :

* Ctrl-E : "Execute region" : runs code snippet
(auto-unindented), which is marked currently in editor,
in interactive namespace
  ( very nice to speedup edit-run-cycle 2x; don't know
how to live without; )
  ( similar to Python mode in XEmacs: "Execute Region" )
  ( executes currently in __main__.__dict__  ;  to be
consistent during debugging 
    the current interp-namespace should be used; found
no easy link to get this namespace )

* Ctrl-Y : context senitive Python help for smartly
guessed words/funcs around cursor in 
"c:/python23/Doc/Python23.chm"
  ( is hardwired as of now :-( .  should take the
CHM-location out of registry )
  ( should be put to Ctrl-F1 and maybe to a framework
module; Don't know how to bind keys like Ctrl-F1 )

* Ctrl-Q : context senitive PythonWin help for smartly
guessed words/funcs around cursor parallel in 	
  hf= "c:/python23/lib/site-packages/pywin32.chm" and
  hf=r"C:\Programme\Microsoft Visual
Studio\MSDN98\98VSa\1033\msdnvs6a.col"
  (hard wiring still to be virtualized; )
  ( win32help.HtmlHelp doesn't raise if file
non-existing, but returns 0; not checked/no error
action as of now )


pywin.mfc.docview , pywin.framework.intpyapp :
* repairs the fatal call from
pywin.mfc.docview.DocTemplate._SetupSharedMenu_  into a
framework module 
  ( that problem crashed py2exe'd apps without
Pythonwin framework, but which use the DocTemplate )


=================
apply:


cd C:/python23/lib/site-packages/pythonwin/pywin
patch -b -p 4 <pywrk.diff



created with:

diff -ur  . /iBase/python/pywin-framework-patched-files
 >pywrk.diff



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

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

[pywin32-bugs] [ pywin32-Bugs-1445947 ] NMAKE : U1073: don't know how to make 'and'

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

Bugs item #1445947, was opened at 2006-03-08 13:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1445947&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
Submitted By: Christopher (chrism1)
Assigned to: Nobody/Anonymous (nobody)
Summary: NMAKE :  U1073: don't know how to make 'and'

Initial Comment:
Got the following build error:

NMAKE :  U1073: don't know how to make 'and'

This was using 207, python 2.4.2 (self-built), VS 
2003, and today's Platform SDK. This came immediately 
after copying scintilla.dll. Attached is the build log.

Christopher




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

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

[pywin32-bugs] [ pywin32-Bugs-1442426 ] Crash on startup with Windows 2003 and AMD X2 dual core

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

Bugs item #1442426, was opened at 2006-03-03 13:07
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1442426&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
Submitted By: Luke Plant (lukeplant)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash on startup with Windows 2003 and AMD X2 dual core 

Initial Comment:
I have installed Python 2.4 and Pythonwin build 207 on
a brand new Windows Server 2003 system.  When I run
pythonwin, it crashes after drawing the mainwindow and
part way through drawing the interactive window. I get
the following error message:

> The instruction at "0x00affa6c" referenced memory at 
> "0x00affa6c".  The memory could not be "written"

I have installed exactly the same version of pythonwin
on an almost identical system, but with different
hardware, so I suspect it is something to do with the
processor on this one.  The processor is an "AMD 64 X2
Dual Core 4400+".

Visual Studio attempts to debug it, but of course there
isn't any source code.  In the disassembly listing, the
following line is highlighted:

00AFFA6C  pop         eax 

I can give more than this if required, but I don't know
whether it would be useful (or how much to include).

Thanks.

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

Comment By: Robert Kiendl (kxroberto)
Date: 2006-03-08 16:38

Message:
Logged In: YES 
user_id=972995

A serious issue. As more and more dual core CPUs are on the
end user market I got reports of similar crashes in win32ui
apps: See the dual core bugs posted as bug# 1441884 (by
mismatch?) in the Python project.
http://sourceforge.net/tracker/index.php?func=detail&aid=1441884&group_id=5470&atid=105470
The dual core problems seems more to be in Pythonwin, as
there are all those indications to MFC dll's.

This problem is different from the crash-bugs 1048355
(unresolved in the normal build since long time; but users
with the patch also have the dual core problem) and 1445659
(new bug in 206 & 207).

Robert


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

Comment By: Luke Plant (lukeplant)
Date: 2006-03-03 15:19

Message:
Logged In: YES 
user_id=621233

I've discovered that it is related to 'DEP' (Data Execution
Prevention) which is available with some AMD processors. 
You can disable this on a per-process basis in Windows - go
to Control Panel -> System -> 'Advanced' tab -> Performance
'Settings' -> 'DEP' tab

It's still a bug in pythonwin though.

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

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

[pywin32-bugs] [ pywin32-Bugs-1445659 ] build 207 & 206 for py2.3 : pythonwin.exe startup crash

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

Bugs item #1445659, was opened at 2006-03-08 15:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1445659&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
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: build 207 & 206 for py2.3 : pythonwin.exe startup crash

Initial Comment:
build 207 (and 206) for Python 2.3(.5)
on WinXP Home (SR1) / normal single core CPU : 

Pythonwin.exe doesn't start: Crash:

Instruction 0x1e037435 points to memory 0x00000028...

MSVC++ Runtime Library : Runtime Error!

debugger shows stack:

PYTHON23! 1e037435()
MFC42! 73d3c10b()
MFC42! 73d42167()


build 205 for 2.3 is the last build which starts ok. I
lived so far with build 203 - also ok.

reproducable.

-------

Additional Notes:

When I start 207/2.3's framework with attached
startupframework.py (or start_pythonwin.pyw) instead of
pythonwin.exe it works! (?)

When I try to use 205/2.3's 5 files
pythonwin.exe,win32ui.pyd,win32uiole.pyd,dde.pyd,scintilla.dll
in otherwise 207/2.3, the crash is the same. guess its
something in the plain python code or win32 modules.

build 207 pythonwin.exe for py2.4 works on my machine,
the described bug seems specific for py2.3 (/MFC42?).

starting build 207/2.4 with start_pythonwin.pyw is (of
course) also ok. But when I close the framework, one of
that old win32ui close crash bug winks: memory
violation at (see also PS below):

011402a0()
MFC71! 7c176020()
MFC71! 7c16e0b0()
MFC71! 7c16e14f()
MFC71! 7c16e1b8()
MFC71! 7c16e1f6()
USER32! 77d18654()
USER32! 77d18723()
USER32! 77d19153()
USER32! 77d19196()
NTDLL! 77f65da3()
WIN32UI! 1e2c8691()
PYTHON24! 1e1ae378()


Robert

--------

PS: Serious old bug 1048355 (causes crashes) in win32ui
is still not addressed in 207. T::OnNotify crashes when
e.g. WM_NCDESTROY pulls off the underlying window out
of MFC during Python_OnNotify. To get my apps stable i
have to patch OnNotify & OnCmdMsg in win32uiExt.h (only
2 lines added) as shown below (suspect
CPythonRichEditView::OnNotify and
CPythonPropertySheet::OnNotify and
CPythonDocTemp<P>::OnCmdMsg and
CPythonRichEditView::OnCmdMsg and
CPythonPropertySheet::OnCmdMsg to require all the same
patch - often when win32ui apps close, strange crashes
occure... ):

	virtual BOOL OnCmdMsg( UINT nID, int nCode, void*
pExtra, AFX_CMDHANDLERINFO*pHandlerInfo )
	{
		// yield to Python first
		if (Python_OnCmdMsg (this, nID, nCode, pExtra,
pHandlerInfo))
			return TRUE;
		else {
			if (!IsWindow( this->m_hWnd ))
				return TRUE;			
			return T::OnCmdMsg (nID, nCode, pExtra, pHandlerInfo);
		}
	}
	virtual BOOL OnNotify (WPARAM wParam, LPARAM lParam,
LRESULT *pResult) {
		// yield to Python first
		if (Python_OnNotify (this, wParam, lParam, pResult))
			return TRUE;
		else {
			if (!IsWindow( this->m_hWnd ))
			//if (!IsWindow( ((NMHDR*)lParam)->hwndFrom ))
				return TRUE;			
			return T::OnNotify (wParam, lParam, pResult);
		}
	}



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

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

[pywin32-bugs] [ pywin32-Bugs-1445113 ] GetMenu not exported (even though SetMenu is)

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

Bugs item #1445113, was opened at 2006-03-07 15:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1445113&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
Submitted By: Chad Austin (aegis)
Assigned to: Nobody/Anonymous (nobody)
Summary: GetMenu not exported (even though SetMenu is)

Initial Comment:
I noticed a perhaps obvious omission today: 
win32gui.SetMenu is exported and works as expected, but
there is no corresponding win32gui.GetMenu.


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

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

[pywin32-bugs] [ pywin32-Bugs-1444675 ] Typo error in netbios.py

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

Bugs item #1444675, was opened at 2006-03-07 16:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1444675&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
Submitted By: helium (helium-sun)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typo error in netbios.py

Initial Comment:
netbios.py line 169:

FIND_NAME_BUFFER_ITEMS = [
    (UCHAR,   "length"),
    (UCHAR,   "access_control"),
    (UCHAR,   "frame_control"),
    ("6s"   "destination_addr"),
         ^^^
    ("6s", "source_addr"), 
    ("18s", "routing_info"),
]

',' is lost

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

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

[pywin32-bugs] [ pywin32-Bugs-1444381 ] lines may be mistaken for exception lines

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

Bugs item #1444381, was opened at 2006-03-06 20:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1444381&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
Submitted By: Erik Andersén (erik_andersen)
Assigned to: Nobody/Anonymous (nobody)
Summary: lines may be mistaken for exception lines

Initial Comment:
PythonWin 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.
1310 32 bit (Intel)] on win32.
Portions Copyright 1994-2004 Mark Hammond 
(mha...@sk...) - see 'Help/About 
PythonWin' for further copyright informatio
>>> print 'File "<xxx>", line 1324' 

System will respond with "Cannot open this file"

The cause is in winout.HandleSpecialLine.

The input line matches the input line, so the 
interactive shell thinks is is a traceback line and 
tries to jump to the file <xxx>.

Similarly,

>>> s = 'File' + ' "<xxx>", line 1324'
>>> s
'File "<xxx>", line 1324'
>>> 1+1

gives the same error since HandleSpecialLine also
tries the preceeding line.

The solution is to add

		if line.startswith('>>>') or line.
startswith('...'):
			return 0

near the beginning of HandleSpecialLine.

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

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

[pywin32-bugs] [ pywin32-Bugs-1442426 ] Crash on startup with Windows 2003 and AMD X2 dual core

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

Bugs item #1442426, was opened at 2006-03-03 12:07
Message generated for change (Comment added) made by lukeplant
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1442426&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
Submitted By: Luke Plant (lukeplant)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash on startup with Windows 2003 and AMD X2 dual core 

Initial Comment:
I have installed Python 2.4 and Pythonwin build 207 on
a brand new Windows Server 2003 system.  When I run
pythonwin, it crashes after drawing the mainwindow and
part way through drawing the interactive window. I get
the following error message:

> The instruction at "0x00affa6c" referenced memory at 
> "0x00affa6c".  The memory could not be "written"

I have installed exactly the same version of pythonwin
on an almost identical system, but with different
hardware, so I suspect it is something to do with the
processor on this one.  The processor is an "AMD 64 X2
Dual Core 4400+".

Visual Studio attempts to debug it, but of course there
isn't any source code.  In the disassembly listing, the
following line is highlighted:

00AFFA6C  pop         eax 

I can give more than this if required, but I don't know
whether it would be useful (or how much to include).

Thanks.

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

>Comment By: Luke Plant (lukeplant)
Date: 2006-03-03 14:19

Message:
Logged In: YES 
user_id=621233

I've discovered that it is related to 'DEP' (Data Execution
Prevention) which is available with some AMD processors. 
You can disable this on a per-process basis in Windows - go
to Control Panel -> System -> 'Advanced' tab -> Performance
'Settings' -> 'DEP' tab

It's still a bug in pythonwin though.

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

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

[pywin32-bugs] [ pywin32-Bugs-1442426 ] Crash on startup with Windows 2003 and AMD X2 dual core

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

Bugs item #1442426, was opened at 2006-03-03 12:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1442426&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
Submitted By: Luke Plant (lukeplant)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash on startup with Windows 2003 and AMD X2 dual core 

Initial Comment:
I have installed Python 2.4 and Pythonwin build 207 on
a brand new Windows Server 2003 system.  When I run
pythonwin, it crashes after drawing the mainwindow and
part way through drawing the interactive window. I get
the following error message:

> The instruction at "0x00affa6c" referenced memory at 
> "0x00affa6c".  The memory could not be "written"

I have installed exactly the same version of pythonwin
on an almost identical system, but with different
hardware, so I suspect it is something to do with the
processor on this one.  The processor is an "AMD 64 X2
Dual Core 4400+".

Visual Studio attempts to debug it, but of course there
isn't any source code.  In the disassembly listing, the
following line is highlighted:

00AFFA6C  pop         eax 

I can give more than this if required, but I don't know
whether it would be useful (or how much to include).

Thanks.

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

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

[pywin32-bugs] [ pywin32-Bugs-1198857 ] Installation failure : Critical

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

Bugs item #1198857, was opened at 2005-05-10 18:24
Message generated for change (Settings changed) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1198857&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
Submitted By: Neil J. McLeish (neiljmac)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installation failure : Critical

Initial Comment:
pywin32-204.win32-py2.2 installer says it needs Python
2.2 in the registry.
I have ActiveState Python 2.4 installed.  What gives?

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

Comment By: Neil J. McLeish (neiljmac)
Date: 2005-05-10 22:53

Message:
Logged In: YES 
user_id=187020

Thanks for that Roger.

That'll be a 'DOH!' from me then :)

Neil

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

Comment By: Roger Upole (rupole)
Date: 2005-05-10 21:23

Message:
Logged In: YES 
user_id=771074

You'll need the installer for Python 2.4.  The filename given is 
for python 2.2.
        Roger


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

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

[pywin32-bugs] [ pywin32-Bugs-1208544 ] setup.py fails to find most recent platform SDK

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

Bugs item #1208544, was opened at 2005-05-26 01:33
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1208544&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: Fixed
Priority: 5
Submitted By: PJ Tremblay (piairjooles)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py fails to find most recent platform SDK

Initial Comment:
The most recent Microsoft Platform SDK installation
isn't found (as of date of submission of this bug).

The key name I have in the registry is:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MicrosoftSDK\InstalledSDKs\8F9E5EF3-A9A5-491B-A889-C58EFFECE8B3\Installed
Dir

whereas setup.py is looking for it in:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MicrosoftSDK\Directories\Installed
 Dir

Creating a new string value at the latter key patches
the problem.


Note:  the Platform SDK readme header says: Windows
Server 2003 SP1 SDK Release Notes

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

>Comment By: Mark Hammond (mhammond)
Date: 2006-02-27 23:08

Message:
Logged In: YES 
user_id=14198

Thanks Trent - I think this is all checked in

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

Comment By: Trent Mick (tmick)
Date: 2005-06-17 09:51

Message:
Logged In: YES 
user_id=34892

I've just sent a patch to MarkH for review for this bug. I'm
not sure why I don't see a mechanism to attach patches to
this bug... I can for bugs in the Python project here on sf.net.

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

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