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

[pywin32-bugs] [ pywin32-Bugs-2671640 ] pywin32 amd64 installation error

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

Bugs item #2671640, was opened at 2009-03-07 11: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=2671640&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: installation
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Maxime Labelle (mlabelle3108)
Assigned to: Nobody/Anonymous (nobody)
Summary: pywin32 amd64 installation error

Initial Comment:
There is a problem in the "pywin32-213.win-amd64-py2.7.exe" installer when detecting if python 2.6 is installed. It will not find python 2.6 even though it is installed.

Running WinXP 64bit pro on AMD64.

Regards,

Max.

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

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

[pywin32-bugs] [ pywin32-Patches-2630059 ] patch for genpy.py to improve support for constants class

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Neuroth (mindia)
>Assigned to: Mark Hammond (mhammond)
Summary: patch for genpy.py to improve support for constants class

Initial Comment:
With the build 213 I had problems with a COM class when using genpy.py. The COM class has no constants defined but the method Generator.do_generate() in the genpy.py file had problems to generate a valid python class. The following construct was generated:

...
MajorVersion = 1
MinorVersion = 1
LibraryFlags = 8
LCID = 0x0

class constants:

from win32com.client import DispatchBaseClass
class IMyInterface(DispatchBaseClass):
	"""IMyInterface Interface"""
...

Unfortunately this code is not a valid python code.

I appied the following patch to genpy.py which helped me to fix this problem. Maybe a similar patch could be included into the original source code?

======= Modifications in genpy.py ==========

  def do_generate(self):
    ...
    # Generate the constants and their support.
    if enumItems:
        iTotalCount = 0                                             # PATCH
        print >> stream, "class constants:"
        items = enumItems.values()
        items.sort()
        for oleitem in items:
            iTotalCount += oleitem.WriteEnumerationItems(stream)    # PATCH
            self.progress.Tick()
        if iTotalCount==0:                                          # PATCH
            print >> stream, "\tpass"                               # PATCH
        print >> stream

    ...

class EnumerationItem(build.OleItem, WriteableItem):
  ...

  def WriteEnumerationItems(self, stream):
    enumName = self.doc[0]
    iItemCount = 0                                      # PATCH
    # Write in name alpha order
    names = list(self.mapVars.keys())
    names.sort()
    for name in names:
      entry = self.mapVars[name]
      vdesc = entry.desc
      if vdesc[4] == pythoncom.VAR_CONST:
        val = vdesc[1]
        if sys.version_info <= (2,4) and (isinstance(val, int) or isinstance(val, long)):
          # in python 2.3, 0x80000000L == 2147483648
          if val==2147483648: # == 0x80000000L - special case for 2.3...
            use = "0x80000000L" # 'L' for future warning
          elif val > 2147483648 or val < 0: # avoid a FutureWarning
            use = long(val)
          else:
            use = hex(val)
        else:
          use = repr(val)
        print >> stream, "\t%-30s=%-10s # from enum %s" % \
                      (build.MakePublicAttributeName(name, True), use, enumName)
        iItemCount += 1                                 # PATCH
    return iItemCount                                   # PATCH



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

>Comment By: Mark Hammond (mhammond)
Date: 2009-02-25 09:27

Message:
Right - typedefs also appear there, which explains things.  I certainly do
want pywin32 to be robust against *real* problems - I just needed to
understand this one well enough to convince myself it was real :)  I'll
apply your patch, thanks.

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

Comment By: Michael Neuroth (mindia)
Date: 2009-02-24 23:29

Message:
Sorry, I missed a line of code:

    typedef [public    ,
      custom(F914481D-9C62-4B43-9340-E9B2E6252E5F, 1)    
]
    unsigned long ULONG_PTR;


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

Comment By: Michael Neuroth (mindia)
Date: 2009-02-24 23:27

Message:
The COM object is until now only used internally. 
I found out that the following definition in the IDL file caused the
problems:

[id(7), helpstring("method getNumberInfos")] HRESULT getNumberInfos([out,
retval] SIZE_T* number);

This statement produced in the type library (I used OLEView to display
this information) this data:

typedef [public    ,
   custom(F914481D-9C62-4B43-9340-E9B2E6252E5F, 1)    
]

When I replaced the SIZE_T type in the method the problematic data in the
type library disappeared and genpy.py has no problems at all to generate a
valid python file.
I am not sure if the type SIZE_T is a valid COM type. The type SIZE_T is
defined in the header file BaseTds.h as follows:

typedef ULONG_PTR SIZE_T, *PSIZE_T;

And the COM object could be created with MS Visual Studio 2008 without
errors.
Isn't it a good idea to make the genpy.py code robust against 'unclean'
(but valid) input?



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

Comment By: Mark Hammond (mhammond)
Date: 2009-02-24 09:47

Message:
What COM object is this?  I'm interested to know how we are getting
enumeration items, but ending up with no constants.  In other words, the
correct fix may be elsewhere - to have enumItems only have real items with
constants and the existing check for enumItems to continue doing its job.

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

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

[pywin32-bugs] [ pywin32-Patches-2630059 ] patch for genpy.py to improve support for constants class

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

Patches item #2630059, was opened at 2009-02-23 13:53
Message generated for change (Comment added) made by mindia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2630059&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Neuroth (mindia)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch for genpy.py to improve support for constants class

Initial Comment:
With the build 213 I had problems with a COM class when using genpy.py. The COM class has no constants defined but the method Generator.do_generate() in the genpy.py file had problems to generate a valid python class. The following construct was generated:

...
MajorVersion = 1
MinorVersion = 1
LibraryFlags = 8
LCID = 0x0

class constants:

from win32com.client import DispatchBaseClass
class IMyInterface(DispatchBaseClass):
	"""IMyInterface Interface"""
...

Unfortunately this code is not a valid python code.

I appied the following patch to genpy.py which helped me to fix this problem. Maybe a similar patch could be included into the original source code?

======= Modifications in genpy.py ==========

  def do_generate(self):
    ...
    # Generate the constants and their support.
    if enumItems:
        iTotalCount = 0                                             # PATCH
        print >> stream, "class constants:"
        items = enumItems.values()
        items.sort()
        for oleitem in items:
            iTotalCount += oleitem.WriteEnumerationItems(stream)    # PATCH
            self.progress.Tick()
        if iTotalCount==0:                                          # PATCH
            print >> stream, "\tpass"                               # PATCH
        print >> stream

    ...

class EnumerationItem(build.OleItem, WriteableItem):
  ...

  def WriteEnumerationItems(self, stream):
    enumName = self.doc[0]
    iItemCount = 0                                      # PATCH
    # Write in name alpha order
    names = list(self.mapVars.keys())
    names.sort()
    for name in names:
      entry = self.mapVars[name]
      vdesc = entry.desc
      if vdesc[4] == pythoncom.VAR_CONST:
        val = vdesc[1]
        if sys.version_info <= (2,4) and (isinstance(val, int) or isinstance(val, long)):
          # in python 2.3, 0x80000000L == 2147483648
          if val==2147483648: # == 0x80000000L - special case for 2.3...
            use = "0x80000000L" # 'L' for future warning
          elif val > 2147483648 or val < 0: # avoid a FutureWarning
            use = long(val)
          else:
            use = hex(val)
        else:
          use = repr(val)
        print >> stream, "\t%-30s=%-10s # from enum %s" % \
                      (build.MakePublicAttributeName(name, True), use, enumName)
        iItemCount += 1                                 # PATCH
    return iItemCount                                   # PATCH



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

>Comment By: Michael Neuroth (mindia)
Date: 2009-02-24 13:29

Message:
Sorry, I missed a line of code:

    typedef [public    ,
      custom(F914481D-9C62-4B43-9340-E9B2E6252E5F, 1)    
]
    unsigned long ULONG_PTR;


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

Comment By: Michael Neuroth (mindia)
Date: 2009-02-24 13:27

Message:
The COM object is until now only used internally. 
I found out that the following definition in the IDL file caused the
problems:

[id(7), helpstring("method getNumberInfos")] HRESULT getNumberInfos([out,
retval] SIZE_T* number);

This statement produced in the type library (I used OLEView to display
this information) this data:

typedef [public    ,
   custom(F914481D-9C62-4B43-9340-E9B2E6252E5F, 1)    
]

When I replaced the SIZE_T type in the method the problematic data in the
type library disappeared and genpy.py has no problems at all to generate a
valid python file.
I am not sure if the type SIZE_T is a valid COM type. The type SIZE_T is
defined in the header file BaseTds.h as follows:

typedef ULONG_PTR SIZE_T, *PSIZE_T;

And the COM object could be created with MS Visual Studio 2008 without
errors.
Isn't it a good idea to make the genpy.py code robust against 'unclean'
(but valid) input?



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

Comment By: Mark Hammond (mhammond)
Date: 2009-02-23 23:47

Message:
What COM object is this?  I'm interested to know how we are getting
enumeration items, but ending up with no constants.  In other words, the
correct fix may be elsewhere - to have enumItems only have real items with
constants and the existing check for enumItems to continue doing its job.

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

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

[pywin32-bugs] [ pywin32-Patches-2630059 ] patch for genpy.py to improve support for constants class

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

Patches item #2630059, was opened at 2009-02-23 13:53
Message generated for change (Comment added) made by mindia
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2630059&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Neuroth (mindia)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch for genpy.py to improve support for constants class

Initial Comment:
With the build 213 I had problems with a COM class when using genpy.py. The COM class has no constants defined but the method Generator.do_generate() in the genpy.py file had problems to generate a valid python class. The following construct was generated:

...
MajorVersion = 1
MinorVersion = 1
LibraryFlags = 8
LCID = 0x0

class constants:

from win32com.client import DispatchBaseClass
class IMyInterface(DispatchBaseClass):
	"""IMyInterface Interface"""
...

Unfortunately this code is not a valid python code.

I appied the following patch to genpy.py which helped me to fix this problem. Maybe a similar patch could be included into the original source code?

======= Modifications in genpy.py ==========

  def do_generate(self):
    ...
    # Generate the constants and their support.
    if enumItems:
        iTotalCount = 0                                             # PATCH
        print >> stream, "class constants:"
        items = enumItems.values()
        items.sort()
        for oleitem in items:
            iTotalCount += oleitem.WriteEnumerationItems(stream)    # PATCH
            self.progress.Tick()
        if iTotalCount==0:                                          # PATCH
            print >> stream, "\tpass"                               # PATCH
        print >> stream

    ...

class EnumerationItem(build.OleItem, WriteableItem):
  ...

  def WriteEnumerationItems(self, stream):
    enumName = self.doc[0]
    iItemCount = 0                                      # PATCH
    # Write in name alpha order
    names = list(self.mapVars.keys())
    names.sort()
    for name in names:
      entry = self.mapVars[name]
      vdesc = entry.desc
      if vdesc[4] == pythoncom.VAR_CONST:
        val = vdesc[1]
        if sys.version_info <= (2,4) and (isinstance(val, int) or isinstance(val, long)):
          # in python 2.3, 0x80000000L == 2147483648
          if val==2147483648: # == 0x80000000L - special case for 2.3...
            use = "0x80000000L" # 'L' for future warning
          elif val > 2147483648 or val < 0: # avoid a FutureWarning
            use = long(val)
          else:
            use = hex(val)
        else:
          use = repr(val)
        print >> stream, "\t%-30s=%-10s # from enum %s" % \
                      (build.MakePublicAttributeName(name, True), use, enumName)
        iItemCount += 1                                 # PATCH
    return iItemCount                                   # PATCH



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

>Comment By: Michael Neuroth (mindia)
Date: 2009-02-24 13:27

Message:
The COM object is until now only used internally. 
I found out that the following definition in the IDL file caused the
problems:

[id(7), helpstring("method getNumberInfos")] HRESULT getNumberInfos([out,
retval] SIZE_T* number);

This statement produced in the type library (I used OLEView to display
this information) this data:

typedef [public    ,
   custom(F914481D-9C62-4B43-9340-E9B2E6252E5F, 1)    
]

When I replaced the SIZE_T type in the method the problematic data in the
type library disappeared and genpy.py has no problems at all to generate a
valid python file.
I am not sure if the type SIZE_T is a valid COM type. The type SIZE_T is
defined in the header file BaseTds.h as follows:

typedef ULONG_PTR SIZE_T, *PSIZE_T;

And the COM object could be created with MS Visual Studio 2008 without
errors.
Isn't it a good idea to make the genpy.py code robust against 'unclean'
(but valid) input?



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

Comment By: Mark Hammond (mhammond)
Date: 2009-02-23 23:47

Message:
What COM object is this?  I'm interested to know how we are getting
enumeration items, but ending up with no constants.  In other words, the
correct fix may be elsewhere - to have enumItems only have real items with
constants and the existing check for enumItems to continue doing its job.

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

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

[pywin32-bugs] [ pywin32-Patches-2630059 ] patch for genpy.py to improve support for constants class

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Neuroth (mindia)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch for genpy.py to improve support for constants class

Initial Comment:
With the build 213 I had problems with a COM class when using genpy.py. The COM class has no constants defined but the method Generator.do_generate() in the genpy.py file had problems to generate a valid python class. The following construct was generated:

...
MajorVersion = 1
MinorVersion = 1
LibraryFlags = 8
LCID = 0x0

class constants:

from win32com.client import DispatchBaseClass
class IMyInterface(DispatchBaseClass):
	"""IMyInterface Interface"""
...

Unfortunately this code is not a valid python code.

I appied the following patch to genpy.py which helped me to fix this problem. Maybe a similar patch could be included into the original source code?

======= Modifications in genpy.py ==========

  def do_generate(self):
    ...
    # Generate the constants and their support.
    if enumItems:
        iTotalCount = 0                                             # PATCH
        print >> stream, "class constants:"
        items = enumItems.values()
        items.sort()
        for oleitem in items:
            iTotalCount += oleitem.WriteEnumerationItems(stream)    # PATCH
            self.progress.Tick()
        if iTotalCount==0:                                          # PATCH
            print >> stream, "\tpass"                               # PATCH
        print >> stream

    ...

class EnumerationItem(build.OleItem, WriteableItem):
  ...

  def WriteEnumerationItems(self, stream):
    enumName = self.doc[0]
    iItemCount = 0                                      # PATCH
    # Write in name alpha order
    names = list(self.mapVars.keys())
    names.sort()
    for name in names:
      entry = self.mapVars[name]
      vdesc = entry.desc
      if vdesc[4] == pythoncom.VAR_CONST:
        val = vdesc[1]
        if sys.version_info <= (2,4) and (isinstance(val, int) or isinstance(val, long)):
          # in python 2.3, 0x80000000L == 2147483648
          if val==2147483648: # == 0x80000000L - special case for 2.3...
            use = "0x80000000L" # 'L' for future warning
          elif val > 2147483648 or val < 0: # avoid a FutureWarning
            use = long(val)
          else:
            use = hex(val)
        else:
          use = repr(val)
        print >> stream, "\t%-30s=%-10s # from enum %s" % \
                      (build.MakePublicAttributeName(name, True), use, enumName)
        iItemCount += 1                                 # PATCH
    return iItemCount                                   # PATCH



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

>Comment By: Mark Hammond (mhammond)
Date: 2009-02-24 09:47

Message:
What COM object is this?  I'm interested to know how we are getting
enumeration items, but ending up with no constants.  In other words, the
correct fix may be elsewhere - to have enumItems only have real items with
constants and the existing check for enumItems to continue doing its job.

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

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

[pywin32-bugs] [ pywin32-Patches-2630059 ] patch for genpy.py to improve support for constants class

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

Patches item #2630059, was opened at 2009-02-23 13:53
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=2630059&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Neuroth (mindia)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch for genpy.py to improve support for constants class

Initial Comment:
With the build 213 I had problems with a COM class when using genpy.py. The COM class has no constants defined but the method Generator.do_generate() in the genpy.py file had problems to generate a valid python class. The following construct was generated:

...
MajorVersion = 1
MinorVersion = 1
LibraryFlags = 8
LCID = 0x0

class constants:

from win32com.client import DispatchBaseClass
class IMyInterface(DispatchBaseClass):
	"""IMyInterface Interface"""
...

Unfortunately this code is not a valid python code.

I appied the following patch to genpy.py which helped me to fix this problem. Maybe a similar patch could be included into the original source code?

======= Modifications in genpy.py ==========

  def do_generate(self):
    ...
    # Generate the constants and their support.
    if enumItems:
        iTotalCount = 0                                             # PATCH
        print >> stream, "class constants:"
        items = enumItems.values()
        items.sort()
        for oleitem in items:
            iTotalCount += oleitem.WriteEnumerationItems(stream)    # PATCH
            self.progress.Tick()
        if iTotalCount==0:                                          # PATCH
            print >> stream, "\tpass"                               # PATCH
        print >> stream

    ...

class EnumerationItem(build.OleItem, WriteableItem):
  ...

  def WriteEnumerationItems(self, stream):
    enumName = self.doc[0]
    iItemCount = 0                                      # PATCH
    # Write in name alpha order
    names = list(self.mapVars.keys())
    names.sort()
    for name in names:
      entry = self.mapVars[name]
      vdesc = entry.desc
      if vdesc[4] == pythoncom.VAR_CONST:
        val = vdesc[1]
        if sys.version_info <= (2,4) and (isinstance(val, int) or isinstance(val, long)):
          # in python 2.3, 0x80000000L == 2147483648
          if val==2147483648: # == 0x80000000L - special case for 2.3...
            use = "0x80000000L" # 'L' for future warning
          elif val > 2147483648 or val < 0: # avoid a FutureWarning
            use = long(val)
          else:
            use = hex(val)
        else:
          use = repr(val)
        print >> stream, "\t%-30s=%-10s # from enum %s" % \
                      (build.MakePublicAttributeName(name, True), use, enumName)
        iItemCount += 1                                 # PATCH
    return iItemCount                                   # PATCH



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

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

[pywin32-bugs] [ pywin32-Bugs-2618277 ] backspacing over multibyte characters raises exception

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

Bugs item #2618277, was opened at 2009-02-19 17:34
Message generated for change (Comment added) made by metolone
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2618277&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: markt (metolone)
Assigned to: Nobody/Anonymous (nobody)
Summary: backspacing over multibyte characters raises exception

Initial Comment:
In Pythonwin from pywin32-213, and on both the 2.6 and 3.0 versions, when backspacing over the Chinese characters in the attached file (or any UTF-8 multibyte character), the first backspace displays the remaining UTF-8 code bytes instead of deleting the entire character.  Trying to save the file at this point or backspacing a second time throws exceptions.

The backspace exception (from 2.6) is:

Firing event '<<smart-backspace>>' failed.
Traceback (most recent call last):
  File "C:\dev\python\Lib\site-packages\pythonwin\pywin\scintilla\bindings.py", line 142, in fire
    rc = binding.handler(*args)
  File "C:\dev\python\Lib\site-packages\pythonwin\pywin\idle\AutoIndent.py", line 133, in smart_backspace_event
    chars = text.get("insert linestart", "insert")
  File "C:\dev\python\Lib\site-packages\pythonwin\pywin\scintilla\IDLEenvironment.py", line 343, in get
    ret = self.edit.GetTextRange(start, end)
  File "C:\dev\python\Lib\site-packages\pythonwin\pywin\scintilla\control.py", line 362, in GetTextRange
    ret = ret.decode(default_scintilla_encoding)
  File "C:\dev\python\lib\encodings\utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 11-12: unexpected end of data

Saving in 2.6 gives:

Traceback (most recent call last):
  File "C:\dev\python\Lib\site-packages\pythonwin\pywin\framework\editor\document.py", line 77, in OnSaveDocument
    self.SaveFile(fileName)
  File "C:\dev\python\Lib\site-packages\pythonwin\pywin\scintilla\document.py", line 54, in SaveFile
    ok = view.SaveTextFile(fileName)
  File "C:\dev\python\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 394, in SaveTextFile
    doc._SaveTextToFile(self, f)
  File "C:\dev\python\Lib\site-packages\pythonwin\pywin\scintilla\document.py", line 137, in _SaveTextToFile
    s = view.GetTextRange() # already decoded from scintilla's encoding
  File "C:\dev\python\Lib\site-packages\pythonwin\pywin\scintilla\control.py", line 362, in GetTextRange
    ret = ret.decode(default_scintilla_encoding)
  File "C:\dev\python\lib\encodings\utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 28-30: invalid data
win32ui.error: OnSaveDocument() virtual handler (<bound method SyntEditDocument.OnSaveDocument of <pywin.framework.editor.color.coloreditor.SyntEditDocument instance at 0x00F27D00>>) raised an exception



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

Comment By: markt (metolone)
Date: 2009-02-19 18:26

Message:
I made a fix to pythonwin\pywin\scintilla\IDLEenvironment.py that appears
to correct the problem.  I found a function _fix_eol_indexes() that
corrected for partial deletion of \r\n.  The function, now named
_fix_indexes(), now corrects for partial deletion of UTF8 chars as well.  I
uploaded the file.  It works by making sure the start and end variables
point to the start of a valid UTF8 character.  In a UTF8 byte, bit 7 on and
bit 6 off is an intermediate byte.

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

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

[pywin32-bugs] [ pywin32-Bugs-2618277 ] backspacing over multibyte characters raises exception

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

Bugs item #2618277, was opened at 2009-02-19 17:34
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=2618277&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: markt (metolone)
Assigned to: Nobody/Anonymous (nobody)
Summary: backspacing over multibyte characters raises exception

Initial Comment:
In Pythonwin from pywin32-213, and on both the 2.6 and 3.0 versions, when backspacing over the Chinese characters in the attached file (or any UTF-8 multibyte character), the first backspace displays the remaining UTF-8 code bytes instead of deleting the entire character.  Trying to save the file at this point or backspacing a second time throws exceptions.

The backspace exception (from 2.6) is:

Firing event '<<smart-backspace>>' failed.
Traceback (most recent call last):
  File "C:\dev\python\Lib\site-packages\pythonwin\pywin\scintilla\bindings.py", line 142, in fire
    rc = binding.handler(*args)
  File "C:\dev\python\Lib\site-packages\pythonwin\pywin\idle\AutoIndent.py", line 133, in smart_backspace_event
    chars = text.get("insert linestart", "insert")
  File "C:\dev\python\Lib\site-packages\pythonwin\pywin\scintilla\IDLEenvironment.py", line 343, in get
    ret = self.edit.GetTextRange(start, end)
  File "C:\dev\python\Lib\site-packages\pythonwin\pywin\scintilla\control.py", line 362, in GetTextRange
    ret = ret.decode(default_scintilla_encoding)
  File "C:\dev\python\lib\encodings\utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 11-12: unexpected end of data

Saving in 2.6 gives:

Traceback (most recent call last):
  File "C:\dev\python\Lib\site-packages\pythonwin\pywin\framework\editor\document.py", line 77, in OnSaveDocument
    self.SaveFile(fileName)
  File "C:\dev\python\Lib\site-packages\pythonwin\pywin\scintilla\document.py", line 54, in SaveFile
    ok = view.SaveTextFile(fileName)
  File "C:\dev\python\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 394, in SaveTextFile
    doc._SaveTextToFile(self, f)
  File "C:\dev\python\Lib\site-packages\pythonwin\pywin\scintilla\document.py", line 137, in _SaveTextToFile
    s = view.GetTextRange() # already decoded from scintilla's encoding
  File "C:\dev\python\Lib\site-packages\pythonwin\pywin\scintilla\control.py", line 362, in GetTextRange
    ret = ret.decode(default_scintilla_encoding)
  File "C:\dev\python\lib\encodings\utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 28-30: invalid data
win32ui.error: OnSaveDocument() virtual handler (<bound method SyntEditDocument.OnSaveDocument of <pywin.framework.editor.color.coloreditor.SyntEditDocument instance at 0x00F27D00>>) raised an exception



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

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

[pywin32-bugs] [ pywin32-Bugs-2609380 ] Cannot load .pyd files in ISAPI Extension

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot load .pyd files in ISAPI Extension

Initial Comment:
Under IIS 7 (Windows Vista SP1) 32-bit or 64-bit and Python 2.6, I'm unable to load .pyd modules, including those in the standard library (e.g. _socket, _hashlib), from an ISAPI extension. I'm attaching a minimal use case that reproduces the issue.  To reproduce, install the ISAPI extension and then request http://localhost/pyd-fails/.  The issue does not occur in Python 2.5.  The issue was discovered with pywin32-212 but also is found in pywin32-213.

The output reported by the win32traceutil is the following:

trace on
Internal Extension Error: Factory function '__ExtensionFactory__' failed
Last Windows error: The specified module could not be found.
Traceback (most recent call last):
  File "C:\inetpub\isapi_test\pyd_fails.py", line 7, in __ExtensionFactory__
    import _hashlib
ImportError: DLL load failed: The specified module could not be found.

The underlying windows error code (found by calling LoadLibrary directly) is 126.  I used the Dependency Walker (depends.exe) to open Python\DLLs\_hashlib.pyd and depends.exe reports that msvcr90.dll is missing.  This DLL is part of the Windows Side-by-Side library management stuff that I still don't fully understand, and the DLL can be found in \Windows\winsxs\x??_microsoft.vc90.crt_*\msvcr90.dll (in two locations on each of my two machines).

As a test, I tried copying msvcr90.dll (tried both versions) to \python\dlls and retried the test. In this case, I get a different error: LoadLibrary returns error 1114: A dynamic link library (DLL) initialization routine failed.  This error seems to indicate that the msvcr90.dll is trying to load code at the same addresses as something that ISAPI has already loaded into its code space.

As expected, loading the _hashlib.pyd or _pyd_fails.dll files from a standalone python process has no problems.  Only in the context of ISAPI do the .pyd files fail to load.

I'm going to investigate AppPool and Security Settings to see if I can find a configuration that works in Python 2.6.

In the meantime, any suggestions would be appreciated.

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

>Comment By: Jason R. Coombs (jaraco)
Date: 2009-02-19 16:01

Message:
Confirmed the fix in the yet-unreleased Python 2.6.2.  Also works in Python
3.0.1.

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

Comment By: Mark Hammond (mhammond)
Date: 2009-02-17 17:34

Message:
I fear this problem is related to how Python loads the DLLS; Python 2.6's
svn tree has a fix in but is yet to be released.  Possibly the best way to
confirm this is to try it out with Python 3.0.1 - that has the fix in it,
so if that does work, I'm afraid the only real solution is to wait for the
next 2.6 build or use a patched python26.dll (contact me for this if you
want to try that)

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

Comment By: Jason R. Coombs (jaraco)
Date: 2009-02-17 10:26

Message:
I experimented with different App Pools, running under Admin credentials
and with no .Net Framework and a Classic Pipeline, but the same error
occurs.  An environment-based workaround does not seem promising.

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

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

[pywin32-bugs] [ pywin32-Bugs-2613356 ] win32serviceutil.HandleCommandLine missing error code return

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Guilherme Polo (ggpolo)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32serviceutil.HandleCommandLine missing error code return

Initial Comment:
Hi,

It didn't fit on the summary line, but win32serviceutil.HandleCommandLine does not return the error code when starting a service (it is missing an "err = hr" after "except win32service.error, (hr, fn, msg):"). 

I have pywin32-212.win-py2.6 installed.

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

>Comment By: Mark Hammond (mhammond)
Date: 2009-02-19 08:32

Message:
Thanks; fixed in revision 1.32

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

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

[pywin32-bugs] [ pywin32-Bugs-2613356 ] win32serviceutil.HandleCommandLine missing error code return

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

Bugs item #2613356, was opened at 2009-02-18 14:17
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=2613356&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Guilherme Polo (ggpolo)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32serviceutil.HandleCommandLine missing error code return

Initial Comment:
Hi,

It didn't fit on the summary line, but win32serviceutil.HandleCommandLine does not return the error code when starting a service (it is missing an "err = hr" after "except win32service.error, (hr, fn, msg):"). 

I have pywin32-212.win-py2.6 installed.

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

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

[pywin32-bugs] [ pywin32-Bugs-2609380 ] Cannot load .pyd files in ISAPI Extension

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot load .pyd files in ISAPI Extension

Initial Comment:
Under IIS 7 (Windows Vista SP1) 32-bit or 64-bit and Python 2.6, I'm unable to load .pyd modules, including those in the standard library (e.g. _socket, _hashlib), from an ISAPI extension. I'm attaching a minimal use case that reproduces the issue.  To reproduce, install the ISAPI extension and then request http://localhost/pyd-fails/.  The issue does not occur in Python 2.5.  The issue was discovered with pywin32-212 but also is found in pywin32-213.

The output reported by the win32traceutil is the following:

trace on
Internal Extension Error: Factory function '__ExtensionFactory__' failed
Last Windows error: The specified module could not be found.
Traceback (most recent call last):
  File "C:\inetpub\isapi_test\pyd_fails.py", line 7, in __ExtensionFactory__
    import _hashlib
ImportError: DLL load failed: The specified module could not be found.

The underlying windows error code (found by calling LoadLibrary directly) is 126.  I used the Dependency Walker (depends.exe) to open Python\DLLs\_hashlib.pyd and depends.exe reports that msvcr90.dll is missing.  This DLL is part of the Windows Side-by-Side library management stuff that I still don't fully understand, and the DLL can be found in \Windows\winsxs\x??_microsoft.vc90.crt_*\msvcr90.dll (in two locations on each of my two machines).

As a test, I tried copying msvcr90.dll (tried both versions) to \python\dlls and retried the test. In this case, I get a different error: LoadLibrary returns error 1114: A dynamic link library (DLL) initialization routine failed.  This error seems to indicate that the msvcr90.dll is trying to load code at the same addresses as something that ISAPI has already loaded into its code space.

As expected, loading the _hashlib.pyd or _pyd_fails.dll files from a standalone python process has no problems.  Only in the context of ISAPI do the .pyd files fail to load.

I'm going to investigate AppPool and Security Settings to see if I can find a configuration that works in Python 2.6.

In the meantime, any suggestions would be appreciated.

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

>Comment By: Mark Hammond (mhammond)
Date: 2009-02-18 09:34

Message:
I fear this problem is related to how Python loads the DLLS; Python 2.6's
svn tree has a fix in but is yet to be released.  Possibly the best way to
confirm this is to try it out with Python 3.0.1 - that has the fix in it,
so if that does work, I'm afraid the only real solution is to wait for the
next 2.6 build or use a patched python26.dll (contact me for this if you
want to try that)

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

Comment By: Jason R. Coombs (jaraco)
Date: 2009-02-18 02:26

Message:
I experimented with different App Pools, running under Admin credentials
and with no .Net Framework and a Classic Pipeline, but the same error
occurs.  An environment-based workaround does not seem promising.

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

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

[pywin32-bugs] [ pywin32-Bugs-2609380 ] Cannot load .pyd files in ISAPI Extension

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot load .pyd files in ISAPI Extension

Initial Comment:
Under IIS 7 (Windows Vista SP1) 32-bit or 64-bit and Python 2.6, I'm unable to load .pyd modules, including those in the standard library (e.g. _socket, _hashlib), from an ISAPI extension. I'm attaching a minimal use case that reproduces the issue.  To reproduce, install the ISAPI extension and then request http://localhost/pyd-fails/.  The issue does not occur in Python 2.5.  The issue was discovered with pywin32-212 but also is found in pywin32-213.

The output reported by the win32traceutil is the following:

trace on
Internal Extension Error: Factory function '__ExtensionFactory__' failed
Last Windows error: The specified module could not be found.
Traceback (most recent call last):
  File "C:\inetpub\isapi_test\pyd_fails.py", line 7, in __ExtensionFactory__
    import _hashlib
ImportError: DLL load failed: The specified module could not be found.

The underlying windows error code (found by calling LoadLibrary directly) is 126.  I used the Dependency Walker (depends.exe) to open Python\DLLs\_hashlib.pyd and depends.exe reports that msvcr90.dll is missing.  This DLL is part of the Windows Side-by-Side library management stuff that I still don't fully understand, and the DLL can be found in \Windows\winsxs\x??_microsoft.vc90.crt_*\msvcr90.dll (in two locations on each of my two machines).

As a test, I tried copying msvcr90.dll (tried both versions) to \python\dlls and retried the test. In this case, I get a different error: LoadLibrary returns error 1114: A dynamic link library (DLL) initialization routine failed.  This error seems to indicate that the msvcr90.dll is trying to load code at the same addresses as something that ISAPI has already loaded into its code space.

As expected, loading the _hashlib.pyd or _pyd_fails.dll files from a standalone python process has no problems.  Only in the context of ISAPI do the .pyd files fail to load.

I'm going to investigate AppPool and Security Settings to see if I can find a configuration that works in Python 2.6.

In the meantime, any suggestions would be appreciated.

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

>Comment By: Jason R. Coombs (jaraco)
Date: 2009-02-17 10:26

Message:
I experimented with different App Pools, running under Admin credentials
and with no .Net Framework and a Classic Pipeline, but the same error
occurs.  An environment-based workaround does not seem promising.

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

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

[pywin32-bugs] [ pywin32-Bugs-2609380 ] Cannot load .pyd files in ISAPI Extension

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

Bugs item #2609380, was opened at 2009-02-17 10:12
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=2609380&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot load .pyd files in ISAPI Extension

Initial Comment:
Under IIS 7 (Windows Vista SP1) 32-bit or 64-bit and Python 2.6, I'm unable to load .pyd modules, including those in the standard library (e.g. _socket, _hashlib), from an ISAPI extension. I'm attaching a minimal use case that reproduces the issue.  To reproduce, install the ISAPI extension and then request http://localhost/pyd-fails/.  The issue does not occur in Python 2.5.  The issue was discovered with pywin32-212 but also is found in pywin32-213.

The output reported by the win32traceutil is the following:

trace on
Internal Extension Error: Factory function '__ExtensionFactory__' failed
Last Windows error: The specified module could not be found.
Traceback (most recent call last):
  File "C:\inetpub\isapi_test\pyd_fails.py", line 7, in __ExtensionFactory__
    import _hashlib
ImportError: DLL load failed: The specified module could not be found.

The underlying windows error code (found by calling LoadLibrary directly) is 126.  I used the Dependency Walker (depends.exe) to open Python\DLLs\_hashlib.pyd and depends.exe reports that msvcr90.dll is missing.  This DLL is part of the Windows Side-by-Side library management stuff that I still don't fully understand, and the DLL can be found in \Windows\winsxs\x??_microsoft.vc90.crt_*\msvcr90.dll (in two locations on each of my two machines).

As a test, I tried copying msvcr90.dll (tried both versions) to \python\dlls and retried the test. In this case, I get a different error: LoadLibrary returns error 1114: A dynamic link library (DLL) initialization routine failed.  This error seems to indicate that the msvcr90.dll is trying to load code at the same addresses as something that ISAPI has already loaded into its code space.

As expected, loading the _hashlib.pyd or _pyd_fails.dll files from a standalone python process has no problems.  Only in the context of ISAPI do the .pyd files fail to load.

I'm going to investigate AppPool and Security Settings to see if I can find a configuration that works in Python 2.6.

In the meantime, any suggestions would be appreciated.

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

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

[pywin32-bugs] [ pywin32-Bugs-2606821 ] setup.py fails

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: installation
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Jacques Merde (jacques_merde)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py fails

Initial Comment:
setup.py (pywin32-212.zip) fails when invoked from cygwin with Python 2.5.2 with the following messages:

import: unable to open X server `'.
import: unable to open X server `'.
import: unable to open X server `'.
import: unable to open X server `'.
./setup.py: line 74: $'\r': command not found
./setup.py: line 76: $'try:\r': command not found
./setup.py: line 77: $'False\r': command not found
./setup.py: line 78: except: command not found
./setup.py: line 81: $'\r': command not found
./setup.py: line 83: from: command not found
./setup.py: line 84: from: command not found
./setup.py: line 85: from: command not found
./setup.py: line 86: from: command not found
./setup.py: line 87: from: command not found
./setup.py: line 88: from: command not found
./setup.py: line 89: $'try:\r': command not found
./setup.py: line 90: from: command not found
./setup.py: line 91: except: command not found
./setup.py: line 93: bdist_msi: command not found
./setup.py: line 94: $'try:\r': command not found
./setup.py: line 95: from: command not found
./setup.py: line 96: except: command not found
./setup.py: line 98: syntax error near unexpected token `('
./setup.py: line 98: `    def get_build_version():


IMHO, setup.py should *not* fail, instead it should politely inform that cygwin installs are not supported.



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

>Comment By: Mark Hammond (mhammond)
Date: 2009-02-17 08:20

Message:
The problem is cygwin doesn't like \r\n line endings.  There is nothing I
can do about that and no way I can make the script politely complain -
cygwin will not even *start* the script so I can output an error.

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

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

[pywin32-bugs] [ pywin32-Bugs-2606821 ] setup.py fails

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

Bugs item #2606821, was opened at 2009-02-16 20:34
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=2606821&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jacques Merde (jacques_merde)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py fails

Initial Comment:
setup.py (pywin32-212.zip) fails when invoked from cygwin with Python 2.5.2 with the following messages:

import: unable to open X server `'.
import: unable to open X server `'.
import: unable to open X server `'.
import: unable to open X server `'.
./setup.py: line 74: $'\r': command not found
./setup.py: line 76: $'try:\r': command not found
./setup.py: line 77: $'False\r': command not found
./setup.py: line 78: except: command not found
./setup.py: line 81: $'\r': command not found
./setup.py: line 83: from: command not found
./setup.py: line 84: from: command not found
./setup.py: line 85: from: command not found
./setup.py: line 86: from: command not found
./setup.py: line 87: from: command not found
./setup.py: line 88: from: command not found
./setup.py: line 89: $'try:\r': command not found
./setup.py: line 90: from: command not found
./setup.py: line 91: except: command not found
./setup.py: line 93: bdist_msi: command not found
./setup.py: line 94: $'try:\r': command not found
./setup.py: line 95: from: command not found
./setup.py: line 96: except: command not found
./setup.py: line 98: syntax error near unexpected token `('
./setup.py: line 98: `    def get_build_version():


IMHO, setup.py should *not* fail, instead it should politely inform that cygwin installs are not supported.



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

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

[pywin32-bugs] [ pywin32-Bugs-1799934 ] easy_install silently fails

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

Bugs item #1799934, was opened at 2007-09-21 20:29
Message generated for change (Comment added) made by zooko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1799934&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: easy_install silently fails

Initial Comment:
If I install pywin32 by executing pywin32-210.win32-py2.5.exe , it works.

If I run "easy_install pywin32" then it claims that it is downloading and installing pywin32-210.win32-py2.5.exe , and after a while it claims that it has successfully installed it, but an attempt to use pywin32 yields errors like this:

$ python -c 'import win32process'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: DLL load failed: The specified module could not be found.


I'm not sure whether this should be considered a bug in pywin32 or in easy_install, or both.

Regards,

Zooko

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

>Comment By: Zooko O'Whielacronx (zooko)
Date: 2009-02-13 22:28

Message:
Well, I think I was wrong when I said that pywin32 212 can be
easy_install'ed.  Probably I accidentally already had pywin32 installed
when I tested it.  I just tested it again and it doesn't work --
ImportError win32api.

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2009-01-02 18:10

Message:
Having pywin32 hosted somewhere that easy_install will discover is needed
for the imminent release of tahoe-lafs v1.3.0.  However, if the current
release of pywin32 is not hosted on pypi, we can instead upload a copy of
the pywin32 package to a tahoe grid.  :-)

http://allmydata.org/trac/tahoe/ticket/566 # host tahoe dependencies on a
tahoe grid

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-12-29 17:19

Message:
Please upload pywin32 212 to http://pypi.python.org and then we can close
this ticket.

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-12-03 12:07

Message:
Okay I just tested pywin32 212 with the latest trunk of setuptools
(0.6c10dev), and it worked!  However, the pywin32 package is not linked
from http://pypi.python.org/simple/pywin32 , so easy_install doesn't know
how to download it.  Please put a link on
http://pypi.python.org/simple/pywin32 pointing to the 212 binaries and this
ticket is done.

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

Comment By: Hartmut Goebel (htgoebel)
Date: 2008-09-04 10:29

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

There are actually two problems:

1) pywin32_postinstall.py can not be run manually when using eggs since it
does not use pkg_resources.

   This is fixed by patch 2092722
  
<http://sourceforge.net/tracker/index.php?func=detail&aid=2092722&group_id=78018&atid=551956>.

2) easy_install does not run pywin32_postinstall.py. It looks like there
is no mechanism to do this.

   This problem has been filed at
<http://bugs.python.org/setuptools/issue18>



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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-06-02 20:31

Message:
Logged In: YES 
user_id=52562
Originator: YES

This is the ticket on the setuptools issue tracker to track the progress
of fixing this in setuptools:

http://bugs.python.org/setuptools/issue18

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-03 01:30

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

That installer is quite recent - you may need to get the latest setuptools
rather than the latest pywin32.  Either way, just grab the CVS sources,
install the Vista SDK, and execute "setup.py" - to get some basic
instructions printed.

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-05-03 00:56

Message:
Logged In: YES 
user_id=52562
Originator: YES

Well, I'm afraid that
starship.python.net/crew/mhammond/pywin32-210.9.win32-py2.5.exe doesn't
work with the current setuptools -- setuptools v0.6 final.  Could you tell
me how to build pywin32 packages from CVS so I can experiment?  Thanks.

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-03 00:39

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

Try starship.python.net/crew/mhammond/pywin32-210.9.win32-py2.5.exe.  Note
I'm not sure of the status of the bug I referred to - ie, I'm not sure if a
released version of setuptools has the bug fixed (but I assume you are
ontop of that :)

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-05-02 17:48

Message:
Logged In: YES 
user_id=52562
Originator: YES

Hi, I went to test this so I could definitely close this bug, but it turns
out that pywin32 build 211 isn't downloadable yet.


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

Comment By: SourceForge Robot (sf-robot)
Date: 2008-04-23 02:20

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

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: Mark Hammond (mhammond)
Date: 2008-04-08 21:20

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

I believe PJE recently fixed a bug in setuptools that was causing problems
with pywin32 as an egg.  Please try again after build 211 is released.

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-01-25 14:17

Message:
Logged In: YES 
user_id=52562
Originator: YES


See also:

http://mail.python.org/pipermail/distutils-sig/2007-July/007823.html


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

Comment By: Mark Hammond (mhammond)
Date: 2007-09-30 23:33

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

I've no idea - that too is an easy_install question.  I've never used
easy_install to install pywin32, and I've never recommended anyone else do
it either.

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2007-09-30 22:57

Message:
Logged In: YES 
user_id=52562
Originator: YES

I will see if I can make the pywin32_postinstall.py stuff get done
automatically upon easy_install.

In the meantime, is there some way to make this failure loud instead of
silent?  How do you tell easy_install: yes, there is a package in the
expected format (.zip) in the expected place (pypi), but it isn't actually
going to work?


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

Comment By: Mark Hammond (mhammond)
Date: 2007-09-21 23:57

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

After install, pywin32_postinstall.py needs to be run, but ezsetup
apparently does not provide a facility to do that.  You may like to ask
them for such a facility.

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

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

[pywin32-bugs] [ pywin32-Bugs-2560493 ] No option to change default background.

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

Bugs item #2560493, was opened at 2009-02-03 06:39
Message generated for change (Settings changed) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2560493&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: MizardX (mizardx)
Assigned to: Roger Upole (rupole)
Summary: No option to change default background.

Initial Comment:
In my quest to get a light-on-dark theme in the editor, I found the "Default Background" registry option. But there is no control to change that in the "Pythonwin Options"-dialog.

"Default Background" is referenced from pywin\scintilla\formatter.py on line 77:
    bg = int( self.LoadPreference( "Default Background", -1 ) )

I do not have enough knowledge of C++ and windows-programming to attempt to add a new control to the dialog.

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

>Comment By: Roger Upole (rupole)
Date: 2009-02-08 20:42

Message:
Just committed formatter.py r1.20 and configui.py r1.7,
which allow you to set the overall background via the
"Whitespace background" setting.


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

Comment By: Roger Upole (rupole)
Date: 2009-02-08 16:07

Message:
>From looking at the code, it appears that the whitespace
background (registered as STYLE_DEFAULT) was originally
intended to be the overall default background.  This
should be doable without any changes to the UI.  Unless
anybody has any objections, I'll implement this and
remove the hidden registry setting altogether.


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

Comment By: MizardX (mizardx)
Date: 2009-02-03 07:02

Message:
For anyone who would be interested in a light-on-dark theme (rip of the
desert theme from gvim), here is a reg-file with the appropriate settings.
Folding does not work with this theme (and gets disabled my the reg-file),
as it is currently impossible to change the color of the folding-column
trough settings alone. Also, it uses the 'Consolas' font instead of the
default 'Courier New'.
File Added: desert_theme.reg

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

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

[pywin32-bugs] [ pywin32-Bugs-2560427 ] Line number formatting

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

Bugs item #2560427, was opened at 2009-02-03 06:17
Message generated for change (Settings changed) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2560427&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: MizardX (mizardx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Line number formatting

Initial Comment:
I can't change the formatting of the line-numbers.

I'm attaching a patch file which adds two more list items to the "Formatting"-tab in the "Pythonwin Options"-dialog.

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

>Comment By: Roger Upole (rupole)
Date: 2009-02-08 16:38

Message:
Patch applied in r1.19, thanks again!


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

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

[pywin32-bugs] [ pywin32-Bugs-2560493 ] No option to change default background.

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: MizardX (mizardx)
>Assigned to: Roger Upole (rupole)
Summary: No option to change default background.

Initial Comment:
In my quest to get a light-on-dark theme in the editor, I found the "Default Background" registry option. But there is no control to change that in the "Pythonwin Options"-dialog.

"Default Background" is referenced from pywin\scintilla\formatter.py on line 77:
    bg = int( self.LoadPreference( "Default Background", -1 ) )

I do not have enough knowledge of C++ and windows-programming to attempt to add a new control to the dialog.

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

>Comment By: Roger Upole (rupole)
Date: 2009-02-08 16:07

Message:
>From looking at the code, it appears that the whitespace
background (registered as STYLE_DEFAULT) was originally
intended to be the overall default background.  This
should be doable without any changes to the UI.  Unless
anybody has any objections, I'll implement this and
remove the hidden registry setting altogether.


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

Comment By: MizardX (mizardx)
Date: 2009-02-03 07:02

Message:
For anyone who would be interested in a light-on-dark theme (rip of the
desert theme from gvim), here is a reg-file with the appropriate settings.
Folding does not work with this theme (and gets disabled my the reg-file),
as it is currently impossible to change the color of the folding-column
trough settings alone. Also, it uses the 'Consolas' font instead of the
default 'Courier New'.
File Added: desert_theme.reg

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

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

[pywin32-bugs] [ pywin32-Bugs-2560391 ] Fold margin default values inconsistent

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: MizardX (mizardx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fold margin default values inconsistent

Initial Comment:
When you first start the editor the margin is small. If you go to options and change anything in the "Editor"-tab, the margin suddenly gets bigger.

This is due to different default values in pywin/framework/editor/color/coloreditor.py and pywin/framework/editor/configui.py

I'm attaching a patch which fixes this.

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

>Comment By: Roger Upole (rupole)
Date: 2009-02-08 15:22

Message:
Thanks again, fixed in r1.9.


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

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

[pywin32-bugs] [ pywin32-Bugs-2560351 ] Can't change Folding Margin width

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: MizardX (mizardx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't change Folding Margin width

Initial Comment:
Changing the value of "Folding" under "Margin Widths" on the "Editor"-tab in the "Pythonwin Options"-dialog have no effect on the editor.

I'm attaching a patch-file which fixes this.

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

>Comment By: Roger Upole (rupole)
Date: 2009-02-08 15:13

Message:
Many thanks, patch applied in r 1.16.


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

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

[pywin32-bugs] [ pywin32-Patches-1937527 ] win32file.ConnectEx patch

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

Patches item #1937527, was opened at 2008-04-08 12:32
Message generated for change (Comment added) made by ionel_mc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1937527&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: ionel (ionel_mc)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.ConnectEx patch

Initial Comment:
A patch for ConnectEx.

called as follows:
win32file.ConnectEx(sock, (host, port), overlappedobj [, bufferobj])

here's an example:
import socket, win32file, pywintypes
s = socket.socket()
ol = pywintypes.OVERLAPPED()
s.bind(('0.0.0.0', 0)) # connectex requires the socket be bound beforehand

print win32file.ConnectEx(s, ("google.com", 80), ol, "GET / HTTP/1.1\r\n\r\n")
print win32file.GetOverlappedResult(s.fileno(), ol, 1)
ol = pywintypes.OVERLAPPED()
buff = win32file.AllocateReadBuffer(20480)
print win32file.WSARecv(s, buff, ol, 0)
print win32file.GetOverlappedResult(s.fileno(), ol, 1)        
print buff


I've tested this on win xp.
I use getaddrinfo to process the (host, port) tuple.

Please review.


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

>Comment By: ionel (ionel_mc)
Date: 2009-02-07 14:00

Message:
this patch is included in #1962146 (the TransmitFile + ConnectEx patch) and
that was applied

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

Comment By: Mark Hammond (mhammond)
Date: 2009-02-07 03:58

Message:
Roger has this in his py3k branch so its now merged to the trunk - thanks
for your patience.

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

Comment By: Mark Hammond (mhammond)
Date: 2009-02-07 03:57

Message:
Roger has this in his py3k branch so its now merged to the trunk - thanks
for your patience.

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

Comment By: ionel (ionel_mc)
Date: 2008-05-09 03:36

Message:
Logged In: YES 
user_id=1189761
Originator: YES

To be completely honest I don't really know how to use the tuples returned
from the socket.getaddrinfo - since they are very far from the C addrinfo
struct I need to use in the ConnectEx call, also, i don't think the python
function call overhead to get that addrinfo and make whatever conversions
back to the struct is worth it.

I would add some sort of demo but i need some suggestions (it seems I lack
imagination right now).

I don't cover the corner cases (like bad params) in the test_connectex.




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

Comment By: ionel (ionel_mc)
Date: 2008-05-09 03:25

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: test_connectex.py

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-05 13:33

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

This looks pretty good.  I'd probably prefer for getaddrinfo() to be
called by the user of this function, and the necessary info passed in - is
there a reason not to do that?  Also, would you be so kind as to add
something to the win32\test directory (and maybe even the win32\Demos
directory :) that covers this?

Thanks!

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

Comment By: ionel (ionel_mc)
Date: 2008-04-24 11:22

Message:
Logged In: YES 
user_id=1189761
Originator: YES

wops, forgot something
File Added: win32file.i-4.patch

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

Comment By: ionel (ionel_mc)
Date: 2008-04-24 11:22

Message:
Logged In: YES 
user_id=1189761
Originator: YES

wops, forgot something
File Added: win32file.i-4.patch

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

Comment By: ionel (ionel_mc)
Date: 2008-04-24 10:57

Message:
Logged In: YES 
user_id=1189761
Originator: YES

ok i've made some changes:
i've moved the wsaioctl in the function body 
  - the msdn docs didn't say if the pointer i'm getting is always the
same
  - wsaioctl requires a wsainit before, i feel win32file is the wrong
place to do that and i don't want to force users to import the socket
module (for wsainit) before win32file
still looking for some feedback on this one though.

i've changed the buffer handling parts to use the 'buffer api'

File Added: win32file.i-3.patch

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

Comment By: ionel (ionel_mc)
Date: 2008-04-24 10:57

Message:
Logged In: YES 
user_id=1189761
Originator: YES

ok i've made some changes:
i've moved the wsaioctl in the function body 
  - the msdn docs didn't say if the pointer i'm getting is always the
same
  - wsaioctl requires a wsainit before, i feel win32file is the wrong
place to do that and i don't want to force users to import the socket
module (for wsainit) before win32file
still looking for some feedback on this one though.

i've changed the buffer handling parts to use the 'buffer api'

File Added: win32file.i-3.patch

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

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

[pywin32-bugs] [ pywin32-Patches-1727357 ] new VC8.0 build patch for AMD64 branch (inc axdebug)

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Steve Yin (steveyin)
Assigned to: Nobody/Anonymous (nobody)
Summary: new VC8.0 build patch for AMD64 branch (inc axdebug)

Initial Comment:
hi mhammond, I have reviewed the patch you committed to cvs, there is still a little bug in cvs. In my previous patch, I totally ignored the axdebug extenstion, because I can not find activdbg.h header in vista sdk.

I found the activdbg.h header exists in the lastest platform sdk, which is build for Windows Server 2003 SP1. So, here comes completed patch for amd64 ;-)

PS. I have to remove the depend of dsound.h, because setup.py just can not find it. and, I also upload a patch for distutils. this patched version can handle the manifest file.

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

>Comment By: Mark Hammond (mhammond)
Date: 2009-02-07 15:30

Message:
Thanks - I've checked in a slightly modified version of this.

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

Comment By: Mark Hammond (mhammond)
Date: 2009-02-07 15:29

Message:
Thanks - I've checked in a slightly modified version of this.

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

Comment By: Steve Yin (steveyin)
Date: 2007-05-30 11:52

Message:
Logged In: YES 
user_id=1613955
Originator: YES

OK, as I said before, in latest activdbg.h, IEnumDebugStackFrames is a
define to IEnumDebugStackFrames64 under x64 and defined to
IEnumDebugStackFrames32 under win32, so I made these change.

and, in latest activdbg.h dwSourceContext is DWORDLONG under x64, and
DWORD under win32. this is a pointer value, x64 use 8 bytes (dwordlong) as
a pointer, win32 use 4 bytes (dword) that is the difference.

in PyWinTypes.h, I have to remove these functions, because it will cause
the link fail, it says PyWinObject_AsWCHAR already as a body. and the
wchar_t is default on in vc8, default off before vc8(vc7.x, vc6).

I'm confused about win32net.h and win32netmodule.cpp, in Visual Studio
IDE, the last parameter  of PFNSIMPLEENUM and PFNNAMEDENUM need to be
PDWORD_PTR, but, if i'm using setup.py, it need to be changed back to
LPDWORD, you can see, LPDWORD is a pointer , PDWORD_PTR is a pointer too. I
really confused about these two types :-( . I'm not sure about the patch of
these two file, you can just delete these from the patch.

I also need to say, the patch to distutil is only needed under vc8, I
added /Zc:wchar_t- to disable default wchar_t, I don't know this has been
changed in python 2.6, and /D_CRT_SECURE_NO_WARNINGS to disable a looot of
stupid warning of vc8, and the manifest file merge.

I also uploaded the latest activdbg.h, this file has a modification date
of 2006-3-3, just a half year before these active script header in updated
vista sdk. you can see the IEnumDebugStackFrames is a define. ;-)
File Added: activdbg.rar

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

Comment By: Mark Hammond (mhammond)
Date: 2007-05-29 23:20

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

Thanks for the update.  MSDN documents the dwSourceContext params as
DWORD_PTR (rather than DWORDLONG).  So we need to change both the
"interface" and "gateway" side of this to use
PyWinObject_As[/From]DWORD_PTR to handle this param (so it works as well as
compiles ;)  That should also make it possible to remove the #ifdef's.

The change involving IEnumDebugStackFrames64 will also be a problem -
nothing in pywin32 will implement that, so it will fail at runtime.

You included a patch to PyWinTypes.h and win32\* which reverse previous
changes I made.  Was this intentional?  If so, what was the problem you
faced?

If we can sort these out, I'd be happy to apply it!

Thanks - I'll check out the distutils patch tomorrow or the next day...

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

Comment By: Steve Yin (steveyin)
Date: 2007-05-29 20:16

Message:
Logged In: YES 
user_id=1613955
Originator: YES

here comes the patch for distutils.

there are some of bugs in pythonwin, maybe it's amd64 related, but I don't
have time to debug it. Sorry.
File Added: distutils-vc8.patch

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

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

[pywin32-bugs] [ pywin32-Patches-1727357 ] new VC8.0 build patch for AMD64 branch (inc axdebug)

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

Patches item #1727357, was opened at 2007-05-29 20:13
Message generated for change (Settings changed) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1727357&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Steve Yin (steveyin)
Assigned to: Nobody/Anonymous (nobody)
Summary: new VC8.0 build patch for AMD64 branch (inc axdebug)

Initial Comment:
hi mhammond, I have reviewed the patch you committed to cvs, there is still a little bug in cvs. In my previous patch, I totally ignored the axdebug extenstion, because I can not find activdbg.h header in vista sdk.

I found the activdbg.h header exists in the lastest platform sdk, which is build for Windows Server 2003 SP1. So, here comes completed patch for amd64 ;-)

PS. I have to remove the depend of dsound.h, because setup.py just can not find it. and, I also upload a patch for distutils. this patched version can handle the manifest file.

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

>Comment By: Mark Hammond (mhammond)
Date: 2009-02-07 15:29

Message:
Thanks - I've checked in a slightly modified version of this.

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

Comment By: Steve Yin (steveyin)
Date: 2007-05-30 11:52

Message:
Logged In: YES 
user_id=1613955
Originator: YES

OK, as I said before, in latest activdbg.h, IEnumDebugStackFrames is a
define to IEnumDebugStackFrames64 under x64 and defined to
IEnumDebugStackFrames32 under win32, so I made these change.

and, in latest activdbg.h dwSourceContext is DWORDLONG under x64, and
DWORD under win32. this is a pointer value, x64 use 8 bytes (dwordlong) as
a pointer, win32 use 4 bytes (dword) that is the difference.

in PyWinTypes.h, I have to remove these functions, because it will cause
the link fail, it says PyWinObject_AsWCHAR already as a body. and the
wchar_t is default on in vc8, default off before vc8(vc7.x, vc6).

I'm confused about win32net.h and win32netmodule.cpp, in Visual Studio
IDE, the last parameter  of PFNSIMPLEENUM and PFNNAMEDENUM need to be
PDWORD_PTR, but, if i'm using setup.py, it need to be changed back to
LPDWORD, you can see, LPDWORD is a pointer , PDWORD_PTR is a pointer too. I
really confused about these two types :-( . I'm not sure about the patch of
these two file, you can just delete these from the patch.

I also need to say, the patch to distutil is only needed under vc8, I
added /Zc:wchar_t- to disable default wchar_t, I don't know this has been
changed in python 2.6, and /D_CRT_SECURE_NO_WARNINGS to disable a looot of
stupid warning of vc8, and the manifest file merge.

I also uploaded the latest activdbg.h, this file has a modification date
of 2006-3-3, just a half year before these active script header in updated
vista sdk. you can see the IEnumDebugStackFrames is a define. ;-)
File Added: activdbg.rar

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

Comment By: Mark Hammond (mhammond)
Date: 2007-05-29 23:20

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

Thanks for the update.  MSDN documents the dwSourceContext params as
DWORD_PTR (rather than DWORDLONG).  So we need to change both the
"interface" and "gateway" side of this to use
PyWinObject_As[/From]DWORD_PTR to handle this param (so it works as well as
compiles ;)  That should also make it possible to remove the #ifdef's.

The change involving IEnumDebugStackFrames64 will also be a problem -
nothing in pywin32 will implement that, so it will fail at runtime.

You included a patch to PyWinTypes.h and win32\* which reverse previous
changes I made.  Was this intentional?  If so, what was the problem you
faced?

If we can sort these out, I'd be happy to apply it!

Thanks - I'll check out the distutils patch tomorrow or the next day...

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

Comment By: Steve Yin (steveyin)
Date: 2007-05-29 20:16

Message:
Logged In: YES 
user_id=1613955
Originator: YES

here comes the patch for distutils.

there are some of bugs in pythonwin, maybe it's amd64 related, but I don't
have time to debug it. Sorry.
File Added: distutils-vc8.patch

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

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