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

[pywin32-bugs] [ pywin32-Bugs-740417 ] Potential error concealment in COM server initialization

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Max Shiyanovsky (shiyanovsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Potential error concealment in COM server initialization

Initial Comment:
file win32com\server\policy.py 
class BasicWrapPolicy:
  def _CreateInstance_(self, clsid, reqIID)

this function brings some danger in case of 
win32api.error raise from server initialization routine. 
I'd suggest to move except statement some rows above to
except only CLSID/PythonCom key reading failure.

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

>Comment By: Mark Hammond (mhammond)
Date: 2003-06-01 22:53

Message:
Logged In: YES 
user_id=14198

Sorry - I was looking at the global _CreateInstance
function.  A patch speaks a thousand words <wink>

Checking in policy.py;
policy.py new revision: 1.14; previous revision: 1.13

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

Comment By: Max Shiyanovsky (shiyanovsky)
Date: 2003-05-31 02:01

Message:
Logged In: YES 
user_id=782829

the whole code of _CreateInstance_ lookis like (doc-string 
omitted)
  def _CreateInstance_(self, clsid, reqIID):
    try:
      classSpec = win32api.RegQueryValue
(win32con.HKEY_CLASSES_ROOT,
                                       regSpec % clsid)
      myob = call_func(classSpec)
      self._wrap_(myob)
      return pythoncom.WrapObject(self, reqIID)
    except win32api.error:
      raise error, "The object is not correctly registered - %s 
key can not be read" % (regSpec % clsid)

The call       
myob = call_func(classSpec) may raise an exception and 
furthermore exactly win32api.error. Certainly it's my bug that 
don't handle such an exception in class ctor (in my case 
callable object is a class). But as a result I've got a wrong 
message "object is not correctly registered".
I suggest to wrap in try-except only win32api.RegQueryValue 
call.


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

Comment By: Mark Hammond (mhammond)
Date: 2003-05-27 12:01

Message:
Logged In: YES 
user_id=14198

I don't quite follow this.  Object creation should be in the
code:

  if dispatcher:
    retObj = dispatcher(policy, None)
  else:
    retObj = policy(None)
  return retObj._CreateInstance_(clsid, reqIID)

And this is not wrapped in an except handler.  I guess that
getting the dispatcher class could fail, but that seems alot
less likely than the class constructor failing.

Can you please give me a real example of what could fail?

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

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

[pywin32-bugs] [ pywin32-Bugs-740417 ] Potential error concealment in COM server initialization

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

Bugs item #740417, was opened at 2003-05-20 12:31
Message generated for change (Comment added) made by shiyanovsky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=740417&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Max Shiyanovsky (shiyanovsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Potential error concealment in COM server initialization

Initial Comment:
file win32com\server\policy.py 
class BasicWrapPolicy:
  def _CreateInstance_(self, clsid, reqIID)

this function brings some danger in case of 
win32api.error raise from server initialization routine. 
I'd suggest to move except statement some rows above to
except only CLSID/PythonCom key reading failure.

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

>Comment By: Max Shiyanovsky (shiyanovsky)
Date: 2003-05-30 16:01

Message:
Logged In: YES 
user_id=782829

the whole code of _CreateInstance_ lookis like (doc-string 
omitted)
  def _CreateInstance_(self, clsid, reqIID):
    try:
      classSpec = win32api.RegQueryValue
(win32con.HKEY_CLASSES_ROOT,
                                       regSpec % clsid)
      myob = call_func(classSpec)
      self._wrap_(myob)
      return pythoncom.WrapObject(self, reqIID)
    except win32api.error:
      raise error, "The object is not correctly registered - %s 
key can not be read" % (regSpec % clsid)

The call       
myob = call_func(classSpec) may raise an exception and 
furthermore exactly win32api.error. Certainly it's my bug that 
don't handle such an exception in class ctor (in my case 
callable object is a class). But as a result I've got a wrong 
message "object is not correctly registered".
I suggest to wrap in try-except only win32api.RegQueryValue 
call.


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

Comment By: Mark Hammond (mhammond)
Date: 2003-05-27 02:01

Message:
Logged In: YES 
user_id=14198

I don't quite follow this.  Object creation should be in the
code:

  if dispatcher:
    retObj = dispatcher(policy, None)
  else:
    retObj = policy(None)
  return retObj._CreateInstance_(clsid, reqIID)

And this is not wrapped in an except handler.  I guess that
getting the dispatcher class could fail, but that seems alot
less likely than the class constructor failing.

Can you please give me a real example of what could fail?

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

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

[pywin32-bugs] [ pywin32-Bugs-745699 ] Error handling: not playing nice with Tkinter? (W98)

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

Bugs item #745699, was opened at 2003-05-29 15:27
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=745699&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Philip Reed (philipreed)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error handling: not playing nice with Tkinter? (W98)

Initial Comment:
When PythonWin is executing a TKInter script and 
something goes wrong, things apparently get left in 
queue for the next (correct) execution.   This causes 
weirdness in the GUI interaction eventually leading 
PythonWin to crash.

Not 100% sure it's PyWin and not TkInter's problem, 
but I started with the more likely suspect IMO.

TO REPRODUCE:
1. start PythonWin
2. New python script
3. Paste in Example 3.1 from 
<http://www.pythonware.com/library/tkinter/introducti
on/hello-again.htm> (a TkInter "Hello World" example).


4. Add some line that's guaranteed to error, 
like "import dummy", BEFORE the call to root.mainloop
()
5. Save the file somewhere not in the Python path, e.g. 
under a subdir of My Documents .
6. Run with an <F5>

OBSERVE: normal exception message in interactive 
window.

6. Fix the "problem" by deleting the bogus import line.
7. Run again with <F5>

ACTUAL RESULT: Now you get two TKInter dialog 
boxes!   Pressing Quit on the 2nd one doesn't really 
quit, and pressing a few more buttons (e.g. Quit on 
the first, Hello on the second, Quit on the second -- I 
think that was my order) will cause an error:

Runtime Error!

Program <path to pythonwin> PYTHONWIN.EXE

abnormal program termination

EXPECTED RESULT: PythonWin should be robust 
enough to handle this.   I think.  :-)

If possible, it should clear out the queue of windows so 
the first dialog never gets displayed.   Certainly they 
shouldn't both display at the same time.

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

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

[pywin32-bugs] [ pywin32-Bugs-745304 ] GetObject fails under Win32all-153

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

Bugs item #745304, was opened at 2003-05-29 02:53
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=745304&group_id=78018

Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Asare (aka_kool)
Assigned to: Nobody/Anonymous (nobody)
Summary: GetObject fails under Win32all-153

Initial Comment:
GetObject fails to retrieve an instance of an object when 
a moniker is used.
For example, when working with WMI the following
will fail :-

>>> import win32com.client
>>> o = win32com.client.GetObject("winmgmts:")
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
  File "C:\Python23\lib\site-
packages\win32com\client\__init__.py", line 73, in 
GetObject
    return Moniker(Pathname, clsctx)
  File "C:\Python23\lib\site-
packages\win32com\client\__init__.py", line 88, in 
Moniker
    moniker, i, bindCtx = 
pythoncom.MkParseDisplayName(Pathname)
com_error: (-2147221020, 'Invalid syntax', None, None)


I believe there is a bug in the implementation of 
MkParseDisplayName - possible corruption of passed 
moniker string.

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

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

[pywin32-bugs] [ pywin32-Patches-743989 ] Some patch to add support for Wizard97

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

Patches item #743989, was opened at 2003-05-27 02:47
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=743989&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lijun Qin (qinlj)
Assigned to: Nobody/Anonymous (nobody)
Summary: Some patch to add support for Wizard97

Initial Comment:
I have patched some source files in 
the ./pywin32/pythonwin directory to add the support for 
the new Wizard97 style.
including these:
pythonppage.cpp pythonppage.h
pythonpsheet.cpp pythonpsheet.h
win32prop.cpp win32prop.h
win32uimodule.cpp

also below because of some bugs found in these files:
win32assoc.cpp
win32bitmap.cpp win32bitmap.h
win32ctlList.h

attached is the diff file.

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

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

[pywin32-bugs] [ pywin32-Bugs-740417 ] Potential error concealment in COM server initialization

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Max Shiyanovsky (shiyanovsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Potential error concealment in COM server initialization

Initial Comment:
file win32com\server\policy.py 
class BasicWrapPolicy:
  def _CreateInstance_(self, clsid, reqIID)

this function brings some danger in case of 
win32api.error raise from server initialization routine. 
I'd suggest to move except statement some rows above to
except only CLSID/PythonCom key reading failure.

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

>Comment By: Mark Hammond (mhammond)
Date: 2003-05-27 12:01

Message:
Logged In: YES 
user_id=14198

I don't quite follow this.  Object creation should be in the
code:

  if dispatcher:
    retObj = dispatcher(policy, None)
  else:
    retObj = policy(None)
  return retObj._CreateInstance_(clsid, reqIID)

And this is not wrapped in an except handler.  I guess that
getting the dispatcher class could fail, but that seems alot
less likely than the class constructor failing.

Can you please give me a real example of what could fail?

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

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

[pywin32-bugs] [ pywin32-Feature Requests-743527 ] support for cygwin

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

Feature Requests item #743527, was opened at 2003-05-26 20:11
Message generated for change (Comment added) made by anadelonbrin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=743527&group_id=78018

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Michael Dubner (dubnerm)
Assigned to: Nobody/Anonymous (nobody)
Summary: support for cygwin

Initial Comment:
Not sure that it will be easy, but there are w32api
package...

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

Comment By: Tony Meyer (anadelonbrin)
Date: 2003-05-26 20:15

Message:
Logged In: YES 
user_id=552329

Why would you need support for cygwin?  If you're running 
cygwin, then you have Windows, so you can use the 
standard extensions, can't you?  (seems to work for me).

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

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

[pywin32-bugs] [ pywin32-Feature Requests-743527 ] support for cygwin

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

Feature Requests item #743527, was opened at 2003-05-26 12: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=743527&group_id=78018

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Michael Dubner (dubnerm)
Assigned to: Nobody/Anonymous (nobody)
Summary: support for cygwin

Initial Comment:
Not sure that it will be easy, but there are w32api
package...

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

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

[pywin32-bugs] [ pywin32-Bugs-740417 ] Potential error concealment in COM server initialization

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

Bugs item #740417, was opened at 2003-05-20 12:31
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=740417&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Max Shiyanovsky (shiyanovsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Potential error concealment in COM server initialization

Initial Comment:
file win32com\server\policy.py 
class BasicWrapPolicy:
  def _CreateInstance_(self, clsid, reqIID)

this function brings some danger in case of 
win32api.error raise from server initialization routine. 
I'd suggest to move except statement some rows above to
except only CLSID/PythonCom key reading failure.

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

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

[pywin32-bugs] [ pywin32-Feature Requests-739624 ] Implement SetConsoleCtrlHandler

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

Feature Requests item #739624, was opened at 2003-05-19 10:38
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=739624&group_id=78018

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Nobody/Anonymous (nobody)
Summary: Implement SetConsoleCtrlHandler 

Initial Comment:
Includes a patch and discussion.

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

>Comment By: Mark Hammond (mhammond)
Date: 2003-05-19 10:39

Message:
Logged In: YES 
user_id=14198

we talked about SetConsoleCtrlHandler a while ago.

>Sorry for the delay, but yes, that sounds like a reasonable 
> approach.  The only problem is with the "last-registered, 
> first-called" approach, meaning second calls to your 
> extensions function would not have the same effect as a
> second call to the real SetConsoleCtrlHandler - but yeah, 
> I see no reasonable solution worth the effort.
>
>The GIL management will not be trivial, and may require 
> you to get - err - creative :)

The GIL wasn't too hard in the end - the handler is called
in the context 
of a new thread, and there is precedent for that in the
source :)

I have attached a simplistic version of a
SetConsoleCtrlHandler. It allows 
to set *one* handler function and doesn't implement the list
I originally 
had in mind.

The code works works, but its behaviour is far from the
behaviour of 
SetConsoleCtrlHandler in a C program.

This is probably due to the signal handling of Python
itself, and I can't 
see what can be done about it.

The current code is useful to me, and it could be improved
to handle 
multiple handlers properly (by installing different C
handlers, thereby 
preserving the order), but it would be rather hard to
document the 
behaviour, since it clashes with the Python internal signal
handling.

For example, take:

import cch # this is the console controle handler module
import time

def handler(type):
     print type
     return False

cch.SetConsoleCtrlHandler(handler, True)

time.sleep(60)

If you execute this, and hit Ctrl-C before the 60 seconds
are up, the 
handler will dutifully print 0, but the process won't be
killed - because 
time.sleep() cannot be killed in Python.

If you do a sys.exit() in the handler function, it will also
not terminate 
the process, since sys.exit() only works from the main thread.

Basically, I have no clue how the Python
SetConsoleCtrlHandler should be 
documented. It would need a link to description of standard
Python signal 
handling to be generally useful, but I am not aware of any
such documentation.



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

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

[pywin32-bugs] [ pywin32-Feature Requests-739624 ] Implement SetConsoleCtrlHandler

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

Feature Requests item #739624, was opened at 2003-05-19 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=551957&aid=739624&group_id=78018

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Nobody/Anonymous (nobody)
Summary: Implement SetConsoleCtrlHandler 

Initial Comment:
Includes a patch and discussion.

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

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

[pywin32-bugs] [ pywin32-Bugs-738142 ] non-admin install issues

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

Bugs item #738142, was opened at 2003-05-15 19:10
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=738142&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: non-admin install issues

Initial Comment:
Just to let you know, I installed Python 2.2 with the
advanced non-admin install option, which puts some dlls
in the Python subtree instead of in the Windows system
folder, and the Win32 Extensions install program gave
me an error because it could not find a dll.

I reinstalled Python 2.2 with the regular admin
install, and the Win32 Extensions installed just fine. 


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

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

[pywin32-bugs] [ pywin32-Bugs-737373 ] Installer has wrong version info in pyd files

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

Bugs item #737373, was opened at 2003-05-14 09:33
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=737373&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: Installer has wrong version info in pyd files

Initial Comment:
Just wanted to alert you to a small problem with the
win32all 152 binary build for Python 2.2.  The Windows
version information appears to be incorrect or at least
inconsistent with win32all 150 for Python 2.2.  The 150
binaries are versioned 2.2.0.150, but the 152 binaries
are versioned 2.1.0.152.  This caused my installation
of 152 over 150 to NOT replace the binaries, since they
appear to be older from a versioning perspective.  All
of the win32 binaries appear to be affected.
 


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

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

[pywin32-bugs] [ pywin32-Bugs-736517 ] Memory Leak

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

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

>Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Shack Toms (shacktoms)
>Assigned to: Mark Hammond (mhammond)
Summary: Memory Leak

Initial Comment:
There is a memory leak associated with events delivered 
through the IConnectionPoint interface.   The leak 
occurs when a ByRef VARIANT parameter is passed 
through the interface as an inout parameter.

The culprit appears to be oleargs.cpp, specifically the 
routine PythonOleArgHelper::MakeObjToVariant, which 
is called to replace the original VARIANT with the 
returned one.   In the case VT_VARIANT | VT_BYREF, 
with bCreateBuffers as false, the routine calls 
VariantClear(var), which only clears the referencing 
VARIANT and not the referenced one.   This call should 
be VariantClear(V_VARIANTREF(var)), which will clear 
memory held by the referenced VARIANT before the 
subsequent call to PyCom_VariantFromPyObject 
simply overwrites that VARIANT.

The code as written depends on V_VARIANTREF(var) to 
remain valid after calling VariantClear(var), which seems 
a dangerous assumption.

Note that this repair follows the same logic as is used in 
the existing code for the VT_BSTR | VT_BYREF case, 
in which SysFreeString(*V_BSTRREF(var)) is called, for 
the reason that VariantClear(var) wouldn't free the 
indirectly referenced BSTR.

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

>Comment By: Mark Hammond (mhammond)
Date: 2003-05-14 00:28

Message:
Logged In: YES 
user_id=14198

Thanks!  Looks right to me.  I will check it in as soon as I
re-run all the tests.

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

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

[pywin32-bugs] [ pywin32-Bugs-736517 ] Memory Leak

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

Bugs item #736517, was opened at 2003-05-12 11:49
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=736517&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Shack Toms (shacktoms)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory Leak

Initial Comment:
There is a memory leak associated with events delivered 
through the IConnectionPoint interface.   The leak 
occurs when a ByRef VARIANT parameter is passed 
through the interface as an inout parameter.

The culprit appears to be oleargs.cpp, specifically the 
routine PythonOleArgHelper::MakeObjToVariant, which 
is called to replace the original VARIANT with the 
returned one.   In the case VT_VARIANT | VT_BYREF, 
with bCreateBuffers as false, the routine calls 
VariantClear(var), which only clears the referencing 
VARIANT and not the referenced one.   This call should 
be VariantClear(V_VARIANTREF(var)), which will clear 
memory held by the referenced VARIANT before the 
subsequent call to PyCom_VariantFromPyObject 
simply overwrites that VARIANT.

The code as written depends on V_VARIANTREF(var) to 
remain valid after calling VariantClear(var), which seems 
a dangerous assumption.

Note that this repair follows the same logic as is used in 
the existing code for the VT_BSTR | VT_BYREF case, 
in which SysFreeString(*V_BSTRREF(var)) is called, for 
the reason that VariantClear(var) wouldn't free the 
indirectly referenced BSTR.

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

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

[pywin32-bugs] [ pywin32-Bugs-716708 ] pythonwin editor does strange things with non-english chars

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

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

Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: pythonwin editor does strange things with non-english chars

Initial Comment:
Reported by a few people, but to repro:
* Paste "# ça ne va pas" into pywin (or any other
string with extended char)
* Move to the ç
* Press Backspace

Some other character appears.  This will be related to
pywin.idle not being mult-character aware.

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

Comment By: Tony Meyer (anadelonbrin)
Date: 2003-05-09 19:38

Message:
Logged In: YES 
user_id=552329

As another example:

In IDLE (0.8):
>>> u = u'questa \xe8 bella'
>>> u
u'questa \xe8 bella'
>>> print u
questa è bella

In PythonWin (152):
>>> u = u'questa \xe8 bella'
>>> u
u'questa \xe8 bella'
>>> print u
questa è bell

(note that if you copy the result of the 'print u', or type 
something after it, the a appears.  *very* confusing!)

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

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

[pywin32-bugs] [ pywin32-Bugs-734562 ] isInitialBreakpoint not initialised

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

Bugs item #734562, was opened at 2003-05-08 12:58
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=734562&group_id=78018

Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: janez jere (janezj)
Assigned to: Nobody/Anonymous (nobody)
Summary: isInitialBreakpoint not initialised

Initial Comment:
In build 152 pywin.debugger.brk() is not working, 
because Debugger is without isInitialBreakpoint attribute.

import pywin.debugger
g = pywin.debugger.GetDebugger()

if not hasattr(g, 'isInitialBreakpoint'):
    g.isInitialBreakpoint = None

pywin.debugger.brk()
print '1'
print '2'
print '3'

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

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

[pywin32-bugs] [ pywin32-Bugs-733540 ] Calling com server w/VB "Call" changes 1st param's value

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

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

Category: com
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Ryan Groe (ryangroe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling com server w/VB "Call" changes 1st param's value

Initial Comment:
python version: 2.2.2
win32all version: 152
platform: win2k server with WSH 5.6

description:
I have a pythoncom server (using DynamicPolicy) with a 
function that takes a single parameter.  Calling that 
function from VB/VBScript using "Call" (ignoring the 
return value) causes the passed parameter to be set to 
the return value of that function.  If I assign the return 
value to a VB variable the parameter's value doesn't 
change:

'Python COM server
class Object:
  def _dynamic_(self, name, lcid, wFlags, args):
    return getattr( self, string.lower(name) )(*args)
  def func1(self, S1):
    pass

'Called From VBScript
Call obj.func1(param) 'Bad, param gets set to Null
rval = obj.func1(param) 'OK, param retains its value

I'm at a loss as to why this is.  The only difference I can 
see at the policy level is wFlags, with one style it's 3 
(DISPATCH_METHOD | DISPATCH_PROPERTYGET) 
and the other it's 1 (DISPATCH_METHOD)

Attached is a zip containing a pythoncom server, a 
VBScript test file and a batch (cmd) file to run the test.  
Please let me know if I've done something incorrectly.


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

>Comment By: Mark Hammond (mhammond)
Date: 2003-05-07 09:46

Message:
Logged In: YES 
user_id=14198

I'm afraid this is not a bug.  When you use call, VB does
not pass a value for the "result" (whereas in a normal call,
it does).  Your Python code always returns a result - when
called as a method, this is the method result - but when
called as a sub by using Call, Python passes this result
back for the first param (which VB passes as byref)

You can either examine the flags (as you noted, VB did
change the flags due to the change in semantics - in the
second case it is *not* a method) or you can create a type
library defining your interface using some external tool,
and Python will then conform (as VB will then know the
signature of the function you intended, rather than guessing
as it does now)


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

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

[pywin32-bugs] [ pywin32-Bugs-733540 ] Calling com server w/VB "Call" changes 1st param's value

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

Bugs item #733540, was opened at 2003-05-06 14:57
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=733540&group_id=78018

Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ryan Groe (ryangroe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling com server w/VB "Call" changes 1st param's value

Initial Comment:
python version: 2.2.2
win32all version: 152
platform: win2k server with WSH 5.6

description:
I have a pythoncom server (using DynamicPolicy) with a 
function that takes a single parameter.  Calling that 
function from VB/VBScript using "Call" (ignoring the 
return value) causes the passed parameter to be set to 
the return value of that function.  If I assign the return 
value to a VB variable the parameter's value doesn't 
change:

'Python COM server
class Object:
  def _dynamic_(self, name, lcid, wFlags, args):
    return getattr( self, string.lower(name) )(*args)
  def func1(self, S1):
    pass

'Called From VBScript
Call obj.func1(param) 'Bad, param gets set to Null
rval = obj.func1(param) 'OK, param retains its value

I'm at a loss as to why this is.  The only difference I can 
see at the policy level is wFlags, with one style it's 3 
(DISPATCH_METHOD | DISPATCH_PROPERTYGET) 
and the other it's 1 (DISPATCH_METHOD)

Attached is a zip containing a pythoncom server, a 
VBScript test file and a batch (cmd) file to run the test.  
Please let me know if I've done something incorrectly.


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

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

[pywin32-bugs] [ pywin32-Patches-732056 ] Fix memory leak in security descriptor functions

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

Patches item #732056, was opened at 2003-05-03 23:06
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=732056&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix memory leak in security descriptor functions

Initial Comment:
In function that converts security descriptor to absolute 
format, minium amount of memory for ACL's and Sid's 
was allocated, but if SACL, DACL, owner sid or group 
sid was not present it was never freed.


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

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

[pywin32-bugs] [ pywin32-Bugs-728896 ] Strange exception handling in win32api registry fns

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

Bugs item #728896, was opened at 2003-04-28 22:49
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=728896&group_id=78018

Category: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: Strange exception handling in win32api registry fns

Initial Comment:
Hi,

The registry handling methods in win32api seem to have
problems with
the Python exception handling. It took me some time,
but I have
managed to isolate the problem to a simple program. But
the problem is
more severe in more complicated situations, and there
it seems to
happen with most (or all) registry methods
(win32api.Reg...()).

The methods of _winreg module do not exhibit this
problem. For now, I
am using _winreg. However, it would be nice if the
problem could be
tracked down inside the win32api's source code and be
fixed.

regards,

Hung Jung Lu

#----------------------------------------------------------------------
# OS used: Windows XP
#
# Python 2.1
#     program works correctly: correct exception
message displayed
#
# Python 2.2.2 (win32all build 152)
#    (a) In Pythonwin intractive window, you get
#        SystemError: error return without exception set
#    (b) When running with python.exe, it crashes
#
# Python 2.3b1 (win32all build 153)
#    (a) In Pythonwin intractive window, you get
#        SystemError: error return without exception set
#    (b) When running with python.exe, program exits
silently,
#        which is not the correct behavior
#
# Comments:
#     (a) equivalent _winreg module methods do not have
problem.
#     (b) problem seems to happen with most, or all,
win32api.Reg...()
#         methods, not in this particular example, but
in more
#         complicated programs (involving classes)
#

import win32con
import win32api

def reg_operation():
    hkey =
win32api.RegCreateKey(win32con.HKEY_CURRENT_USER,
r'Software\Spam')
    x = 3/0 # or a statement like: raise 'error'

try: reg_operation()
except: x = 5/0 # or a statement like: raise 'error'

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

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

[pywin32-bugs] [ pywin32-Patches-725797 ] _exe_name_ for services does not (always) work

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

Patches item #725797, was opened at 2003-04-23 05:17
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=725797&group_id=78018

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: _exe_name_ for services does not (always) work

Initial Comment:
Under certain conditions, win32api.SearchPath() is
called on a service's _exe_name_.
This returns a tuple, not a string.
Patch attached.

And a feature request for _exe_args_!
Can supply a patch if needed.

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

>Comment By: Mark Hammond (mhammond)
Date: 2003-04-24 11:32

Message:
Logged In: YES 
user_id=14198

OK, I checked it all in.  Re policy for checkins - just via
patches would be fine, and when we agree you can check it
in.  Obvious bug fixes (like the first part of the patch)
could just be checked in, but new features (like the second)
should be discussed.  Eventually a list would be fine.  I
will see if I can add you now :)

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

Comment By: Thomas Heller (theller)
Date: 2003-04-23 19:38

Message:
Logged In: YES 
user_id=11105

I cannot delete the now obsolete patch: diff.txt, please
ignore (or remove yourself).

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

Comment By: Thomas Heller (theller)
Date: 2003-04-23 19:37

Message:
Logged In: YES 
user_id=11105

Here's the patch.

dev privs would certainly be nice, but you have to set up a
policy.
Will there be a pywin32-dev list, or where should things be
discussed?

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

Comment By: Mark Hammond (mhammond)
Date: 2003-04-23 10:03

Message:
Logged In: YES 
user_id=14198

ok, attach a patch with _exe_args and I'll apply it :)  You
interested in dev privs? ;)

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

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

[pywin32-bugs] [ pywin32-Patches-725797 ] _exe_name_ for services does not (always) work

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

Patches item #725797, was opened at 2003-04-22 21:17
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=725797&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: _exe_name_ for services does not (always) work

Initial Comment:
Under certain conditions, win32api.SearchPath() is
called on a service's _exe_name_.
This returns a tuple, not a string.
Patch attached.

And a feature request for _exe_args_!
Can supply a patch if needed.

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

>Comment By: Thomas Heller (theller)
Date: 2003-04-23 11:38

Message:
Logged In: YES 
user_id=11105

I cannot delete the now obsolete patch: diff.txt, please
ignore (or remove yourself).

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

Comment By: Thomas Heller (theller)
Date: 2003-04-23 11:37

Message:
Logged In: YES 
user_id=11105

Here's the patch.

dev privs would certainly be nice, but you have to set up a
policy.
Will there be a pywin32-dev list, or where should things be
discussed?

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

Comment By: Mark Hammond (mhammond)
Date: 2003-04-23 02:03

Message:
Logged In: YES 
user_id=14198

ok, attach a patch with _exe_args and I'll apply it :)  You
interested in dev privs? ;)

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

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

[pywin32-bugs] [ pywin32-Patches-725797 ] _exe_name_ for services does not (always) work

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

Patches item #725797, was opened at 2003-04-22 21:17
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=725797&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: _exe_name_ for services does not (always) work

Initial Comment:
Under certain conditions, win32api.SearchPath() is
called on a service's _exe_name_.
This returns a tuple, not a string.
Patch attached.

And a feature request for _exe_args_!
Can supply a patch if needed.

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

>Comment By: Thomas Heller (theller)
Date: 2003-04-23 11:37

Message:
Logged In: YES 
user_id=11105

Here's the patch.

dev privs would certainly be nice, but you have to set up a
policy.
Will there be a pywin32-dev list, or where should things be
discussed?

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

Comment By: Mark Hammond (mhammond)
Date: 2003-04-23 02:03

Message:
Logged In: YES 
user_id=14198

ok, attach a patch with _exe_args and I'll apply it :)  You
interested in dev privs? ;)

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

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

[pywin32-bugs] [ pywin32-Patches-725797 ] _exe_name_ for services does not (always) work

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

Patches item #725797, was opened at 2003-04-23 05:17
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=725797&group_id=78018

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: _exe_name_ for services does not (always) work

Initial Comment:
Under certain conditions, win32api.SearchPath() is
called on a service's _exe_name_.
This returns a tuple, not a string.
Patch attached.

And a feature request for _exe_args_!
Can supply a patch if needed.

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

>Comment By: Mark Hammond (mhammond)
Date: 2003-04-23 10:03

Message:
Logged In: YES 
user_id=14198

ok, attach a patch with _exe_args and I'll apply it :)  You
interested in dev privs? ;)

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

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