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

[pywin32-bugs] [ pywin32-Bugs-1744647 ] Problem in odbc.pyd

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

Bugs item #1744647, was opened at 2007-06-28 03:09
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1744647&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: v_satish (v_satish)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem in odbc.pyd

Initial Comment:
hi,

I was trying to use the odbc.pyd provinded in the win32 , but faces with a interesting problem, when ever the sql server goes down or the lan connection between my python program to the SQL server goes down, my python program seems to crash. While troubleshooting the odbc code, i came across the usage of SQLFreeStmt function. This function seems to be removed after odbc V3.0 (http://msdn2.microsoft.com/en-us/library/ms131681.aspx). And this is the same statements that is causing the pyd file to crash too. How can i get around this problem???

regards
Satish

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

>Comment By: Roger Upole (rupole)
Date: 2007-06-29 11:40

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

Rev 1.20 of odbc.cpp should fix this.


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

Comment By: Roger Upole (rupole)
Date: 2007-06-28 13:31

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

SQLFreeStmt should probably be replaced, but the main problem is
with the reconnect logic.  In attemptReconnect, cur->hstmt is freed
unconditionally using this function but the value is never reset.
A second attempt to reconnect will crash since the handle is already
invalidated.  One solution would be to set the hstmt to NULL when it's
freed, and check for NULL before using it or trying to free it again.

As a workaround in Python code, you might be able to just create a
new cursor when you get disconnected.  However, it might still crash
when deallocating the original cursor since the cursor destructor
will also call SQLFreeStmt with the invalid handle.


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

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

[pywin32-bugs] [ pywin32-Bugs-1744647 ] Problem in odbc.pyd

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

Bugs item #1744647, was opened at 2007-06-28 03:09
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1744647&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: v_satish (v_satish)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem in odbc.pyd

Initial Comment:
hi,

I was trying to use the odbc.pyd provinded in the win32 , but faces with a interesting problem, when ever the sql server goes down or the lan connection between my python program to the SQL server goes down, my python program seems to crash. While troubleshooting the odbc code, i came across the usage of SQLFreeStmt function. This function seems to be removed after odbc V3.0 (http://msdn2.microsoft.com/en-us/library/ms131681.aspx). And this is the same statements that is causing the pyd file to crash too. How can i get around this problem???

regards
Satish

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

>Comment By: Roger Upole (rupole)
Date: 2007-06-28 13:31

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

SQLFreeStmt should probably be replaced, but the main problem is
with the reconnect logic.  In attemptReconnect, cur->hstmt is freed
unconditionally using this function but the value is never reset.
A second attempt to reconnect will crash since the handle is already
invalidated.  One solution would be to set the hstmt to NULL when it's
freed, and check for NULL before using it or trying to free it again.

As a workaround in Python code, you might be able to just create a
new cursor when you get disconnected.  However, it might still crash
when deallocating the original cursor since the cursor destructor
will also call SQLFreeStmt with the invalid handle.


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

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

[pywin32-bugs] [ pywin32-Bugs-1744647 ] Problem in odbc.pyd

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

Bugs item #1744647, was opened at 2007-06-28 13:39
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=1744647&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: v_satish (v_satish)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem in odbc.pyd

Initial Comment:
hi,

I was trying to use the odbc.pyd provinded in the win32 , but faces with a interesting problem, when ever the sql server goes down or the lan connection between my python program to the SQL server goes down, my python program seems to crash. While troubleshooting the odbc code, i came across the usage of SQLFreeStmt function. This function seems to be removed after odbc V3.0 (http://msdn2.microsoft.com/en-us/library/ms131681.aspx). And this is the same statements that is causing the pyd file to crash too. How can i get around this problem???

regards
Satish

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

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

[pywin32-bugs] [ pywin32-Bugs-1732395 ] Vista install errors for pywin32-210

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

Bugs item #1732395, was opened at 2007-06-06 23:36
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=1732395&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: Olivier Mengué (dolmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Vista install errors for pywin32-210

Initial Comment:
It appers that the setup (pywin32-210.win32-py2.5.exe) does not ask for administrative right to install and fails to do some registry modifications.

Here is the log at the end of the install:

Copied pythoncom25.dll to C:\Outils\Python\pythoncom25.dll
Copied pywintypes25.dll to C:\Outils\Python\pywintypes25.dll
You do not have the permissions to install COM objects.
The sample COM objects were not registered.
-> Software\Python\PythonCore\2.5\Help[None]=None
-> Software\Python\PythonCore\2.5\Help\Pythonwin Reference[None]='C:\\Outils\\Python\\Lib\\site-packages\\PyWin32.chm'
Creating directory C:\Outils\Python\Lib\site-packages\win32com\gen_py
Shortcut for Pythonwin created
Shortcut to documentation created
The pywin32 extensions were successfully installed.



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

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

[pywin32-bugs] [ pywin32-Bugs-1731778 ] win32pipe.popen functions can crash

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

Bugs item #1731778, was opened at 2007-06-05 20: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=1731778&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: 1
Private: No
Submitted By: Roger Upole (rupole)
Assigned to: Roger Upole (rupole)
Summary: win32pipe.popen functions can crash

Initial Comment:
The popen functions don't check the result of _fdopen,
resulting in a crash after the limit of open CRT
stdio streams is reached.
This limit is 512 by default, but can be raised to 2048 using _setmaxstdio.

Setting to low priority since the built-in python popen functions or subprocess module are usually used in preference to win32pipe.popen* functions.

Python itself also has this same issue, see bug #886488:
http://sourceforge.net/tracker/index.php?func=detail&aid=886488&group_id=5470&atid=105470


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

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

[pywin32-bugs] [ pywin32-Bugs-1731295 ] _GetServiceShortName doesn't work with non-ascii characters

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

Bugs item #1731295, was opened at 2007-06-05 16:25
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=1731295&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: Shailesh Kumar (shailesh1729)
Assigned to: Nobody/Anonymous (nobody)
Summary: _GetServiceShortName doesn't work with non-ascii characters

Initial Comment:
This problem came up when running on a Japanese computer. 

I was calling QueryServiceStatus for a non-existent
service. 

My code ran like: 
def serviceExists(serviceName):
    exists = True
    try:
        status = win32serviceutil.QueryServiceStatus(serviceName)
    except win32api.error, (rc, fnerr, msg):
        exists = False
    if exists:
        logging.info('%s  service exists.' % serviceName)
    else:
        logging.info("%s service doesn't exist" % serviceName)
    return exists

On english computers, this worked fine.
On a Japanese computer, it led to following exception.


  File "C:\Python24\Lib\site-packages\win32\lib\win32serviceutil.py", line 479, in QueryServiceStatus
    hs = SmartOpenService(hscm, serviceName, win32service.SERVICE_QUERY_STATUS)
  File "C:\Python24\Lib\site-packages\win32\lib\win32serviceutil.py", line 81, in SmartOpenService
    name = _GetServiceShortName(name)
  File "C:\Python24\Lib\site-packages\win32\lib\win32serviceutil.py", line 66, in _GetServiceShortName
    if thisName.lower() == longName:
UnicodeDecodeError: 'ascii' codec can't decode byte 0x83 in position 4: ordinal not in range(128)





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

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

[pywin32-bugs] [ pywin32-Patches-1578151 ] Patch for Testing Parameter Problem

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

Patches item #1578151, was opened at 2006-10-16 23:25
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1578151&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: bkssmith (bkssmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for Testing Parameter Problem

Initial Comment:
As requested by Mark, I have attached patches that 
demonstrate a problem I am having with parameter 
handling when using a Python COM Object from Visual 
Basic after creating a type library for the object.

Here are the two problems I am having, as originally 
reported on the pywin32 mailing list.

1) When using the COM server without the type 
library, I was returning a tuple with the return 
value of the function (in my case, an error code) as 
the first element.  With the type library, this value 
must be the last element.  It is my understanding 
that the return value for the function should be 
returned first, not last.

2) VBA was giving me an error like "Expecting 3 
return values, got: 2" whenever a function contained 
an [in, out] parameter.  It looks like the extra 
parameter it is looking for is the HRESULT signifying 
the success of the call itself, because if I insert a 
0 at the beginning of my returned tuple the problem 
goes away but any other value causes an error saying 
the method call failed.

I was originally testing my own object using VBA in 
Excel 2000.  Mark requested the patches to the pippo 
sample included with pywin32.  The patch adds two 
methods with the same signature.  The difference is 
that the Python implementation of Method2() returns 
two values (as the IDL signature would suggest) and 
Method3() returns 3 values, with a 0 as the first 
value.  My VBA test code (also attached) calls Method3
() first and correctly sets inout1 to -31 and the 
return value to -41.  Note that this occurs even 
though the function return value is the *last* return 
value.  The call to Method2() fails with 
the "Expecting 3 return values, got: 2" error.

I have also tried using Visual Basic 2005 Express 
Edition and the behaviour is similar: the call to 
Method3() succeeds and the call to Method2() fails, 
although now the error is "Error HRESULT E_FAIL has 
been returned from a call to a COM component".

My platform is Win XP Pro (SP2), Python 2.3.4, pywin 
Build 210.



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

>Comment By: Mark Hammond (mhammond)
Date: 2007-06-03 23:27

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

Re point (1) - that is just the nature of the beast when you don't have a
typelib - python guesses best it can.  I can't explain your other points
though.  I got as far as checking in your Method2, and a test that Python
calls it correctly.  I didn't get to adding the VB test though, but
hopefully I will sooner rather than later...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1578151&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 18:13
Message generated for change (Comment added) made by steveyin
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: Open
Resolution: None
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: Steve Yin (steveyin)
Date: 2007-05-30 09: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 21: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 18: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 (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: Open
Resolution: None
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: 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 18:13
Message generated for change (Comment added) made by steveyin
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: Open
Resolution: None
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: Steve Yin (steveyin)
Date: 2007-05-29 18: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 18:13
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=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: Open
Resolution: None
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.

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

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

[pywin32-bugs] [ pywin32-Patches-1623093 ] Pychecker Plug-In for PythonWin: mdi_pychecker

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

Patches item #1623093, was opened at 2006-12-28 05:53
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1623093&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: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pychecker Plug-In for PythonWin: mdi_pychecker

Initial Comment:
This Pychecker plug-in module for PythonWin enables to use Pychecker easily in PythonWin (usage similar to the existing Grep-Tool (Ctrl-N,P) - but it can run in background due to the time consuming Pychecker task).

It also supports easily the #$pycheck_no option of #1623076 
http://sourceforge.net/tracker/index.php?func=detail&aid=1623076&group_id=24686&atid=382219

One can jump to Pychecker warning source lines by DoubleClick and auto-add #$pycheck_no / #$pycheck_no=specific-re-pattern tags to source lines by context/right-mouse-clicking on warning lines.

Further docs in the head of mdi_pychecker.py


Robert


PS: Also contained is a patch for sgrepmdi to pre-init the "Directories" to the directory of the current file.


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

>Comment By: Mark Hammond (mhammond)
Date: 2007-05-24 23:49

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

Works for me (once I remove the .bat file).  Thanks!

Checking in intpyapp.py;
new revision: 1.10; previous revision: 1.9
/cvsroot/pywin32/pywin32/Pythonwin/pywin/framework/mdi_pychecker.py,v  <--
 mdi_pychecker.py
initial revision: 1.1
Checking in sgrepmdi.py;
new revision: 1.5; previous revision: 1.4


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

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

[pywin32-bugs] [ pywin32-Patches-1707700 ] Iterator is missing automatic cast

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

Patches item #1707700, was opened at 2007-04-26 06:54
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1707700&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: Stefan Schukat (sschukat)
Assigned to: Nobody/Anonymous (nobody)
Summary: Iterator is missing automatic cast

Initial Comment:
If a COM collection defines a specific interface which is collected this interface should normally be returned via the Item and __getitem__ method. For this purpose the resultCLSID parameter is filled in the Invoke calls. This parameter is missing in the iterator generation. The attached files show the change in the generation and usage to support casting of interfaces while using an iterator.

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

>Comment By: Mark Hammond (mhammond)
Date: 2007-05-24 23:00

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

Thanks!

Checking in genpy.py;
new revision: 1.52; previous revision: 1.51
Checking in util.py;
new revision: 1.3; previous revision: 1.2

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

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

[pywin32-bugs] [ pywin32-Patches-1705634 ] VC8.0 build patch for AMD64 branch

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

Patches item #1705634, was opened at 2007-04-23 17:58
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1705634&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: Sidnei da Silva (dreamcatcher)
Summary: VC8.0 build patch for AMD64 branch

Initial Comment:
Well, I managed to build amd64 branch with vs8.0.

why vs8? it's better for amd64 build. of course, I also used vista updated sdk as platform sdk.

also, something need to be done with Python25\Lib\distutils\msvccompiler.py, so this built can be build.

here is the patch. 

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

>Comment By: Mark Hammond (mhammond)
Date: 2007-05-24 22:51

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

Thanks very much for these changes.  I think you will find them all
applied on the trunk (note the branch will soon go away).  Please let me
know if you have any problems.

Also FWIW, we are chatting about the distutils changes on distutils-sig
and python-list - the idea currently is that we will just copy the files
from the PCBuild8 dir back into PCBuild via the .bat files in PCBuild8. 
This should avoid any changes to distutils (assuming you use the hack that
I've mentioned in setup.py's docstring)  I'd love to hear how you go and
what you think of these proposed changes.

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

Comment By: Steve Yin (steveyin)
Date: 2007-04-27 18:04

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

no, I don't have vista, just vista sdk. because vista sdk can be used on
XP. supportted platform, right :)

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

Comment By: Sidnei da Silva (dreamcatcher)
Date: 2007-04-26 04:51

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

The branch was building last I tried, haven't touched it since. We
certainly need to merge the changes done on trunk.

Steve: Are you building on Vista, or just using the new Platform SDK?

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

Comment By: Mark Hammond (mhammond)
Date: 2007-04-24 14:29

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

sidnei - what is the status of your branch?

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

Comment By: Mark Hammond (mhammond)
Date: 2007-04-24 14:23

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

that's great - thanks!  I'm actually getting a x64 box within the week, so
I might hang off until then to apply it.

It's worth noting that the trunk has also had some generic amd64 work
done, and that might get close to building too.  I'm afraid I haven't been
paying much attention to the 64bit world.

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

Comment By: Steve Yin (steveyin)
Date: 2007-04-24 13:51

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

you said I comment out some function, the function I only commented out is
ado support, you know, there is no ado under x64, also, there is no naked
keyword under x64.

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

Comment By: Steve Yin (steveyin)
Date: 2007-04-24 13:47

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

well, here we are. the updated patch.

Note: I can not build axdebug extension. because I don't know where to
find the corresponding activdbg.h file to vista sdk. But, I DID found these
IID_ in uuid.lib under Lib\x64. but just no header.

I have little knowledge about ATL & COM under windows.
File Added: vc8-build.patch

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

Comment By: Mark Hammond (mhammond)
Date: 2007-04-24 09:59

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

I'm afraid this patch still needs work - in some cases you have simply
removed functionality which works today.  While that might be acceptable
for 64bit builds, its not acceptable for future 32 bit builds.  Any chance
you can make all the relevant changes conditional?

Thanks

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

Comment By: Steve Yin (steveyin)
Date: 2007-04-23 17:59

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

this patch built on today's cvs revision.

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

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

[pywin32-bugs] [ pywin32-Feature Requests-1720294 ] Egg distribution

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

Feature Requests item #1720294, was opened at 2007-05-16 20:29
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=1720294&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: Jim Fulton (dcjim)
Assigned to: Nobody/Anonymous (nobody)
Summary: Egg distribution

Initial Comment:
Can we get an egg distribution?


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

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

[pywin32-bugs] [ pywin32-Bugs-1709340 ] ByRef 2D arrays of 1 Byte improperly handled

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

Bugs item #1709340, was opened at 2007-04-29 04:26
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1709340&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: wyrock (wyrock)
Assigned to: Mark Hammond (mhammond)
Summary: ByRef 2D arrays of 1 Byte improperly handled

Initial Comment:
If a COM module passes a 2D array where one each dimension is only one byte, then win32com only returns a buffer. The buffer prevents access from the other dimension of the array. It is expected to get an array of buffers.

The bug lies in oleargs.cpp. I've attached an updated version of oleargs.cpp and also some modified versions of the com_testing code to show the problem.

Could someone please review the proposed fix and commit the change?

Thanks,


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

>Comment By: Mark Hammond (mhammond)
Date: 2007-05-16 08:31

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

Thanks - I'll look at this when I get time.  You can build an executable
by running:

  setup.py bdist_wininst

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

Comment By: wyrock (wyrock)
Date: 2007-05-15 23:00

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

Now that I've built the source with the fix. I know i can do setup.py -q
install, but is there an existing script for making the win32 .exe that
gets distributed?

Also, the diff is fairly short, so I'll just post directly here:

? diff.out
? com/TestSources/PyCOMTest/PyCOMTest.plg
? com/win32com/src/oleargs.orig.cpp
? win32/src/_winxpthememodule.backup.cpp
Index: com/TestSources/PyCOMTest/PyCOMImpl.cpp
===================================================================
RCS file:
/cvsroot/pywin32/pywin32/com/TestSources/PyCOMTest/PyCOMImpl.cpp,v
retrieving revision 1.15
diff -r1.15 PyCOMImpl.cpp
312a313,347
> STDMETHODIMP CPyCOMTest::GetComplexVariantByRef(VARIANT *out)
> {
> 	VariantClear(out); // necessary?
> 	// Creating a safe array with two dimensions to make sure
> 	// an array of buffers can be returned
> 	SAFEARRAYBOUND sabBound[2]={ {5,0}, {8,0}};
> 	SAFEARRAY *psaDataBuffer = SafeArrayCreate(VT_UI1,2,sabBound);
> 	VariantInit(out);
> 	out->vt = VT_ARRAY | VT_UI1;
> 	out->parray = psaDataBuffer;
> 	long indicies[2] = {0,0};
> 	for(int i=0;i<5;i++){
> 		indicies[0]=i;
> 		for(int j=0;j<8;j++){
> 			indicies[1] = j;
> 			SafeArrayPutElement(psaDataBuffer,indicies,&j);
> 
> 		}
> 	}
> 	return S_OK;
> }
> 
> 
> STDMETHODIMP CPyCOMTest::SetComplexVariantByRef(VARIANT *v)
> {
> 
> 	if( v->parray->cDims == 2 && v->parray->rgsabound[1].cElements==5 &&
> 		v->parray->rgsabound[0].cElements==8){
> 		return S_OK;
> 	}
> 	return -1;
> }
> 
> 
> 
Index: com/TestSources/PyCOMTest/PyCOMImpl.h
===================================================================
RCS file:
/cvsroot/pywin32/pywin32/com/TestSources/PyCOMTest/PyCOMImpl.h,v
retrieving revision 1.14
diff -r1.14 PyCOMImpl.h
81a82,84
> 	STDMETHOD(GetComplexVariantByRef)(VARIANT *out);
> 	STDMETHOD(SetComplexVariantByRef)(VARIANT *v);
> 
Index: com/TestSources/PyCOMTest/PyCOMTest.dsp
===================================================================
RCS file:
/cvsroot/pywin32/pywin32/com/TestSources/PyCOMTest/PyCOMTest.idl,v
retrieving revision 1.15
diff -r1.15 PyCOMTest.idl
198a199,200
> 		HRESULT GetComplexVariantByRef([out, retval] VARIANT *vout);
> 		HRESULT SetComplexVariantByRef([out] VARIANT *v);
Index: com/win32com/src/oleargs.cpp
===================================================================
RCS file: /cvsroot/pywin32/pywin32/com/win32com/src/oleargs.cpp,v
retrieving revision 1.37
diff -r1.37 oleargs.cpp
398c398
< 	if (dimNo==nDims && vt==VT_UI1 && obj->ob_type->tp_as_buffer) {
---
> 	if (dimNo==nDims && obj->ob_type->tp_as_buffer) {
831c831
< 	if (vt==VT_UI1) {
---
> 	if (vt==VT_UI1 && dimNo==nDims) {

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

Comment By: wyrock (wyrock)
Date: 2007-05-12 22:14

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

File Added: test2dByRef.py

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

Comment By: wyrock (wyrock)
Date: 2007-05-12 22:13

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

Attaching the cvs diff with the fix (in oleargs.cpp) and some
modifications to the test bench that test for the issue.
File Added: diff.out

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

Comment By: Mark Hammond (mhammond)
Date: 2007-05-06 21:00

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

Thanks!  I haven't looked yet, but I can believe what you say is true. 
I'll (try to) get to this before the next release (but a .diff against the
test suite instead of the .zip with a complete copy would help even more!) 
If you have the c compiler handy, then 'setup.py install' from CVS is quite
an easy way to get a build from sources (but I digress... :)

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

Comment By: wyrock (wyrock)
Date: 2007-05-06 08:10

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

File Added: oleargs.new.cpp

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

Comment By: wyrock (wyrock)
Date: 2007-04-29 04:35

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

File Added: testSmaller.py

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

Comment By: wyrock (wyrock)
Date: 2007-04-29 04:34

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

File Added: com_testing2.zip

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

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

[pywin32-bugs] [ pywin32-Bugs-1709340 ] ByRef 2D arrays of 1 Byte improperly handled

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

Bugs item #1709340, was opened at 2007-04-28 13:26
Message generated for change (Comment added) made by wyrock
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1709340&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: wyrock (wyrock)
Assigned to: Mark Hammond (mhammond)
Summary: ByRef 2D arrays of 1 Byte improperly handled

Initial Comment:
If a COM module passes a 2D array where one each dimension is only one byte, then win32com only returns a buffer. The buffer prevents access from the other dimension of the array. It is expected to get an array of buffers.

The bug lies in oleargs.cpp. I've attached an updated version of oleargs.cpp and also some modified versions of the com_testing code to show the problem.

Could someone please review the proposed fix and commit the change?

Thanks,


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

>Comment By: wyrock (wyrock)
Date: 2007-05-15 08:00

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

Now that I've built the source with the fix. I know i can do setup.py -q
install, but is there an existing script for making the win32 .exe that
gets distributed?

Also, the diff is fairly short, so I'll just post directly here:

? diff.out
? com/TestSources/PyCOMTest/PyCOMTest.plg
? com/win32com/src/oleargs.orig.cpp
? win32/src/_winxpthememodule.backup.cpp
Index: com/TestSources/PyCOMTest/PyCOMImpl.cpp
===================================================================
RCS file:
/cvsroot/pywin32/pywin32/com/TestSources/PyCOMTest/PyCOMImpl.cpp,v
retrieving revision 1.15
diff -r1.15 PyCOMImpl.cpp
312a313,347
> STDMETHODIMP CPyCOMTest::GetComplexVariantByRef(VARIANT *out)
> {
> 	VariantClear(out); // necessary?
> 	// Creating a safe array with two dimensions to make sure
> 	// an array of buffers can be returned
> 	SAFEARRAYBOUND sabBound[2]={ {5,0}, {8,0}};
> 	SAFEARRAY *psaDataBuffer = SafeArrayCreate(VT_UI1,2,sabBound);
> 	VariantInit(out);
> 	out->vt = VT_ARRAY | VT_UI1;
> 	out->parray = psaDataBuffer;
> 	long indicies[2] = {0,0};
> 	for(int i=0;i<5;i++){
> 		indicies[0]=i;
> 		for(int j=0;j<8;j++){
> 			indicies[1] = j;
> 			SafeArrayPutElement(psaDataBuffer,indicies,&j);
> 
> 		}
> 	}
> 	return S_OK;
> }
> 
> 
> STDMETHODIMP CPyCOMTest::SetComplexVariantByRef(VARIANT *v)
> {
> 
> 	if( v->parray->cDims == 2 && v->parray->rgsabound[1].cElements==5 &&
> 		v->parray->rgsabound[0].cElements==8){
> 		return S_OK;
> 	}
> 	return -1;
> }
> 
> 
> 
Index: com/TestSources/PyCOMTest/PyCOMImpl.h
===================================================================
RCS file:
/cvsroot/pywin32/pywin32/com/TestSources/PyCOMTest/PyCOMImpl.h,v
retrieving revision 1.14
diff -r1.14 PyCOMImpl.h
81a82,84
> 	STDMETHOD(GetComplexVariantByRef)(VARIANT *out);
> 	STDMETHOD(SetComplexVariantByRef)(VARIANT *v);
> 
Index: com/TestSources/PyCOMTest/PyCOMTest.dsp
===================================================================
RCS file:
/cvsroot/pywin32/pywin32/com/TestSources/PyCOMTest/PyCOMTest.idl,v
retrieving revision 1.15
diff -r1.15 PyCOMTest.idl
198a199,200
> 		HRESULT GetComplexVariantByRef([out, retval] VARIANT *vout);
> 		HRESULT SetComplexVariantByRef([out] VARIANT *v);
Index: com/win32com/src/oleargs.cpp
===================================================================
RCS file: /cvsroot/pywin32/pywin32/com/win32com/src/oleargs.cpp,v
retrieving revision 1.37
diff -r1.37 oleargs.cpp
398c398
< 	if (dimNo==nDims && vt==VT_UI1 && obj->ob_type->tp_as_buffer) {
---
> 	if (dimNo==nDims && obj->ob_type->tp_as_buffer) {
831c831
< 	if (vt==VT_UI1) {
---
> 	if (vt==VT_UI1 && dimNo==nDims) {

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

Comment By: wyrock (wyrock)
Date: 2007-05-12 07:14

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

File Added: test2dByRef.py

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

Comment By: wyrock (wyrock)
Date: 2007-05-12 07:13

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

Attaching the cvs diff with the fix (in oleargs.cpp) and some
modifications to the test bench that test for the issue.
File Added: diff.out

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

Comment By: Mark Hammond (mhammond)
Date: 2007-05-06 06:00

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

Thanks!  I haven't looked yet, but I can believe what you say is true. 
I'll (try to) get to this before the next release (but a .diff against the
test suite instead of the .zip with a complete copy would help even more!) 
If you have the c compiler handy, then 'setup.py install' from CVS is quite
an easy way to get a build from sources (but I digress... :)

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

Comment By: wyrock (wyrock)
Date: 2007-05-05 17:10

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

File Added: oleargs.new.cpp

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

Comment By: wyrock (wyrock)
Date: 2007-04-28 13:35

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

File Added: testSmaller.py

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

Comment By: wyrock (wyrock)
Date: 2007-04-28 13:34

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

File Added: com_testing2.zip

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

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

[pywin32-bugs] [ pywin32-Bugs-1709340 ] ByRef 2D arrays of 1 Byte improperly handled

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

Bugs item #1709340, was opened at 2007-04-28 13:26
Message generated for change (Comment added) made by wyrock
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1709340&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: wyrock (wyrock)
Assigned to: Mark Hammond (mhammond)
Summary: ByRef 2D arrays of 1 Byte improperly handled

Initial Comment:
If a COM module passes a 2D array where one each dimension is only one byte, then win32com only returns a buffer. The buffer prevents access from the other dimension of the array. It is expected to get an array of buffers.

The bug lies in oleargs.cpp. I've attached an updated version of oleargs.cpp and also some modified versions of the com_testing code to show the problem.

Could someone please review the proposed fix and commit the change?

Thanks,


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

>Comment By: wyrock (wyrock)
Date: 2007-05-12 07:14

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

File Added: test2dByRef.py

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

Comment By: wyrock (wyrock)
Date: 2007-05-12 07:13

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

Attaching the cvs diff with the fix (in oleargs.cpp) and some
modifications to the test bench that test for the issue.
File Added: diff.out

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

Comment By: Mark Hammond (mhammond)
Date: 2007-05-06 06:00

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

Thanks!  I haven't looked yet, but I can believe what you say is true. 
I'll (try to) get to this before the next release (but a .diff against the
test suite instead of the .zip with a complete copy would help even more!) 
If you have the c compiler handy, then 'setup.py install' from CVS is quite
an easy way to get a build from sources (but I digress... :)

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

Comment By: wyrock (wyrock)
Date: 2007-05-05 17:10

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

File Added: oleargs.new.cpp

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

Comment By: wyrock (wyrock)
Date: 2007-04-28 13:35

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

File Added: testSmaller.py

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

Comment By: wyrock (wyrock)
Date: 2007-04-28 13:34

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

File Added: com_testing2.zip

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

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

[pywin32-bugs] [ pywin32-Bugs-1709340 ] ByRef 2D arrays of 1 Byte improperly handled

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

Bugs item #1709340, was opened at 2007-04-28 13:26
Message generated for change (Comment added) made by wyrock
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1709340&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: wyrock (wyrock)
Assigned to: Mark Hammond (mhammond)
Summary: ByRef 2D arrays of 1 Byte improperly handled

Initial Comment:
If a COM module passes a 2D array where one each dimension is only one byte, then win32com only returns a buffer. The buffer prevents access from the other dimension of the array. It is expected to get an array of buffers.

The bug lies in oleargs.cpp. I've attached an updated version of oleargs.cpp and also some modified versions of the com_testing code to show the problem.

Could someone please review the proposed fix and commit the change?

Thanks,


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

>Comment By: wyrock (wyrock)
Date: 2007-05-12 07:13

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

Attaching the cvs diff with the fix (in oleargs.cpp) and some
modifications to the test bench that test for the issue.
File Added: diff.out

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

Comment By: Mark Hammond (mhammond)
Date: 2007-05-06 06:00

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

Thanks!  I haven't looked yet, but I can believe what you say is true. 
I'll (try to) get to this before the next release (but a .diff against the
test suite instead of the .zip with a complete copy would help even more!) 
If you have the c compiler handy, then 'setup.py install' from CVS is quite
an easy way to get a build from sources (but I digress... :)

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

Comment By: wyrock (wyrock)
Date: 2007-05-05 17:10

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

File Added: oleargs.new.cpp

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

Comment By: wyrock (wyrock)
Date: 2007-04-28 13:35

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

File Added: testSmaller.py

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

Comment By: wyrock (wyrock)
Date: 2007-04-28 13:34

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

File Added: com_testing2.zip

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

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

[pywin32-bugs] [ pywin32-Bugs-1016558 ] 202 Windows Installer requires MSVCR71.dll

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

Bugs item #1016558, was opened at 2004-08-26 03:01
Message generated for change (Comment added) made by gawarecki
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1016558&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: Will Watts (willw)
Assigned to: Nobody/Anonymous (nobody)
Summary: 202 Windows Installer requires MSVCR71.dll

Initial Comment:
When I run the install, it fails at once with a modal
dialog:

pywin32-202.win32-py2.4.exe - Unable to Locate DLL

The dynamic link library MSVCR71.dll could not be found
in the specified path.... [path on my machine]

After that the install stops and no further progress is
possible.

OS is Win2k SP4.



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

Comment By: Gawarecki (gawarecki)
Date: 2007-05-08 17:12

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

Install of "pywin32-210.win32-py2.5.exe" and "pywin32-210.win32-py2.6.exe"
and get following error dialog:
    Title = pywin32-210.win32-py2.5.exe - Unable to Locate Component
    Content = This application has failed to start because MSVCR71.dll was
not found.  Re=installing the application may fix this problem.
    Buttons = OK


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

Comment By: Will Watts (willw)
Date: 2005-05-04 03:25

Message:
Logged In: YES 
user_id=70647

Re: Chris Mahan's comment: You've missed my point. I don't
(or rather didn't) have MSVCR71.dll to copy around to any
directory. 

It is a redistributable DLL that is part of Microsoft's
Visual C++ 7.1. It's not part of the OS - at least, not
Win2K. Therefore any program that depends on it should
supply it.

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

Comment By: Chris Mahan (chris_mahan)
Date: 2005-05-03 23:42

Message:
Logged In: YES 
user_id=102754

You can work around it by copying the dll to the directory 
where pywin installer is. Win XP here.

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

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

[pywin32-bugs] [ pywin32-Bugs-1709340 ] ByRef 2D arrays of 1 Byte improperly handled

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

Bugs item #1709340, was opened at 2007-04-29 04:26
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1709340&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: wyrock (wyrock)
>Assigned to: Mark Hammond (mhammond)
Summary: ByRef 2D arrays of 1 Byte improperly handled

Initial Comment:
If a COM module passes a 2D array where one each dimension is only one byte, then win32com only returns a buffer. The buffer prevents access from the other dimension of the array. It is expected to get an array of buffers.

The bug lies in oleargs.cpp. I've attached an updated version of oleargs.cpp and also some modified versions of the com_testing code to show the problem.

Could someone please review the proposed fix and commit the change?

Thanks,


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

>Comment By: Mark Hammond (mhammond)
Date: 2007-05-06 21:00

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

Thanks!  I haven't looked yet, but I can believe what you say is true. 
I'll (try to) get to this before the next release (but a .diff against the
test suite instead of the .zip with a complete copy would help even more!) 
If you have the c compiler handy, then 'setup.py install' from CVS is quite
an easy way to get a build from sources (but I digress... :)

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

Comment By: wyrock (wyrock)
Date: 2007-05-06 08:10

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

File Added: oleargs.new.cpp

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

Comment By: wyrock (wyrock)
Date: 2007-04-29 04:35

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

File Added: testSmaller.py

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

Comment By: wyrock (wyrock)
Date: 2007-04-29 04:34

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

File Added: com_testing2.zip

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

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

[pywin32-bugs] [ pywin32-Bugs-1709340 ] ByRef 2D arrays of 1 Byte improperly handled

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

Bugs item #1709340, was opened at 2007-04-28 13:26
Message generated for change (Comment added) made by wyrock
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1709340&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: wyrock (wyrock)
Assigned to: Nobody/Anonymous (nobody)
Summary: ByRef 2D arrays of 1 Byte improperly handled

Initial Comment:
If a COM module passes a 2D array where one each dimension is only one byte, then win32com only returns a buffer. The buffer prevents access from the other dimension of the array. It is expected to get an array of buffers.

The bug lies in oleargs.cpp. I've attached an updated version of oleargs.cpp and also some modified versions of the com_testing code to show the problem.

Could someone please review the proposed fix and commit the change?

Thanks,


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

>Comment By: wyrock (wyrock)
Date: 2007-05-05 17:10

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

File Added: oleargs.new.cpp

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

Comment By: wyrock (wyrock)
Date: 2007-04-28 13:35

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

File Added: testSmaller.py

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

Comment By: wyrock (wyrock)
Date: 2007-04-28 13:34

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

File Added: com_testing2.zip

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

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

[pywin32-bugs] [ pywin32-Bugs-1709340 ] ByRef 2D arrays of 1 Byte improperly handled

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

Bugs item #1709340, was opened at 2007-04-28 13:26
Message generated for change (Comment added) made by wyrock
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1709340&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: wyrock (wyrock)
Assigned to: Nobody/Anonymous (nobody)
Summary: ByRef 2D arrays of 1 Byte improperly handled

Initial Comment:
If a COM module passes a 2D array where one each dimension is only one byte, then win32com only returns a buffer. The buffer prevents access from the other dimension of the array. It is expected to get an array of buffers.

The bug lies in oleargs.cpp. I've attached an updated version of oleargs.cpp and also some modified versions of the com_testing code to show the problem.

Could someone please review the proposed fix and commit the change?

Thanks,


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

>Comment By: wyrock (wyrock)
Date: 2007-04-28 13:35

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

File Added: testSmaller.py

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

Comment By: wyrock (wyrock)
Date: 2007-04-28 13:34

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

File Added: com_testing2.zip

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

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

[pywin32-bugs] [ pywin32-Bugs-1709340 ] ByRef 2D arrays of 1 Byte improperly handled

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

Bugs item #1709340, was opened at 2007-04-28 13:26
Message generated for change (Comment added) made by wyrock
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1709340&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: wyrock (wyrock)
Assigned to: Nobody/Anonymous (nobody)
Summary: ByRef 2D arrays of 1 Byte improperly handled

Initial Comment:
If a COM module passes a 2D array where one each dimension is only one byte, then win32com only returns a buffer. The buffer prevents access from the other dimension of the array. It is expected to get an array of buffers.

The bug lies in oleargs.cpp. I've attached an updated version of oleargs.cpp and also some modified versions of the com_testing code to show the problem.

Could someone please review the proposed fix and commit the change?

Thanks,


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

>Comment By: wyrock (wyrock)
Date: 2007-04-28 13:34

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

File Added: com_testing2.zip

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

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

[pywin32-bugs] [ pywin32-Bugs-1709340 ] ByRef 2D arrays of 1 Byte improperly handled

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

Bugs item #1709340, was opened at 2007-04-28 13:26
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=1709340&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: wyrock (wyrock)
Assigned to: Nobody/Anonymous (nobody)
Summary: ByRef 2D arrays of 1 Byte improperly handled

Initial Comment:
If a COM module passes a 2D array where one each dimension is only one byte, then win32com only returns a buffer. The buffer prevents access from the other dimension of the array. It is expected to get an array of buffers.

The bug lies in oleargs.cpp. I've attached an updated version of oleargs.cpp and also some modified versions of the com_testing code to show the problem.

Could someone please review the proposed fix and commit the change?

Thanks,


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

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