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

[pywin32-bugs] [ pywin32-Bugs-1119908 ] CastTo/QueryInterface problem

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

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

Category: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: oleaw (oleaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: CastTo/QueryInterface problem

Initial Comment:
In the COM API I am using, the following is provided: To 
create a new patient object I have to cast the Patient 
manager interface to the IDIContstructor interface. 

PatMgr: IDIPatientMgr;
NewPat: IDIPatient;
...
PatMgr := DISession.GetManagerById(miPatient) as 
IDIPatientMgr;
NewPat := (PatMgr as IDIConstructor).CreateNew as 
IDIPatient;
//edit the patient...
//Save the changes
(NewPat as IDIEdit).Save;


In python I have written the following code.

miPerson = 26        
try:
   PersonMgr
except NameError:
   PersonMgr = self.__dips_api.GetManagerById(miPerson)
else:
   print "PersonMgr eksisterer"
      
NewPerson = CastTo(PersonMgr, 'IDIPersonMgr')

This casts PersonMgr to the right Interface.
My problem is that once I use the CastTo function all of 
my other functions cease to work. Apparently all the 
objects are wrapped in PyIUnkown, and python is no 
longer able to find their appropriate type. This problem 
will persist until delete the automatically generated 
python COM code and restart IDLE.
All the interfaces I am using are IDispatch.

I have also tried to alternatively cast the interface with
PersonMgr.QueryObject(‘IDIConstructor’) and
Dispatch(PersonMgr , None, 'IDIContructor'), 
but these functions are unable to find the interface.
Have also tried with makepy

Can anyone provide information on how to make CastTo 
work, (can I unwrap the PyIUnknown wrapper?)


Ole A


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

>Comment By: oleaw (oleaw)
Date: 2005-02-10 09:14

Message:
Logged In: YES 
user_id=1216110

The line 
NewPerson = CastTo(PersonMgr, 'IDIPersonMgr') 
is
NewPerson = CastTo(PersonMgr, 'IDIConstructor') 
and IDIContructor should be IDIConstructor

This however is not the problem

Ole A

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

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

[pywin32-bugs] [ pywin32-Bugs-1119908 ] CastTo/QueryInterface problem

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

Bugs item #1119908, was opened at 2005-02-10 09:06
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=1119908&group_id=78018

Category: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: oleaw (oleaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: CastTo/QueryInterface problem

Initial Comment:
In the COM API I am using, the following is provided: To 
create a new patient object I have to cast the Patient 
manager interface to the IDIContstructor interface. 

PatMgr: IDIPatientMgr;
NewPat: IDIPatient;
...
PatMgr := DISession.GetManagerById(miPatient) as 
IDIPatientMgr;
NewPat := (PatMgr as IDIConstructor).CreateNew as 
IDIPatient;
//edit the patient...
//Save the changes
(NewPat as IDIEdit).Save;


In python I have written the following code.

miPerson = 26        
try:
   PersonMgr
except NameError:
   PersonMgr = self.__dips_api.GetManagerById(miPerson)
else:
   print "PersonMgr eksisterer"
      
NewPerson = CastTo(PersonMgr, 'IDIPersonMgr')

This casts PersonMgr to the right Interface.
My problem is that once I use the CastTo function all of 
my other functions cease to work. Apparently all the 
objects are wrapped in PyIUnkown, and python is no 
longer able to find their appropriate type. This problem 
will persist until delete the automatically generated 
python COM code and restart IDLE.
All the interfaces I am using are IDispatch.

I have also tried to alternatively cast the interface with
PersonMgr.QueryObject(‘IDIConstructor’) and
Dispatch(PersonMgr , None, 'IDIContructor'), 
but these functions are unable to find the interface.
Have also tried with makepy

Can anyone provide information on how to make CastTo 
work, (can I unwrap the PyIUnknown wrapper?)


Ole A


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

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

[pywin32-bugs] [ pywin32-Bugs-1119799 ] Active Debugging bugs

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

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

Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kiriakos Vlahos (kvlahos)
Assigned to: Nobody/Anonymous (nobody)
Summary: Active Debugging bugs

Initial Comment:
I know that Active Scripting is a bit passe, but I have
written a "Smart" Active Scripting host that works well
with VBScript and JScript and I thought that it would
cool if it worked with Python.  It did not work out of
the box.  I played a bit with PythonWin and I have made
it work after introducing various changes.  Below I
discribed the resolved and outstanding issues. 
(pywin32 build 203)

a)  ActiveScriptDebug fails when queried for IActiveScript
The class ActiveScriptDebug in debug.py implements the
IActiveScriptDebug interface.  Hosts get access to this
interface by quering the IActiveScript interface. 
According to the MS specification the
IActiveScriptDebug should provide back the
IActiveScript inteface when queried for it.   Indeed
this happens when the host calls GetScriptBlockInfo on
 IDebugDocumentHelper when handling breakpoints and the
like (and in a couple of other cases).  When this
happens ActiveScript debug does not return a valid
Interface and the Process Debug Manager (PDM) raises an
exception preventing debugging.  A workaround is to
modify following method:

	def _query_interface_(self, iid):
		trace("DebuggerQI with", iid)
		return _wrap(self.debugMgr.scriptEngine, iid)

Of course the Interface returned is not the same as the
original IActiveScript and the host should discard it.
 But it keeps PDM happy.  I could find no way to
retrieve the original interface.  Any ideas?

b)  Adb.OnDisconnect debugger
This method should set the appDebugger to None. 
Checking the existance of appDebugger provides a good
way to see whether debugging should take palce or not.
 (see next issue).  There is no reason to slow down
code if an appDebugger does not exist.  Modified method:

	def OnDisconnectDebugger(self):
		traceenter("OnDisconnectDebugger")
		self.appDebugger = None #KV
		self.set_quit()

c)  Debugger tracing never starts
If I understand it well, debugging is supposed to start
after a call to OnEnterScript.  This method finds the
right stackframe, passes it to adb.SetupAXDebugging
which calls  _BreakFlagsChanged.  This last method sets
the frame.f_trace to trace_dispatch.   However, just
setting f_trace is not enough to start debugger
tracing.  sys.settrace needs to be called somewhere, or
else the running of the code should be done through the
run, runexec, runevall etc. methods of the debugger. 
This second method is much better I think (avoids
fiddling with the frames directly and traces only the
script code), but I have implemented the first method
by modifying :

	def OnEnterScript(self):
		trace("OnEnterScript")
		baseFrame = sys._getframe().f_back
		self.adb.SetupAXDebugging(baseFrame)
		if self.adb.appDebugger:
			sys.settrace(self.adb.trace_dispatch)

d)  Debugger tracing never stops (after the above change)
Debugging is supposed to stop when the
adb.OnDisconnectDebugger is called since this calls the
set_quit method which in turn calls sys.settrace(None).
 However, OnDisconnectDebugger is called on a different
thread from the Script thread (not 100% sure on this)
and the effect is that the Script thread (and PyWin)
carries on beign traced by the debugger.  I have modified:
	def OnLeaveScript(self):
		trace("OnLeaveScript")
		self.adb.ResetAXDebugging()
		sys.settrace(None);  # KV
Implementing the second solution described above would
be simpler and cleaner than this though.

e)  Code positions are reported incorrectly
With the above changes I could set and handle
breakpoints examine the stack frames and get access to
the local variables just fine. One problem though was
that the posisitions of the breakpoints and errors
returned by PyWin were incorrect.   This is due to the
fact that when the Engine receives code from the hosts
it removes the CRs using RemoveCR in framework.py.  In
calculating the position of the various lines it does
so without taking account of the CRs that exist in the
host code.  One solution to this problem is to keep the
code as defined by the host and only apply RemoveCR
prior to submitting the code to the interpreter (not
implemented).  

f)  DebugProperty.SetValueAsString causes Access violation.
DebugProperty.GetPropertyInfo in unit expressions.py
works fine.  DebugProperty.SetValueAsString on the
other hand calls  RaiseNotImpl which would also be OK.
 However my host gets an access violation when calling
this method and the code in SetValueAsString is never
called (I added a trace statement to check this). 
Could this be a problem with the C part of PyWin?? 
This feature works well with other engines.  By the way
it wouldn't be too difficult to implement this.  All
you would need is to pass the stackFrame to the
__init__ of DebugProperty and then just say in
SetValueAsString:
exec(self.name+"="+self.value, stackFrame.f_locals,
stackFrame.f_globals)
with exception handling of course.

The followiing are feature requests rather than bugs:

g)  Partial InvokeEx support for ScriptDispatch
It is fairly easy to provide partial InvokeEx support
to ScriptDispatch by overriding two mehtods in
StrictDynamicPolicy

class
StrictDynamicPolicy(win32com.server.policy.DynamicPolicy):
	def _wrap_(self, object):
		win32com.server.policy.DynamicPolicy._wrap_(self, object)
		if hasattr(self._obj_, 'scriptNamespace'):
			for name in dir(self._obj_.scriptNamespace):
				self._dyn_dispid_to_name_[self._getdispid_(name,0)]
= name    

	def _getmembername_(self, dispid):
		try:
			return str(self._dyn_dispid_to_name_[dispid])
		except KeyError:
			raise
COMException(scode=winerror.DISP_E_UNKNOWNNAME,
desc="Name not found")	

h)  Module support
Currently ParseScriptText in Framework.py ignores the
second argument ItemName and compiles all code in the
module globalNameSpaceModule.  The proper (Microsoft
Engines like) way of handling ItemName is to compile
into globalNameSpaceModule only when ItemName is None
and create new modules for different ItemNames.  The
globalNameSpaceModule should be imported into the other
modules so that all members of globalNameSpaceModule
are visible in other modules.  

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

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

[pywin32-bugs] [ pywin32-Feature Requests-1114447 ] Need documentation separate from kit

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

Feature Requests item #1114447, was opened at 2005-02-01 22:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1114447&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary Feldman (garyfx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Need documentation separate from kit

Initial Comment:
I've found a number of pointers to this package, but
nothing - not even an FAQ entry - giving a detailed
list of the current contents or installation
requirements/instructions.  

The closest I've found is the page at
http://www.python.org/windows/win32.  But that isn't
very clear or consistent, and just confuses things
more. I'd like to see a list that is a bit more
detailed (at least to the level of "base services,
common controls, etc." - as listed in the MSDN docs),
without inconsistencies (are memory mapped files part
of the API or aren't they).

I'd also like basic installation instructions:  Which
versions of Python are supported, does the installation
give me a choice of which components to install, what
changes it makes to the registry, how to uninstall,
etc.  The fact that the install is an .exe and not an
.msi or setup.exe opens some questions that need to be
addressed, even if it's just to say that the .exe is a
standard windows installation kit.

Gary

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

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

[pywin32-bugs] [ pywin32-Feature Requests-1110245 ] Integration with pychecker

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

Feature Requests item #1110245, was opened at 2005-01-26 21:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1110245&group_id=78018

Category: pythonwin
Group: Next Release (example)
Status: Open
Resolution: None
Priority: 5
Submitted By: Ramon M. Felciano (felciano)
Assigned to: Nobody/Anonymous (nobody)
Summary: Integration with pychecker

Initial Comment:
Hi --

It would be nice to include integration with PyChecker 
(http://sourceforge.net/projects/pychecker) in the same 
way there is TabNanny integration. A Google search 
comes up with the cfg below to do it yourself by adding 
a new pywin editor configuration (slightly modified below 
to handle pathnames with spaces and to add messaging 
to the status bar). It would be nice to ship this out-of-
the-box to encourage adoption. Barring that, maybe add 
a pointer / reference to these instructions in the FAQ?

Thanks!

Ramon


[General]
# place this in <pythondir>\Lib\site-
packages\Pythonwin\pywinBased On = Default

[Keys:Editor]
Shift+Ctrl+v      = checksource

[Extensions]
def checksource(editor_window, event):
    import pywin.framework.scriptutils
    import os
    import re
    import win32ui
    
    filename = 
pywin.framework.scriptutils.GetActiveFileName()
    win32ui.SetStatusText("PyChecker is checking your 
source..." , True)
    messages = os.popen(r'<pythondir>\pychecker.bat "%
s"' % filename)
    for message in messages.xreadlines():
        print re.sub(r"(.*):(\d+):(.*)", r'File "\1", line \2, 
\3', message.strip())
    messages.close()
    win32ui.SetStatusText("PyChecker is done checking 
your source." , True)



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

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

[pywin32-bugs] [ pywin32-Bugs-1085454 ] Py 2.4 + MS Excel COM --> crash

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

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

Category: com
Group: None
>Status: Open
>Resolution: None
Priority: 5
Submitted By: sitecap (sitecap)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py 2.4 + MS Excel COM --> crash

Initial Comment:
Any code that tries to dispatch an Excel (2003)
application ends up crashing Python 2.4.

(Used bForDemand=1 in makepy to generate MS Excel 11.0
Object Library, otherwise makepy itself crashes.)



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

>Comment By: Mark Hammond (mhammond)
Date: 2005-01-26 20:32

Message:
Logged In: YES 
user_id=14198

Thanks Roger - I'll dig a little deeper on this.

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

Comment By: Roger Upole (rupole)
Date: 2005-01-26 16:27

Message:
Logged In: YES 
user_id=771074

Python still crashes when you invoke one of the methods 
whose generated code caused the original crash. Looks to be 
related to this bug in the tokenizer:
www.python.org/sf/1089395
It hits an assertion failure on lines longer than 512.
For a workaround, remove the mbcs encoding tag in genpy.py
and makepy works correctly even with bForDemand=0.



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

Comment By: Mark Hammond (mhammond)
Date: 2005-01-25 20:53

Message:
Logged In: YES 
user_id=14198

gencache.py (1.30)
makepy.py (1.19)

From that checkin message:

Avoid crashes on Python 2.4 by defaulting to bForDemand=True
- ie, each typelib actually creates a "skeleton" Python
package, and populates the package as each interface is
requested.

Cause of the underling crash is that the generated .py
causes an overflow as the byte-code is generated - something
in 2.4 bloated the byte-code for these modules.


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

Comment By: barney dalton (barneyd)
Date: 2004-12-16 21:07

Message:
Logged In: YES 
user_id=49828


I'm having a similar problem with Excel 2002 in Python 2.4.
The script:

#>

from win32com.client import gencache
gencache.EnsureModule('{00020813-0000-0000-C000-000000000046}',
0, 1, 3, bForDemand=1)

import win32com.client

ExcelApp=win32com.client.Dispatch("Excel.Application")

#<

Causes a access violation in python

AppName: python.exe	 AppVer: 0.0.0.0	 ModName: ntdll.dll
ModVer: 5.1.2600.1217	 Offset: 00033905




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

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

[pywin32-bugs] [ pywin32-Bugs-1085454 ] Py 2.4 + MS Excel COM --> crash

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

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

Category: com
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: sitecap (sitecap)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py 2.4 + MS Excel COM --> crash

Initial Comment:
Any code that tries to dispatch an Excel (2003)
application ends up crashing Python 2.4.

(Used bForDemand=1 in makepy to generate MS Excel 11.0
Object Library, otherwise makepy itself crashes.)



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

>Comment By: Roger Upole (rupole)
Date: 2005-01-26 00:27

Message:
Logged In: YES 
user_id=771074

Python still crashes when you invoke one of the methods 
whose generated code caused the original crash. Looks to be 
related to this bug in the tokenizer:
www.python.org/sf/1089395
It hits an assertion failure on lines longer than 512.
For a workaround, remove the mbcs encoding tag in genpy.py
and makepy works correctly even with bForDemand=0.



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

Comment By: Mark Hammond (mhammond)
Date: 2005-01-25 04:53

Message:
Logged In: YES 
user_id=14198

gencache.py (1.30)
makepy.py (1.19)

From that checkin message:

Avoid crashes on Python 2.4 by defaulting to bForDemand=True
- ie, each typelib actually creates a "skeleton" Python
package, and populates the package as each interface is
requested.

Cause of the underling crash is that the generated .py
causes an overflow as the byte-code is generated - something
in 2.4 bloated the byte-code for these modules.


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

Comment By: barney dalton (barneyd)
Date: 2004-12-16 05:07

Message:
Logged In: YES 
user_id=49828


I'm having a similar problem with Excel 2002 in Python 2.4.
The script:

#>

from win32com.client import gencache
gencache.EnsureModule('{00020813-0000-0000-C000-000000000046}',
0, 1, 3, bForDemand=1)

import win32com.client

ExcelApp=win32com.client.Dispatch("Excel.Application")

#<

Causes a access violation in python

AppName: python.exe	 AppVer: 0.0.0.0	 ModName: ntdll.dll
ModVer: 5.1.2600.1217	 Offset: 00033905




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

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

[pywin32-bugs] [ pywin32-Bugs-1085454 ] Py 2.4 + MS Excel COM --> crash

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

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

Category: com
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: sitecap (sitecap)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py 2.4 + MS Excel COM --> crash

Initial Comment:
Any code that tries to dispatch an Excel (2003)
application ends up crashing Python 2.4.

(Used bForDemand=1 in makepy to generate MS Excel 11.0
Object Library, otherwise makepy itself crashes.)



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

>Comment By: Mark Hammond (mhammond)
Date: 2005-01-25 20:53

Message:
Logged In: YES 
user_id=14198

gencache.py (1.30)
makepy.py (1.19)

From that checkin message:

Avoid crashes on Python 2.4 by defaulting to bForDemand=True
- ie, each typelib actually creates a "skeleton" Python
package, and populates the package as each interface is
requested.

Cause of the underling crash is that the generated .py
causes an overflow as the byte-code is generated - something
in 2.4 bloated the byte-code for these modules.


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

Comment By: barney dalton (barneyd)
Date: 2004-12-16 21:07

Message:
Logged In: YES 
user_id=49828


I'm having a similar problem with Excel 2002 in Python 2.4.
The script:

#>

from win32com.client import gencache
gencache.EnsureModule('{00020813-0000-0000-C000-000000000046}',
0, 1, 3, bForDemand=1)

import win32com.client

ExcelApp=win32com.client.Dispatch("Excel.Application")

#<

Causes a access violation in python

AppName: python.exe	 AppVer: 0.0.0.0	 ModName: ntdll.dll
ModVer: 5.1.2600.1217	 Offset: 00033905




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

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

[pywin32-bugs] [ pywin32-Bugs-1017504 ] Debugger fills Registry with 100s of ToolbarDefault-Bar-n

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

Bugs item #1017504, was opened at 2004-08-27 12:44
Message generated for change (Comment added) made by gfe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&group_id=78018

Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Martin Gfeller (gfe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Debugger fills Registry with 100s of ToolbarDefault-Bar-n

Initial Comment:
On Windows 2000, PythonWin creates many hundreds of 
ToolbarDefault-Bar-n keys in the registry once the 
debugger is invoked (either by debug or post-mortem) 
and the 'go' or 'close' button is clicked.

It seems to be specific to Windows 2000, where it 
occurs each time, and makes the debugger pretty 
unusable, because the registry slows down Windows to 
the point of unusability and instability. 

I could not reproduce it on Windows XP Pro. 

Environment: 
PythonWin Build 202
PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC 
v.1200 32 bit (Intel)] on win32.
Windows 2000, SP4, Build 2195

Best regards,
Martin

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

>Comment By: Martin Gfeller (gfe)
Date: 2005-01-10 10:25

Message:
Logged In: YES 
user_id=884167

I never encountered this AssertionError, nevertheless the 
registry gets filled regularly. I zap the PyWin part of the 
registry now routinely after using the debugger. 

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

Comment By: Colin J. Williams (cjwhrh)
Date: 2005-01-08 21:48

Message:
Logged In: YES 
user_id=285587

The following traceback appears to be connected with the
flood of toolbar entries to the registry of Windows XP with
PythonWin build 203.

The work around is to uninstall PythonWin and then remove
the Python for win32 entry in the registry (uninstall
doesn't do this).

Finally, reinstall PythonWin.

>>> Traceback (most recent call last):
  File
"C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py",
line 65, in OnStepOver
    self._DoOrStart("do_set_next", scriptutils.RS_DEBUGGER_STEP)
  File
"C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py",
line 57, in _DoOrStart
    method()
  File
"C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py",
line 632, in do_set_next
    if self.GUIAboutToRun():
  File
"C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py",
line 791, in GUIAboutToRun
    if not self.StopDebuggerPump():
  File
"C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py",
line 487, in StopDebuggerPump
    assert self.pumping, "Can't stop the debugger pump if Im
not pumping!"
AssertionError: Can't stop the debugger pump if Im not pumping!
win32ui: Error in Command Message handler for command ID
15021, Code 0

Best wishes,

Colin W.

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

Comment By: Martin Gfeller (gfe)
Date: 2004-12-22 22:48

Message:
Logged In: YES 
user_id=884167

It also happens to me on Windows XP SP2 now (with PyWin 
203).

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

Comment By: Mark Hammond (mhammond)
Date: 2004-10-09 07:52

Message:
Logged In: YES 
user_id=14198

As I said in 944506:
I've failed again to solve this.  It sounds alot like
Q151446, but that is pre MFC6, and doesn't solve the
problem.  It *nearly* does.  I'm closing this and will keep
"[ 1017504 ] Debugger fills Registry with 100s of
ToolbarDefault-Bar-n" open (only as it has a better name)

The next release will have that SaveBarState() call
commented out.  Dropping priority as this should mean the
bug is much less severe.

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

Comment By: bob gailer (ramrom)
Date: 2004-08-28 15:19

Message:
Logged In: YES 
user_id=587593

*This problem has also been entered under 894191 and 944506.
It definitely causes problems, and has not, to my knowledge
been  addressed.  944506 has never been assigned! 

Please, someone who knows the details of what should happen
help us.


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

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

[pywin32-bugs] [ pywin32-Bugs-1017504 ] Debugger fills Registry with 100s of ToolbarDefault-Bar-n

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

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

Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Martin Gfeller (gfe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Debugger fills Registry with 100s of ToolbarDefault-Bar-n

Initial Comment:
On Windows 2000, PythonWin creates many hundreds of 
ToolbarDefault-Bar-n keys in the registry once the 
debugger is invoked (either by debug or post-mortem) 
and the 'go' or 'close' button is clicked.

It seems to be specific to Windows 2000, where it 
occurs each time, and makes the debugger pretty 
unusable, because the registry slows down Windows to 
the point of unusability and instability. 

I could not reproduce it on Windows XP Pro. 

Environment: 
PythonWin Build 202
PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC 
v.1200 32 bit (Intel)] on win32.
Windows 2000, SP4, Build 2195

Best regards,
Martin

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

Comment By: Colin J. Williams (cjwhrh)
Date: 2005-01-08 15:48

Message:
Logged In: YES 
user_id=285587

The following traceback appears to be connected with the
flood of toolbar entries to the registry of Windows XP with
PythonWin build 203.

The work around is to uninstall PythonWin and then remove
the Python for win32 entry in the registry (uninstall
doesn't do this).

Finally, reinstall PythonWin.

>>> Traceback (most recent call last):
  File
"C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py",
line 65, in OnStepOver
    self._DoOrStart("do_set_next", scriptutils.RS_DEBUGGER_STEP)
  File
"C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py",
line 57, in _DoOrStart
    method()
  File
"C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py",
line 632, in do_set_next
    if self.GUIAboutToRun():
  File
"C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py",
line 791, in GUIAboutToRun
    if not self.StopDebuggerPump():
  File
"C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py",
line 487, in StopDebuggerPump
    assert self.pumping, "Can't stop the debugger pump if Im
not pumping!"
AssertionError: Can't stop the debugger pump if Im not pumping!
win32ui: Error in Command Message handler for command ID
15021, Code 0

Best wishes,

Colin W.

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

Comment By: Martin Gfeller (gfe)
Date: 2004-12-22 16:48

Message:
Logged In: YES 
user_id=884167

It also happens to me on Windows XP SP2 now (with PyWin 
203).

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

Comment By: Mark Hammond (mhammond)
Date: 2004-10-09 01:52

Message:
Logged In: YES 
user_id=14198

As I said in 944506:
I've failed again to solve this.  It sounds alot like
Q151446, but that is pre MFC6, and doesn't solve the
problem.  It *nearly* does.  I'm closing this and will keep
"[ 1017504 ] Debugger fills Registry with 100s of
ToolbarDefault-Bar-n" open (only as it has a better name)

The next release will have that SaveBarState() call
commented out.  Dropping priority as this should mean the
bug is much less severe.

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

Comment By: bob gailer (ramrom)
Date: 2004-08-28 09:19

Message:
Logged In: YES 
user_id=587593

*This problem has also been entered under 894191 and 944506.
It definitely causes problems, and has not, to my knowledge
been  addressed.  944506 has never been assigned! 

Please, someone who knows the details of what should happen
help us.


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

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

[pywin32-bugs] [ pywin32-Bugs-1097387 ] Characters property does not have __call__ method

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

Bugs item #1097387, was opened at 2005-01-06 13:50
Message generated for change (Settings changed) made by dhabersa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1097387&group_id=78018

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Daniel B. Habersat (dhabersa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Characters property does not have __call__ method

Initial Comment:
The Characters property/method is supposed to allow an
application to modify the contents (in whole or in
partial) of a cell, text box, etc.  According to the
Microsoft Excel Object Model, Characters has two
optional arguments, one to specify the starting
position and a second to specify the number of
characters (default is for the whole set).  When I try
to call Characters of an object such as an AxisTitle or
Cell, python fails with an error like so:

<--
Traceback (most recent call last):
  File "__init__.py", line 546, in ?
    y2axis.AxisTitle.Characters(2,2).Font.Subscript = True
AttributeError: Characters instance has no __call__ method
-->

The way that a call like this should work can be easily
implemented within Excel's Visual Basic Editor with an
open sheet named "Sheet1":
<--
Function demonstration()
    Sheet1.Cells(1,1).Value = "test phrase"
    Sheet1.Cells(1,1).Characters(1,4).Font.Bold = True
End Function
-->
This script places the value "test phrase" into the
first cell on Sheet1, and then makes only the "test"
part bold.  I have made a python script which attempts
to do the same thing as an example but fails on the
call to Characters.

Software versions:
Python 2.3.2
win32com build 203
Microsoft Excel 2002 (10.4302.4219) SP-2

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

Comment By: Daniel B. Habersat (dhabersa)
Date: 2005-01-07 09:02

Message:
Logged In: YES 
user_id=422196

Thanks!  That's just what I was looking for.

Is there a better way to find information like this, like
documentation or source code or something?  I tried (among
other things) looking in the makepy wrapper .py file but it
was rather confusing and not very helpful.

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

Comment By: Stefan Schukat (sschukat)
Date: 2005-01-07 01:43

Message:
Logged In: YES 
user_id=977439

The Characters property is a "parametrized" property. 
Such a concept is not natively supported by Python.
With a makepy wrapper you could call 

 y2axis.AxisTitle.GetCharacters(2,2).Font.Subscript = True

So just a little bit different interpretation of an
interface definition.

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

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

[pywin32-bugs] [ pywin32-Bugs-1097387 ] Characters property does not have __call__ method

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

Bugs item #1097387, was opened at 2005-01-06 13:50
Message generated for change (Comment added) made by dhabersa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1097387&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel B. Habersat (dhabersa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Characters property does not have __call__ method

Initial Comment:
The Characters property/method is supposed to allow an
application to modify the contents (in whole or in
partial) of a cell, text box, etc.  According to the
Microsoft Excel Object Model, Characters has two
optional arguments, one to specify the starting
position and a second to specify the number of
characters (default is for the whole set).  When I try
to call Characters of an object such as an AxisTitle or
Cell, python fails with an error like so:

<--
Traceback (most recent call last):
  File "__init__.py", line 546, in ?
    y2axis.AxisTitle.Characters(2,2).Font.Subscript = True
AttributeError: Characters instance has no __call__ method
-->

The way that a call like this should work can be easily
implemented within Excel's Visual Basic Editor with an
open sheet named "Sheet1":
<--
Function demonstration()
    Sheet1.Cells(1,1).Value = "test phrase"
    Sheet1.Cells(1,1).Characters(1,4).Font.Bold = True
End Function
-->
This script places the value "test phrase" into the
first cell on Sheet1, and then makes only the "test"
part bold.  I have made a python script which attempts
to do the same thing as an example but fails on the
call to Characters.

Software versions:
Python 2.3.2
win32com build 203
Microsoft Excel 2002 (10.4302.4219) SP-2

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

>Comment By: Daniel B. Habersat (dhabersa)
Date: 2005-01-07 09:02

Message:
Logged In: YES 
user_id=422196

Thanks!  That's just what I was looking for.

Is there a better way to find information like this, like
documentation or source code or something?  I tried (among
other things) looking in the makepy wrapper .py file but it
was rather confusing and not very helpful.

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

Comment By: Stefan Schukat (sschukat)
Date: 2005-01-07 01:43

Message:
Logged In: YES 
user_id=977439

The Characters property is a "parametrized" property. 
Such a concept is not natively supported by Python.
With a makepy wrapper you could call 

 y2axis.AxisTitle.GetCharacters(2,2).Font.Subscript = True

So just a little bit different interpretation of an
interface definition.

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

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

[pywin32-bugs] [ pywin32-Feature Requests-1097745 ] please expose Getservicebyname and getservicebykeyname

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

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

Category: win32
Group: Next Release (example)
Status: Open
Resolution: None
Priority: 5
Submitted By: Harald Armin Massa (ghum)
Assigned to: Nobody/Anonymous (nobody)
Summary: please expose Getservicebyname and getservicebykeyname

Initial Comment:
The win32service-module does not expose

Getservicebyname


and 

Getservicebykeyname


of the win32api yet.

Please expose them in future versions.



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

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

[pywin32-bugs] [ pywin32-Bugs-1097387 ] Characters property does not have __call__ method

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

Bugs item #1097387, was opened at 2005-01-06 19:50
Message generated for change (Comment added) made by sschukat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1097387&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel B. Habersat (dhabersa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Characters property does not have __call__ method

Initial Comment:
The Characters property/method is supposed to allow an
application to modify the contents (in whole or in
partial) of a cell, text box, etc.  According to the
Microsoft Excel Object Model, Characters has two
optional arguments, one to specify the starting
position and a second to specify the number of
characters (default is for the whole set).  When I try
to call Characters of an object such as an AxisTitle or
Cell, python fails with an error like so:

<--
Traceback (most recent call last):
  File "__init__.py", line 546, in ?
    y2axis.AxisTitle.Characters(2,2).Font.Subscript = True
AttributeError: Characters instance has no __call__ method
-->

The way that a call like this should work can be easily
implemented within Excel's Visual Basic Editor with an
open sheet named "Sheet1":
<--
Function demonstration()
    Sheet1.Cells(1,1).Value = "test phrase"
    Sheet1.Cells(1,1).Characters(1,4).Font.Bold = True
End Function
-->
This script places the value "test phrase" into the
first cell on Sheet1, and then makes only the "test"
part bold.  I have made a python script which attempts
to do the same thing as an example but fails on the
call to Characters.

Software versions:
Python 2.3.2
win32com build 203
Microsoft Excel 2002 (10.4302.4219) SP-2

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

Comment By: Stefan Schukat (sschukat)
Date: 2005-01-07 07:43

Message:
Logged In: YES 
user_id=977439

The Characters property is a "parametrized" property. 
Such a concept is not natively supported by Python.
With a makepy wrapper you could call 

 y2axis.AxisTitle.GetCharacters(2,2).Font.Subscript = True

So just a little bit different interpretation of an
interface definition.

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

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

[pywin32-bugs] [ pywin32-Bugs-1097387 ] Characters property does not have __call__ method

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

Bugs item #1097387, was opened at 2005-01-06 13:50
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=1097387&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel B. Habersat (dhabersa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Characters property does not have __call__ method

Initial Comment:
The Characters property/method is supposed to allow an
application to modify the contents (in whole or in
partial) of a cell, text box, etc.  According to the
Microsoft Excel Object Model, Characters has two
optional arguments, one to specify the starting
position and a second to specify the number of
characters (default is for the whole set).  When I try
to call Characters of an object such as an AxisTitle or
Cell, python fails with an error like so:

<--
Traceback (most recent call last):
  File "__init__.py", line 546, in ?
    y2axis.AxisTitle.Characters(2,2).Font.Subscript = True
AttributeError: Characters instance has no __call__ method
-->

The way that a call like this should work can be easily
implemented within Excel's Visual Basic Editor with an
open sheet named "Sheet1":
<--
Function demonstration()
    Sheet1.Cells(1,1).Value = "test phrase"
    Sheet1.Cells(1,1).Characters(1,4).Font.Bold = True
End Function
-->
This script places the value "test phrase" into the
first cell on Sheet1, and then makes only the "test"
part bold.  I have made a python script which attempts
to do the same thing as an example but fails on the
call to Characters.

Software versions:
Python 2.3.2
win32com build 203
Microsoft Excel 2002 (10.4302.4219) SP-2

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

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

[pywin32-bugs] [ pywin32-Bugs-1097153 ] DispatchWithEvents always rebuild makepy support

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

Bugs item #1097153, was opened at 2005-01-06 13:51
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=1097153&group_id=78018

Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Giovanni Bajo (giovannibajo)
Assigned to: Nobody/Anonymous (nobody)
Summary: DispatchWithEvents always rebuild makepy support

Initial Comment:
Hello,

it looks like DispatchWithEvents has a bug and always 
rebuild the makepy support even if it is not necessary. 
The bug is here:

  if not disp.__dict__.get("CLSID"): # Eeek - no makepy 
support - try and build it.
    try:
      [...]

The problem is the use of disp.__dict__ which is the 
dictionary instance. makepy generates objects which 
have their CLSID as a class attribute (rather than 
instance attributes).

To fix this bug, it is sufficient to change this bug to the 
more straightforward and standard:

  if not getattr(disp, "CLSID"): # Eeek - no makepy 
support - try and build it.
    try:

I'm not sure if the use of __dict__ was to avoid looking 
up in base classes (no clue about how win32com 
internally wraps COM objects). In that case, I suggest 
to use disp.__class__.__dict__ instead of disp.__dict__.


Please, let me know in which official released version of 
win32all this fix will appear. Thanks.

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

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

[pywin32-bugs] [ pywin32-Bugs-1094803 ] postinstall failure: access denied to registry writes

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

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

Category: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kim Davies (kjd)
Assigned to: Nobody/Anonymous (nobody)
Summary: postinstall failure: access denied to registry writes

Initial Comment:
Installing pythonwin build 203 for Python 2.4 under 
Windows XP, I receive the following. 

The installation is nonfunctioning if I try and run it (i.e. 
pythonw.exe) at this point.

The user is an administrator, I can't think of any reason 
why the program would be administratively denied 
access to the registry.

This is what the install script gave:

Copied pythoncom24.dll to F:\WINDOWS\System32
\pythoncom24.dll
Copied pywintypes24.dll to F:\WINDOWS\System32
\pywintypes24.dll
Registered: Python.Interpreter 
Registered: Python.Dictionary 
Registered: Python 
Traceback (most recent call last):
  File "F:\Python24\Scripts\pywin32_postinstall.py", line 
358, in ?
    install()
  File "F:\Python24\Scripts\pywin32_postinstall.py", line 
231, in install
    SetPyKeyVal("Help", None, None)
  File "F:\Python24\Scripts\pywin32_postinstall.py", line 
103, in SetPyKeyVal
    _winreg.SetValueEx(my_key, value_name, 0, 
_winreg.REG_SZ, value)
WindowsError: [Errno 5] Access is denied
*** run_installscript: internal error 0xFFFFFFFF ***

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

>Comment By: Kim Davies (kjd)
Date: 2005-01-03 14:26

Message:
Logged In: YES 
user_id=168657

I note there is a comment in pywin32_postinstall.py that
probably explains it, and I just put an exception handler
around it, and it installed okay (presumably missing some
help functionality..)

New code fragment:

    # Register the .chm help file.
    chm_file = os.path.join(lib_dir, "PyWin32.chm")
    if os.path.isfile(chm_file):
        # This isn't recursive, so if 'Help' doesn't exist,
we croak
        try:
            SetPyKeyVal("Help", None, None)
            SetPyKeyVal("Help\Pythonwin Reference", None,
chm_file)
        except:
            pass
    else:
        print "NOTE: PyWin32.chm can not be located, so has
not "               "been registered"

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

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

[pywin32-bugs] [ pywin32-Bugs-1094803 ] postinstall failure: access denied to registry writes

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

Bugs item #1094803, was opened at 2005-01-03 14:13
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=1094803&group_id=78018

Category: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kim Davies (kjd)
Assigned to: Nobody/Anonymous (nobody)
Summary: postinstall failure: access denied to registry writes

Initial Comment:
Installing pythonwin build 203 for Python 2.4 under 
Windows XP, I receive the following. 

The installation is nonfunctioning if I try and run it (i.e. 
pythonw.exe) at this point.

The user is an administrator, I can't think of any reason 
why the program would be administratively denied 
access to the registry.

This is what the install script gave:

Copied pythoncom24.dll to F:\WINDOWS\System32
\pythoncom24.dll
Copied pywintypes24.dll to F:\WINDOWS\System32
\pywintypes24.dll
Registered: Python.Interpreter 
Registered: Python.Dictionary 
Registered: Python 
Traceback (most recent call last):
  File "F:\Python24\Scripts\pywin32_postinstall.py", line 
358, in ?
    install()
  File "F:\Python24\Scripts\pywin32_postinstall.py", line 
231, in install
    SetPyKeyVal("Help", None, None)
  File "F:\Python24\Scripts\pywin32_postinstall.py", line 
103, in SetPyKeyVal
    _winreg.SetValueEx(my_key, value_name, 0, 
_winreg.REG_SZ, value)
WindowsError: [Errno 5] Access is denied
*** run_installscript: internal error 0xFFFFFFFF ***

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

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

[pywin32-bugs] [ pywin32-Bugs-1092592 ] win32ui: LoadFrame failed

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

Bugs item #1092592, was opened at 2004-12-29 09: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=1092592&group_id=78018

Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: marc412 (marc412)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32ui: LoadFrame failed

Initial Comment:
I installed python-2.4.msi and pywin32-203.win32-
py2.4.exe on a windows XP system. 
At the beginning, everything worked fine, until I started 
to use the debugger. 
Since then, pythonwin seems to be broken. I can't call it 
any more from the context menu, when selecting a 
python file in the windows explorer.

Calling a file from the context menu, I am getting the 
error messages, attached below. A reinstallation had no 
effect. No effect as well as when I used pywin32-
202.win32-py2.4.exe, i.e. build no 202 instead of 203.

>>> Traceback (most recent call last):
  File "C:\Python24\Lib\site-
packages\pythonwin\pywin\mfc\docview.py", line 91, in 
CreateNewFrame
    wnd.LoadFrame(self.GetResourceID(), -1, None, 
context)	# triggers OnCreateClient...
win32ui: LoadFrame failed

win32ui: CreateNewFrame() virtual handler (<bound 
method SyntEditTemplate.CreateNewFrame of 
<pywin.framework.editor.color.coloreditor.SyntEditTempla
te instance at 0x01153530>>) raised an exception
TypeError: PyCTemplate::CreateNewFrame must return a 
PyCFrameWnd object.

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

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

[pywin32-bugs] [ pywin32-Bugs-1089483 ] pywin32-203 build failure

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: ablakok (ablakok)
Assigned to: Nobody/Anonymous (nobody)
Summary: pywin32-203 build failure

Initial Comment:
I tried running "python setup-win32all.py build" and it
failed.  I have Visual Studio 7.1 and the latest SDK
installed, along with Python 2.4.  I am attaching the
traceback.

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

>Comment By: Mark Hammond (mhammond)
Date: 2004-12-23 10:05

Message:
Logged In: YES 
user_id=14198

Please try grabbing the sources via CVS and building - this
has been fixed since the release.

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

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

[pywin32-bugs] [ pywin32-Bugs-1017504 ] Debugger fills Registry with 100s of ToolbarDefault-Bar-n

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

Bugs item #1017504, was opened at 2004-08-27 12:44
Message generated for change (Comment added) made by gfe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&group_id=78018

Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Martin Gfeller (gfe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Debugger fills Registry with 100s of ToolbarDefault-Bar-n

Initial Comment:
On Windows 2000, PythonWin creates many hundreds of 
ToolbarDefault-Bar-n keys in the registry once the 
debugger is invoked (either by debug or post-mortem) 
and the 'go' or 'close' button is clicked.

It seems to be specific to Windows 2000, where it 
occurs each time, and makes the debugger pretty 
unusable, because the registry slows down Windows to 
the point of unusability and instability. 

I could not reproduce it on Windows XP Pro. 

Environment: 
PythonWin Build 202
PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC 
v.1200 32 bit (Intel)] on win32.
Windows 2000, SP4, Build 2195

Best regards,
Martin

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

>Comment By: Martin Gfeller (gfe)
Date: 2004-12-22 22:48

Message:
Logged In: YES 
user_id=884167

It also happens to me on Windows XP SP2 now (with PyWin 
203).

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

Comment By: Mark Hammond (mhammond)
Date: 2004-10-09 07:52

Message:
Logged In: YES 
user_id=14198

As I said in 944506:
I've failed again to solve this.  It sounds alot like
Q151446, but that is pre MFC6, and doesn't solve the
problem.  It *nearly* does.  I'm closing this and will keep
"[ 1017504 ] Debugger fills Registry with 100s of
ToolbarDefault-Bar-n" open (only as it has a better name)

The next release will have that SaveBarState() call
commented out.  Dropping priority as this should mean the
bug is much less severe.

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

Comment By: bob gailer (ramrom)
Date: 2004-08-28 15:19

Message:
Logged In: YES 
user_id=587593

*This problem has also been entered under 894191 and 944506.
It definitely causes problems, and has not, to my knowledge
been  addressed.  944506 has never been assigned! 

Please, someone who knows the details of what should happen
help us.


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

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

[pywin32-bugs] [ pywin32-Bugs-1089483 ] pywin32-203 build failure

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

Bugs item #1089483, was opened at 2004-12-21 18: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=1089483&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: ablakok (ablakok)
Assigned to: Nobody/Anonymous (nobody)
Summary: pywin32-203 build failure

Initial Comment:
I tried running "python setup-win32all.py build" and it
failed.  I have Visual Studio 7.1 and the latest SDK
installed, along with Python 2.4.  I am attaching the
traceback.

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

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

[pywin32-bugs] [ pywin32-Bugs-1089071 ] Debugging with debug build of Pythonwin loops with assert

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

Bugs item #1089071, was opened at 2004-12-21 14: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=1089071&group_id=78018

Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark E (markenglish)
Assigned to: Nobody/Anonymous (nobody)
Summary: Debugging with debug build of Pythonwin loops with assert

Initial Comment:
Build debug version of Pythonwin (Pythonwin_d.exe)
Run it.
Create a test script like:
------------------------
def RunTest():
	"""Print something"""
	print "RunTest()"

def main():
	"""Main entry point for module"""
	RunTest()

if __name__ == "__main__":
	main()
----------------------
Put a breakpoint inside "RunTest()".
Run in debugger. Stops at breakpoint correctly.
Continue.

ASSERT dialog box comes up referencing "thrdcore.cpp" 
line 173 which is part of MFC threading code.
Referenced lines of code are:
<code>
#ifdef _DEBUG
  if (pState->m_nDisablePumpCount != 0)
	{
	  TRACE(traceAppMsg, 0, "Error: 
CWinThread::PumpMessage called when not 
permitted.\n");
	  ASSERT(FALSE);
	}
#endif
</code>
Not particularly severe in itself but might point at source 
of other bugs.

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

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

[pywin32-bugs] [ pywin32-Bugs-1013126 ] PythonWin not installed in context menu.

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

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

Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon McLin (jon_mclin)
Assigned to: Nobody/Anonymous (nobody)
Summary: PythonWin not installed in context menu.

Initial Comment:
In earlier builds (142 to 163, at least), PythonWin was
installed to the Explorer context menu so I could
right-click and "Open with PythonWin".

I used this a lot!  Where did it go in 202?

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

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-12-20 22:21

Message:
Logged In: YES 
user_id=1038590

I think I'm getting a similar error with 203.

When I first installed 203, the postinstall script aborted
due to the missing MFC DLL. Now, uninstalling/reinstalling
203 doesn't seem to make any difference - I still have no
direct option in the context menu to edit files with
Pythonwin. (Not a huge hassle, due to XP's 'Open with'
submenu, but still kind of annoying).

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

Comment By: Andrew Payn Barnert (payn)
Date: 2004-09-09 08:13

Message:
Logged In: YES 
user_id=96775

See bug 990048. I'm willing to bet the installer got an
error in the postinstall script, so it skipped all later
steps (including the Explorer integration stuff) but still
reported success overall.


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

Comment By: Jon McLin (jon_mclin)
Date: 2004-08-21 06:56

Message:
Logged In: YES 
user_id=1071288

PS - platform is Win XP Pro.

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

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

[pywin32-bugs] [ pywin32-Bugs-1087777 ] CDC.StartDoc() does not spool to file

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

Bugs item #1087777, was opened at 2004-12-19 06:26
Message generated for change (Comment added) made by lsaffre
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1087777&group_id=78018

Category: None
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Luc Saffre (lsaffre)
Assigned to: Nobody/Anonymous (nobody)
Summary: CDC.StartDoc() does not spool to file

Initial Comment:
The documentation states that CDC.StartDoc() has a
second parameter "outputFile": "Use this to spool to a
file. Omit to send to the printer."

As far as i can see, this parameter has no effect.  I
use it as follows:

dc = win32ui.CreateDC()
dc.CreatePrinterDC(printerName)
dc.StartDoc("my print job",r"c:\temp\temp.txt")
dc.SetMapMode(win32con.MM_TWIPS)
dc.StartPage()
... print something...
dc.EndDoc()

This parameter would be useful because I am writing
test cases, and I don't want them to really print
something by accident.



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

>Comment By: Luc Saffre (lsaffre)
Date: 2004-12-20 11:19

Message:
Logged In: YES 
user_id=161785

Confirmation: this problem came because the "Virtual PDF
Printer" (http://www.go2pdf.com/products.html) driver
appearently ignores this lpszOutput element. When printing
on a "normal" printer, everything works as documented. 
Apologies for inconveniences.


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

Comment By: Mark Hammond (mhammond)
Date: 2004-12-20 05:02

Message:
Logged In: YES 
user_id=14198

I have verified that we are setting the lpszOutput element
of the DOCINFO structure.  I'm afraid I have no idea why it
isn't working for you, but I can't see a bug in pywin32
here.  Please re-open if you think there is something we are
doing wrong.

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

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