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

[pywin32-bugs] [ pywin32-Bugs-1763285 ] win32 extensions cannot be used by non-admin user

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

Bugs item #1763285, was opened at 2007-07-29 22:54
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=1763285&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: delta (delta_c)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32 extensions cannot be used by non-admin user

Initial Comment:
pywin32-210.win32-py2.5.exe was installed on Windows XP after installing Python 2.5.

PythonWin shows only on admin startup menu.

win32com.client could not be imported by a non-admin user.  However, after being imported by admin, the non-admin user could do so.  The import had been done twice - once in IDLE and once in PythonWin.  Sorry, I don't know if either by itself would have worked.


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

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

[pywin32-bugs] [ pywin32-Bugs-1762768 ] 'import win32file' in Python 2.5.1 can't locate PYWINTYPES25

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

Bugs item #1762768, was opened at 2007-07-29 01:01
Message generated for change (Settings changed) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1762768&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: Works For Me
Priority: 5
Private: No
Submitted By: Sam Denton (samwyse)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'import win32file' in Python 2.5.1 can't locate PYWINTYPES25

Initial Comment:
Adding to Window's PATH fixes everything.

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\>c:\python25\python
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import win32file
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: DLL load failed: The specified module could not be found.
>>> import sys
>>> for d in sys.path: print d
...

c:\python25\lib\site-packages\setuptools-0.6c6-py2.5.egg
c:\python25\lib\site-packages\sqlalchemy-0.3.10-py2.5.egg
c:\python25\lib\site-packages\pil-1.1.6-py2.5-win32.egg
c:\python25\lib\site-packages\epydoc-3.0beta1-py2.5-win32.egg
c:\python25\lib\site-packages\pywin32-210-py2.5-win32.egg
C:\WINNT\system32\python25.zip
c:\python25\DLLs
c:\python25\lib
c:\python25\lib\plat-win
c:\python25\lib\lib-tk
c:\python25
c:\python25\lib\site-packages
>>> ^Z


C:\>path=%PATH%;C:\Python25\Lib\site-packages\pywin32-210-py2.5-win32.egg\pywin3
2_system32

C:\>c:\python25\python
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import win32file
>>> ^Z


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

>Comment By: Mark Hammond (mhammond)
Date: 2007-07-29 11:00

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

How did you install it?  The pywin32_postinstall.py script is supposed to
be run by the installer, which copies these DLLs to either your SYSTEM32
directory, or the directory with python.exe in it.

It looks like you are using an egg provided by someone else - you should
discuss your problem with them, as pywin32 does not (yet) support eggs.

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

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

[pywin32-bugs] [ pywin32-Bugs-1762768 ] 'import win32file' in Python 2.5.1 can't locate PYWINTYPES25

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

Bugs item #1762768, was opened at 2007-07-28 10:01
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=1762768&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: Sam Denton (samwyse)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'import win32file' in Python 2.5.1 can't locate PYWINTYPES25

Initial Comment:
Adding to Window's PATH fixes everything.

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\>c:\python25\python
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import win32file
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: DLL load failed: The specified module could not be found.
>>> import sys
>>> for d in sys.path: print d
...

c:\python25\lib\site-packages\setuptools-0.6c6-py2.5.egg
c:\python25\lib\site-packages\sqlalchemy-0.3.10-py2.5.egg
c:\python25\lib\site-packages\pil-1.1.6-py2.5-win32.egg
c:\python25\lib\site-packages\epydoc-3.0beta1-py2.5-win32.egg
c:\python25\lib\site-packages\pywin32-210-py2.5-win32.egg
C:\WINNT\system32\python25.zip
c:\python25\DLLs
c:\python25\lib
c:\python25\lib\plat-win
c:\python25\lib\lib-tk
c:\python25
c:\python25\lib\site-packages
>>> ^Z


C:\>path=%PATH%;C:\Python25\Lib\site-packages\pywin32-210-py2.5-win32.egg\pywin3
2_system32

C:\>c:\python25\python
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import win32file
>>> ^Z


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

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

[pywin32-bugs] [ pywin32-Bugs-1648655 ] Wrong args order with event handler

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
>Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: atsuo ishimoto (ishimoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong args order with event handler

Initial Comment:
Order of args doesn't match with prototype generated by makepy.

To reproduce, please run script below and Save workbook on the Excel.

# <<<<<< BEGIN >>>>>>
import win32com.client

class WorkbookEvent:
    def OnBeforeSave(self, SaveAsUI, Cancel):
        print "OnBeforeSave", SaveAsUI, Cancel
        return False

xl = win32com.client.Dispatch("Excel.Application")
xl.Visible = 1
wb = DispatchWithEvents(xl.Workbooks.Add(), WorkbookEvent)
while 1:
    pythoncom.PumpWaitingMessages()

# <<<<<< END >>>>>>

When I save workbook, WorkbookEvent.OnBeforeSave called with 
SaveAsUI=False and Cancel=False. But on SaveAs, args passed are 
SaveAsUI=False and Cancel=True, which should be SaveAsUI=True and 
Cancel=False. 

Python2.4.3,pywin32-210,MS-Excel 2000



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

>Comment By: atsuo ishimoto (ishimoto)
Date: 2007-07-28 21:35

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

Thank you for comment.
But same script with VB.NET, correct values are passed with correct
order.
So, I guess typelib is corrent.


Part of VB script follows.


    Private WithEvents e1 As Excel.Application

    Private Sub e1_WorkbookBeforeSave(ByVal Wb As Excel.Workbook, ByVal
SaveAsUI As Boolean, ByRef Cancel As Boolean) Handles
e1.WorkbookBeforeSave
        MsgBox("SaveAsUI:" + Str(SaveAsUI) + " Cancel:" + Str(Cancel))
    End Sub
End Class




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

Comment By: Mark Hammond (mhammond)
Date: 2007-07-28 16:17

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

Sorry, but I can't see a bug of ours here.  It sounds like the type info
Excel gives out is wrong - otherwise I'd expect *all* params to be reversed
for all events, and I don't think that is the case.

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

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

[pywin32-bugs] [ pywin32-Bugs-1591650 ] setup.py quits while building win32inet_winhttp.cpp

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

Bugs item #1591650, was opened at 2006-11-07 08:26
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1591650&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: Works For Me
Priority: 5
Private: No
Submitted By: Jan Bölsche (jan_boelsche)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py quits while building win32inet_winhttp.cpp

Initial Comment:
setip.py seems to have trouble with a missing winhttp.h
THis is a bug, right?

Details below:

Warning - can't find an installed platform SDK
Found WINDOWS.H version 0x501 in C:\Program
Files\Microsoft Visual Studio .NET 2
003\VC7\PlatformSDK\include
building 'win32inet' extension
skipping swig of win32/src/win32inet.i
C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\bin\cl.exe /c /nologo /Ox
 /MD /W3 /GX /DNDEBUG -DDISTUTILS_BUILD
-Icom/win32com/src/include -Iwin32/src -
IC:\Python24\include -IC:\Python24\PC
/Tpwin32/src/win32inet_winhttp.cpp /Fobuil
d\temp.win32-2.4\Release\win32/src/win32inet_winhttp.obj
win32inet_winhttp.cpp
win32\src\win32inet_winhttp.cpp(10) : fatal error
C1083: Cannot open include fil
e: 'winhttp.h': No such file or directory
error: command '"C:\Program Files\Microsoft Visual
Studio .NET 2003\Vc7\bin\cl.e
xe"' failed with exit status 2

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

>Comment By: Mark Hammond (mhammond)
Date: 2007-07-28 17:23

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

winhttp.h is included with the platform SDK.

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

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

[pywin32-bugs] [ pywin32-Bugs-1596989 ] problem with Session.ModelObjects() ERwin COM API

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

Bugs item #1596989, was opened at 2006-11-16 00:35
Message generated for change (Settings changed) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1596989&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Denis Komarov (denis_komarov)
Assigned to: Nobody/Anonymous (nobody)
Summary: problem with Session.ModelObjects() ERwin COM API

Initial Comment:
I'm hoping this is a coding error on my part, but I've
encountered a problem with interface that I cannot
understand. I try to use pywin32 (build 210 for Python 2.4) on WinXP for access to AllFusion ERwin Data Modeler 7.1 (Computer Associates) via ERwin COM API:

------------------------- begin erwin.py
import win32com.client
ERwin = win32com.client.dynamic.Dispatch('AllFusionERwin.SCAPI')
PersistenceUnit = ERwin.PersistenceUnits.Add(r'D:\s\model.erwin')
Session = ERwin.Sessions.Add()
ModelSet = PersistenceUnit.ModelSet()
Session.Open(ModelSet)
ModelObjects = Session.ModelObjects()
------------------------- end erwin.py

Traceback (most recent call last):
  File "D:\Project\erwin\src\root\nested\erwin.py", line 7, in ?
    ModelObjects = Session.ModelObjects()
  File "C:\Python24\Lib\site-packages\win32com\client\dynamic.py", line 172, in __call__
    return self._get_good_object_(self._oleobj_.Invoke(*allArgs),self._olerepr_.defaultDispatchName,None)
pywintypes.com_error: (-2147352562, '\xcd\xe5\xe4\xee\xef\xf3\xf1\xf2\xe8\xec\xee\xe5 \xf7\xe8\xf1\xeb\xee \xef\xe0\xf0\xe0\xec\xe5\xf2\xf0\xee\xe2.', None, None)



Any insight into this problem would be most appreciated.

Regards,
Denis V. Komarov



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

Comment By: Mark Hammond (mhammond)
Date: 2006-11-16 08:36

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

I've no idea why the bizarre string was displayed, but the error message
for -2147352562 should be:

>>> pythoncom.GetScodeString(-2147352562)
'Invalid number of parameters.'

Which may give you a clue.  Otherwise, I suggest you try asking on the
pyt...@py... mailing list where more people will see it.

Cheers

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

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

[pywin32-bugs] [ pywin32-Bugs-1619086 ] Excel sort fails w/ early binding in Python 2.2.3

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Craig (craigch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Excel sort fails w/ early binding in Python 2.2.3

Initial Comment:
I am using Python 2.2.3 with Pywin32-210.win32-py2.2 The following Python sequence works fine when using the 'late binding' method.

import win32com.client.dynamic
import types
xlApp = win32com.client.Dispatch("Excel.Application")
xlBook = xlApp.Workbooks.Open( 'C:\\TestExcel.xls' )
sheet = xlBook.Worksheets( 1 )
sheet.Activate()

rangeToSort = xlApp.Range('a2:e5')
rangeToSort.Sort( Key1=sheet.Columns( 3 ), Order1=1 , Header=1 )

Since I required the use of the GetOffset function when using COM with Excel, I compiled the Excel 11.0 Object Library using the COM MakePy Utility in PythonWin. When I run the above sequence now, I get the following error. If I then delete the generated Excel 11.0 .py file in the win32com\gen_py directory. The sequence will then run without a problem.

Traceback (most recent call last):
  File "C:\Python22\Tools\idle\Debugger.py", line 37, in run
    return apply(bdb.Bdb.run, (self,) + args)
  File "C:\Python22\lib\bdb.py", line 349, in run
    exec cmd in globals, locals
  File "<pyshell#10>", line 1, in ?
    rangeToSort.Sort( Key1=sheet.Columns( 3 ), Order1=1 , Header=1 )
  File "C:\Python22\lib\site-packages\win32com\gen_py\00020813-0000-0000-C000-000000000046x0x1x5.py", line 22609, in Sort, SortMethod, DataOption1, DataOption2, DataOption3)
  File "C:\Python22\Lib\site-packages\win32com\client\__init__.py", line 446, in _ApplyTypes_
    return self._get_good_object_( com_error: (-2147352567, 'Exception occurred.', (0, 'Microsoft Office Excel', "The sort reference is not valid. Make sure that it's within the data you want to sort, and the first Sort By box isn't the same or blank.", 'C:\\Program Files\\Microsoft Office\\OFFICE11\\1033\\xlmain11.chm', 0, -2146827284), None)

Varying the setting of the 'bForDemand' parameter did not seems to affect the problem behavior.

I am using Python 2.2.3 in conjunction with a 3rd party app and do not have the option of moving to a upgraded/fixed version of Python at this time. One workaround that I have is to remove the generated Excel 11.0 .py file and no longer use the GetOffset call in my Python code, but wondered if there is a known fix to the above problem.

Thanks,
Craig 

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

>Comment By: Mark Hammond (mhammond)
Date: 2007-07-28 17:21

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

yeah - this sucks :(  The problem is that each COM server has different
ways of handling default params.  MSOffice seems to deal OK with both
styles in general, but there are obviously exceptions, as you saw.  Since
making that change to pywin32 many years ago, the number of complaints
about this reduced significantly

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

Comment By: Craig (craigch)
Date: 2006-12-20 13:07

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

>>
>> rangeToSort.Sort( Key1=sheet.Columns( 3 ), Order1=1 , Header=1,
Key2=pythoncom.Missing, Key3=pythoncom.Missing )
>>

I ran my test with the 'optional' arguments defined as pythoncom.Missing
and it does work now. Previously my code was working under a very old
Python 1.5.2 where the 'defaultNamedNotOptArg' was defined as
pythoncom.Missing in the .py file generated for the Excel 11.0 Object
Library. 

Evidently the more recent Pywin32 for 2.2.3 has defined these optional
arguments as pythoncom.Empty and thus the error was occurring. I expect
there was some rationale for changing the defaults, but it seems an
'optional' argument would want to use Missing rather than Empty. 

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

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

[pywin32-bugs] [ pywin32-Bugs-1648655 ] Wrong args order with event handler

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: atsuo ishimoto (ishimoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong args order with event handler

Initial Comment:
Order of args doesn't match with prototype generated by makepy.

To reproduce, please run script below and Save workbook on the Excel.

# <<<<<< BEGIN >>>>>>
import win32com.client

class WorkbookEvent:
    def OnBeforeSave(self, SaveAsUI, Cancel):
        print "OnBeforeSave", SaveAsUI, Cancel
        return False

xl = win32com.client.Dispatch("Excel.Application")
xl.Visible = 1
wb = DispatchWithEvents(xl.Workbooks.Add(), WorkbookEvent)
while 1:
    pythoncom.PumpWaitingMessages()

# <<<<<< END >>>>>>

When I save workbook, WorkbookEvent.OnBeforeSave called with 
SaveAsUI=False and Cancel=False. But on SaveAs, args passed are 
SaveAsUI=False and Cancel=True, which should be SaveAsUI=True and 
Cancel=False. 

Python2.4.3,pywin32-210,MS-Excel 2000



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

>Comment By: Mark Hammond (mhammond)
Date: 2007-07-28 17:17

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

Sorry, but I can't see a bug of ours here.  It sounds like the type info
Excel gives out is wrong - otherwise I'd expect *all* params to be reversed
for all events, and I don't think that is the case.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&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-07-27 07:26

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

I'm sorry the patch I submitted didn't work. Not sure what went wrong
there.

The patch you proposed would also need handle the
Set2dByteArrayVariantByRef...Being able to pass in a multi-dimensional
array is important also.

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

Comment By: Mark Hammond (mhammond)
Date: 2007-07-26 03:31

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

I'm adding a new patch that doesn't attempt to return multiple buffers - I
couldn't make the old patch return the correct data, and
http://mail.python.org/pipermail/python-win32/2007-July/006096.html
convinces me that the right thing to do may well be to return a single
buffer in this case, so long as the caller can get the dimensions - that
way, if the data is destined for PIL etc, its very efficient, but still
simple for someone to slice up if they really do need it as a multi-dim
array.

The patch works, but I'm reluctant to check it in until we do return the
dimensions.  This might mean creating a new buffer-like object.
File Added: 2d_ui1.patch

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

Comment By: wyrock (wyrock)
Date: 2007-07-23 06:59

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

Mark,

I was just curious if you had been able to review this change and add it
to the current source tree?

Thanks,
Kevin

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

Comment By: Mark Hammond (mhammond)
Date: 2007-05-15 17: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 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-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-07-26 18:31

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

I'm adding a new patch that doesn't attempt to return multiple buffers - I
couldn't make the old patch return the correct data, and
http://mail.python.org/pipermail/python-win32/2007-July/006096.html
convinces me that the right thing to do may well be to return a single
buffer in this case, so long as the caller can get the dimensions - that
way, if the data is destined for PIL etc, its very efficient, but still
simple for someone to slice up if they really do need it as a multi-dim
array.

The patch works, but I'm reluctant to check it in until we do return the
dimensions.  This might mean creating a new buffer-like object.
File Added: 2d_ui1.patch

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

Comment By: wyrock (wyrock)
Date: 2007-07-23 21:59

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

Mark,

I was just curious if you had been able to review this change and add it
to the current source tree?

Thanks,
Kevin

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

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-Feature Requests-1114447 ] Need documentation separate from kit

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

Feature Requests item #1114447, was opened at 2005-02-01 21:42
Message generated for change (Comment added) made by carlk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1114447&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: Gary Feldman (garyfx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Need documentation separate from kit

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

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

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

Gary

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

Comment By: Carl Karsten (carlk)
Date: 2007-07-25 09:24

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

+1

I am looking to implement "broadcast a WM_SETTINGCHANGE message to all
windows    SendMessageTimeout(HWND_BROADCAST, ..."  
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q104011

after lots of googleing, someone else found
http://aspn.activestate.com/ASPN/docs/ActivePython/2.5/pywin32/win32api__SendMessage_meth.html

Which is close, but I am guessing not what I need.  I would think the docs
should be here.

(don't answer my SendMessageTimeout() thing here, I'll start a new thread
for that.)


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1114447&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-07-23 06:59

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

Mark,

I was just curious if you had been able to review this change and add it
to the current source tree?

Thanks,
Kevin

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

Comment By: Mark Hammond (mhammond)
Date: 2007-05-15 17: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 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-Feature Requests-1672891 ] problem win32api when consulting the registry Reg_MULTI_SZ

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

Feature Requests item #1672891, was opened at 2007-03-03 05:59
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1672891&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: Wont Fix
Priority: 5
Private: No
Submitted By: Josu Rodriguez Vilda (jrvilda)
Assigned to: Nobody/Anonymous (nobody)
Summary: problem win32api when consulting the registry  Reg_MULTI_SZ

Initial Comment:
hello,
First, I hope that they pardon the English to me, since I am Spanish and am using the tool of google. The problem takes place when consulting registry keys type reg_MULTI_SZ with several values, the turn out  to give several values and single it shows one. Example: 
[pendientes.reg]
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]
"PendingFileRenameOperations"=hex(7):5c,00,3f,00,3f,00,5c,00,43,00,3a,00,5c,00,\
  41,00,72,00,63,00,68,00,69,00,76,00,6f,00,73,00,20,00,64,00,65,00,20,00,70,\
  00,72,00,6f,00,67,00,72,00,61,00,6d,00,61,00,5c,00,47,00,6f,00,6f,00,67,00,\
  6c,00,65,00,5c,00,47,00,6f,00,6f,00,67,00,6c,00,65,00,54,00,6f,00,6f,00,6c,\
  00,62,00,61,00,72,00,4e,00,6f,00,74,00,69,00,66,00,69,00,65,00,72,00,5c,00,\
  31,00,2e,00,32,00,2e,00,39,00,30,00,38,00,2e,00,35,00,30,00,30,00,38,00,5c,\
  00,73,00,77,00,67,00,33,00,2e,00,74,00,6d,00,70,00,00,00,00,00,5c,00,3f,00,\
  3f,00,5c,00,43,00,3a,00,5c,00,41,00,72,00,63,00,68,00,69,00,76,00,6f,00,73,\
  00,20,00,64,00,65,00,20,00,70,00,72,00,6f,00,67,00,72,00,61,00,6d,00,61,00,\
  5c,00,47,00,6f,00,6f,00,67,00,6c,00,65,00,5c,00,47,00,6f,00,6f,00,67,00,6c,\
  00,65,00,54,00,6f,00,6f,00,6c,00,62,00,61,00,72,00,4e,00,6f,00,74,00,69,00,\
  66,00,69,00,65,00,72,00,5c,00,31,00,2e,00,32,00,2e,00,39,00,30,00,38,00,2e,\
  00,35,00,30,00,30,00,38,00,5c,00,47,00,6f,00,6f,00,34,00,2e,00,74,00,6d,00,\
  70,00,00,00,00,00,5c,00,3f,00,3f,00,5c,00,43,00,3a,00,5c,00,41,00,72,00,63,\
  00,68,00,69,00,76,00,6f,00,73,00,20,00,64,00,65,00,20,00,70,00,72,00,6f,00,\
  67,00,72,00,61,00,6d,00,61,00,5c,00,47,00,6f,00,6f,00,67,00,6c,00,65,00,5c,\
  00,47,00,6f,00,6f,00,67,00,6c,00,65,00,54,00,6f,00,6f,00,6c,00,62,00,61,00,\
  72,00,4e,00,6f,00,74,00,69,00,66,00,69,00,65,00,72,00,5c,00,31,00,2e,00,32,\
  00,2e,00,39,00,30,00,38,00,2e,00,35,00,30,00,30,00,38,00,5c,00,72,00,65,00,\
  73,00,35,00,2e,00,74,00,6d,00,70,00,00,00,00,00,5c,00,3f,00,3f,00,5c,00,43,\
  00,3a,00,5c,00,41,00,72,00,63,00,68,00,69,00,76,00,6f,00,73,00,20,00,64,00,\
  65,00,20,00,70,00,72,00,6f,00,67,00,72,00,61,00,6d,00,61,00,5c,00,47,00,6f,\
  00,6f,00,67,00,6c,00,65,00,5c,00,47,00,6f,00,6f,00,67,00,6c,00,65,00,54,00,\
  6f,00,6f,00,6c,00,62,00,61,00,72,00,4e,00,6f,00,74,00,69,00,66,00,69,00,65,\
  00,72,00,5c,00,31,00,2e,00,32,00,2e,00,39,00,30,00,38,00,2e,00,35,00,30,00,\
  30,00,38,00,00,00,00,00,5c,00,3f,00,3f,00,5c,00,43,00,3a,00,5c,00,41,00,72,\
  00,63,00,68,00,69,00,76,00,6f,00,73,00,20,00,64,00,65,00,20,00,70,00,72,00,\
  6f,00,67,00,72,00,61,00,6d,00,61,00,5c,00,47,00,6f,00,6f,00,67,00,6c,00,65,\
  00,5c,00,47,00,6f,00,6f,00,67,00,6c,00,65,00,54,00,6f,00,6f,00,6c,00,62,00,\
  61,00,72,00,4e,00,6f,00,74,00,69,00,66,00,69,00,65,00,72,00,00,00,00,00,5c,\
  00,3f,00,3f,00,5c,00,43,00,3a,00,5c,00,41,00,72,00,63,00,68,00,69,00,76,00,\
  6f,00,73,00,20,00,64,00,65,00,20,00,70,00,72,00,6f,00,67,00,72,00,61,00,6d,\
  00,61,00,5c,00,47,00,6f,00,6f,00,67,00,6c,00,65,00,5c,00,47,00,6f,00,6f,00,\
  67,00,6c,00,65,00,54,00,6f,00,6f,00,6c,00,62,00,61,00,72,00,32,00,2e,00,64,\
  00,6c,00,6c,00,00,00,00,00,5c,00,3f,00,3f,00,5c,00,43,00,3a,00,5c,00,41,00,\
  72,00,63,00,68,00,69,00,76,00,6f,00,73,00,20,00,64,00,65,00,20,00,70,00,72,\
  00,6f,00,67,00,72,00,61,00,6d,00,61,00,5c,00,47,00,6f,00,6f,00,67,00,6c,00,\
  65,00,5c,00,47,00,6f,00,6f,00,67,00,6c,00,65,00,54,00,6f,00,6f,00,6c,00,62,\
  00,61,00,72,00,4e,00,6f,00,74,00,69,00,66,00,69,00,65,00,72,00,5c,00,31,00,\
  2e,00,32,00,2e,00,39,00,30,00,38,00,2e,00,35,00,30,00,30,00,38,00,00,00,00,\
  00,5c,00,3f,00,3f,00,5c,00,63,00,3a,00,5c,00,61,00,72,00,63,00,68,00,69,00,\
  76,00,6f,00,73,00,20,00,64,00,65,00,20,00,70,00,72,00,6f,00,67,00,72,00,61,\
  00,6d,00,61,00,5c,00,67,00,6f,00,6f,00,67,00,6c,00,65,00,5c,00,67,00,6f,00,\
  6f,00,67,00,6c,00,65,00,74,00,6f,00,6f,00,6c,00,62,00,61,00,72,00,32,00,2e,\
  00,64,00,6c,00,6c,00,00,00,00,00,00,00

[/prendientes.reg]


[CODE]

pendingFileRename=time.strftime("%A  %d-%m-%Y  %H:%M", time.localtime())
def getPendingFileRenameOperations():
    
    aKey = _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE,r"SYSTEM\CurrentControlSet\Control\Session Manager")
    try:
       try: values = _winreg.QueryValueEx(aKey, "PendingFileRenameOperations")[0]
       except WindowsError: values = ("No Existen Datos")
    finally:
       _winreg.CloseKey(aKey)
    
    return values

    

pendingFileRename=pendingFileRename+"\n\n"+str(getPendingFileRenameOperations())

pendingFileRename=pendingFileRename+"\n\n--------------------"
pendingFileRename=pendingFileRename+"\nRecuerda que aun es una versión DEMO.\nDebes de usar programas testeados como puede ser:\npendmoves.exe de sysinternals."
self.txm373c.SetValue(pendingFileRename)

RESULTADO WIN32API=
[u'\\??\\C:\\Archivos de programa\\Google\\GoogleToolbarNotifier\\1.2.908.5008\\swg3.tmp']

RESULTADO OK=
[u'\\??\\C:\\Archivos de programa\\Google\\GoogleToolbarNotifier\\1.2.908.5008\\swg3.tmp',u'\\??\\C:\\Archivos de programa\\Google\\GoogleToolbarNotifier\\1.2.908.5008\\res5.tmp',u'\\??\\C:\\Archivos de programa\\Google\\GoogleToolbarNotifier\\1.2.908.5008\\goo4.tmp',u'\\??\\C:\\Archivos de programa\\Google\\GoogleToolbarNotifier\\1.2.908.5008',etc]



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

>Comment By: Roger Upole (rupole)
Date: 2007-07-22 16:43

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

Since there is an api specifically for this, closing as 'won't fix'


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

Comment By: Roger Upole (rupole)
Date: 2007-03-03 16:45

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

It appears the paths in the data are separated by double NULLs, which are
used as a terminator
for REG_MULTI_SZ values.  According to the docs here:
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/58499.mspx?mfr=true
this key shouldn't be manipulated directly (probably for this very same
reason).
You should be able to use win32file.MoveFileEx with
MOVEFILE_DELAY_UNTIL_REBOOT instead.

                 Roger


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

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

[pywin32-bugs] [ pywin32-Feature Requests-1755527 ] Default to buffer for win32ts.WTSQuerySessionInformation

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

Feature Requests item #1755527, was opened at 2007-07-17 10:33
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1755527&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: ken (kchmbrln)
Assigned to: Nobody/Anonymous (nobody)
Summary: Default to buffer for win32ts.WTSQuerySessionInformation

Initial Comment:
Currently win32ts.WTSQuerySessionInformation raises a PyExc_NotImplementedError exception in those cases where no specific interpretation of the results has been provided.  It would be more useful if, instead of an exception, it would return a buffer object with the raw contents of the buffer that the api function returned copied into it.  Then the user could use something like struct.unpack_from(fmt, buffer [,offset = 0]) to interpret the results as needed.

Something like (untested):

	switch (WTSInfoClass){
                ...
		default:
                        void *newbuf
                        ret=PyBuffer_New(bufsize);
                        ret->ob_type->tp_as_buffer->bf_getwritebuffer(ret, 0, &newbuf);
                        memcpy(newbuf, buf, bufsize);
		}


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

>Comment By: Roger Upole (rupole)
Date: 2007-07-22 16:37

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

The two remaining classes of information have been added.


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

Comment By: ken (kchmbrln)
Date: 2007-07-18 09:12

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

I guess if Roger is going to implement the last two cases here that kinda
makes the question moot.
Philosophically speaking, though, it seems to me that getting data that
may contain bad pointers is still preferable to not being able to get any
data at all, and having fragile code that may break with an upgrade is
still preferable to not having any way to code it at all.  Maybe another
alternative would be to continue to raise the exception, but to provide the
buffer contents along with it.  At least then the user should not be
surprised by an upgrade breaking the workaround.
As for Mark's idea of adding an extra parameter to ask for the raw buffer
-- I can imagine that could be useful if, for example, you wanted to
serialize some complex structure in its already packed form without having
it unpacked for you and then having to repack it.  I don't, however, see
much potential for that with WTSQuerySessionInformation.

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

Comment By: Roger Upole (rupole)
Date: 2007-07-18 00:25

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

Another issue with copying the buffer is that the buffer
could contain pointers to addresses inside the original
buffer, which would become invalid after copying and
freeing the original buffer.  There are only 2
classes of information not supported yet
(WTSClientAddress and WTSClientDisplay), so I'll go ahead and
implement them.


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

Comment By: Mark Hammond (mhammond)
Date: 2007-07-17 16:46

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

If we do that, it would prevent us upgrading the code in the future (as it
would then break code which assumed the buffer).  An alternative might be
an extra param to indicate if a buffer is wanted or not, which would then
be used in all cases.

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

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

[pywin32-bugs] [ pywin32-Feature Requests-1755527 ] Default to buffer for win32ts.WTSQuerySessionInformation

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

Feature Requests item #1755527, was opened at 2007-07-17 10:33
Message generated for change (Comment added) made by kchmbrln
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1755527&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: ken (kchmbrln)
Assigned to: Nobody/Anonymous (nobody)
Summary: Default to buffer for win32ts.WTSQuerySessionInformation

Initial Comment:
Currently win32ts.WTSQuerySessionInformation raises a PyExc_NotImplementedError exception in those cases where no specific interpretation of the results has been provided.  It would be more useful if, instead of an exception, it would return a buffer object with the raw contents of the buffer that the api function returned copied into it.  Then the user could use something like struct.unpack_from(fmt, buffer [,offset = 0]) to interpret the results as needed.

Something like (untested):

	switch (WTSInfoClass){
                ...
		default:
                        void *newbuf
                        ret=PyBuffer_New(bufsize);
                        ret->ob_type->tp_as_buffer->bf_getwritebuffer(ret, 0, &newbuf);
                        memcpy(newbuf, buf, bufsize);
		}


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

>Comment By: ken (kchmbrln)
Date: 2007-07-18 09:12

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

I guess if Roger is going to implement the last two cases here that kinda
makes the question moot.
Philosophically speaking, though, it seems to me that getting data that
may contain bad pointers is still preferable to not being able to get any
data at all, and having fragile code that may break with an upgrade is
still preferable to not having any way to code it at all.  Maybe another
alternative would be to continue to raise the exception, but to provide the
buffer contents along with it.  At least then the user should not be
surprised by an upgrade breaking the workaround.
As for Mark's idea of adding an extra parameter to ask for the raw buffer
-- I can imagine that could be useful if, for example, you wanted to
serialize some complex structure in its already packed form without having
it unpacked for you and then having to repack it.  I don't, however, see
much potential for that with WTSQuerySessionInformation.

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

Comment By: Roger Upole (rupole)
Date: 2007-07-18 00:25

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

Another issue with copying the buffer is that the buffer
could contain pointers to addresses inside the original
buffer, which would become invalid after copying and
freeing the original buffer.  There are only 2
classes of information not supported yet
(WTSClientAddress and WTSClientDisplay), so I'll go ahead and
implement them.


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

Comment By: Mark Hammond (mhammond)
Date: 2007-07-17 16:46

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

If we do that, it would prevent us upgrading the code in the future (as it
would then break code which assumed the buffer).  An alternative might be
an extra param to indicate if a buffer is wanted or not, which would then
be used in all cases.

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

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

[pywin32-bugs] [ pywin32-Feature Requests-1755527 ] Default to buffer for win32ts.WTSQuerySessionInformation

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

Feature Requests item #1755527, was opened at 2007-07-17 10:33
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1755527&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: ken (kchmbrln)
Assigned to: Nobody/Anonymous (nobody)
Summary: Default to buffer for win32ts.WTSQuerySessionInformation

Initial Comment:
Currently win32ts.WTSQuerySessionInformation raises a PyExc_NotImplementedError exception in those cases where no specific interpretation of the results has been provided.  It would be more useful if, instead of an exception, it would return a buffer object with the raw contents of the buffer that the api function returned copied into it.  Then the user could use something like struct.unpack_from(fmt, buffer [,offset = 0]) to interpret the results as needed.

Something like (untested):

	switch (WTSInfoClass){
                ...
		default:
                        void *newbuf
                        ret=PyBuffer_New(bufsize);
                        ret->ob_type->tp_as_buffer->bf_getwritebuffer(ret, 0, &newbuf);
                        memcpy(newbuf, buf, bufsize);
		}


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

>Comment By: Roger Upole (rupole)
Date: 2007-07-18 00:25

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

Another issue with copying the buffer is that the buffer
could contain pointers to addresses inside the original
buffer, which would become invalid after copying and
freeing the original buffer.  There are only 2
classes of information not supported yet
(WTSClientAddress and WTSClientDisplay), so I'll go ahead and
implement them.


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

Comment By: Mark Hammond (mhammond)
Date: 2007-07-17 16:46

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

If we do that, it would prevent us upgrading the code in the future (as it
would then break code which assumed the buffer).  An alternative might be
an extra param to indicate if a buffer is wanted or not, which would then
be used in all cases.

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

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

[pywin32-bugs] [ pywin32-Feature Requests-1755527 ] Default to buffer for win32ts.WTSQuerySessionInformation

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

Feature Requests item #1755527, was opened at 2007-07-18 01:33
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1755527&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: ken (kchmbrln)
Assigned to: Nobody/Anonymous (nobody)
Summary: Default to buffer for win32ts.WTSQuerySessionInformation

Initial Comment:
Currently win32ts.WTSQuerySessionInformation raises a PyExc_NotImplementedError exception in those cases where no specific interpretation of the results has been provided.  It would be more useful if, instead of an exception, it would return a buffer object with the raw contents of the buffer that the api function returned copied into it.  Then the user could use something like struct.unpack_from(fmt, buffer [,offset = 0]) to interpret the results as needed.

Something like (untested):

	switch (WTSInfoClass){
                ...
		default:
                        void *newbuf
                        ret=PyBuffer_New(bufsize);
                        ret->ob_type->tp_as_buffer->bf_getwritebuffer(ret, 0, &newbuf);
                        memcpy(newbuf, buf, bufsize);
		}


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

>Comment By: Mark Hammond (mhammond)
Date: 2007-07-18 07:46

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

If we do that, it would prevent us upgrading the code in the future (as it
would then break code which assumed the buffer).  An alternative might be
an extra param to indicate if a buffer is wanted or not, which would then
be used in all cases.

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

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

[pywin32-bugs] [ pywin32-Feature Requests-1755527 ] Default to buffer for win32ts.WTSQuerySessionInformation

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

Feature Requests item #1755527, was opened at 2007-07-17 10:33
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=1755527&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: ken (kchmbrln)
Assigned to: Nobody/Anonymous (nobody)
Summary: Default to buffer for win32ts.WTSQuerySessionInformation

Initial Comment:
Currently win32ts.WTSQuerySessionInformation raises a PyExc_NotImplementedError exception in those cases where no specific interpretation of the results has been provided.  It would be more useful if, instead of an exception, it would return a buffer object with the raw contents of the buffer that the api function returned copied into it.  Then the user could use something like struct.unpack_from(fmt, buffer [,offset = 0]) to interpret the results as needed.

Something like (untested):

	switch (WTSInfoClass){
                ...
		default:
                        void *newbuf
                        ret=PyBuffer_New(bufsize);
                        ret->ob_type->tp_as_buffer->bf_getwritebuffer(ret, 0, &newbuf);
                        memcpy(newbuf, buf, bufsize);
		}


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

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

[pywin32-bugs] [ pywin32-Bugs-1751668 ] PythonWin 210 crashes on startup

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

Bugs item #1751668, was opened at 2007-07-11 07:15
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=1751668&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: Pash (wildpash)
Assigned to: Nobody/Anonymous (nobody)
Summary: PythonWin 210 crashes on startup

Initial Comment:
Hi,

PythonWin crashes at startup.

Machine: Windows 2003 Server

Does there exist a possibility to switch on a log-file for further investigation?

Thanks

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

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

[pywin32-bugs] [ pywin32-Bugs-1751177 ] Missing CF_DIBV5

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

Bugs item #1751177, was opened at 2007-07-10 15:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1751177&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: Pete Forman (pete_forman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing CF_DIBV5

Initial Comment:
The clipboard formats defined as attributes of win32clipboard and win32con do not include CF_DIBV5 = 18.  This was new in Windows 2000.  I observed it copying from Excel 2002 on XP.

See

http://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/featusability/assoc.mspx

and winuser.h

pywin32 210 on Python 2.5.1.


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

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

[pywin32-bugs] [ pywin32-Bugs-1746689 ] National characters (Polish) are entered incorrectly

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

Bugs item #1746689, was opened at 2007-07-02 17:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1746689&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: admindomeny (admindomeny)
Assigned to: Nobody/Anonymous (nobody)
Summary: National characters (Polish) are entered incorrectly

Initial Comment:

Entering (Polish) national characters using standard Windows keyboard (using so called "Polish Programmer's Keyboard") enters wrong Unicode characters.

OS: Win XP SP2, Polish edition.

I have tried changing fonts to what are Unicode fonts as far as I know (Times New Roman, Arial, etc), including fonts designated as "CE" in Windows (Central Europe) as well. It doesn't work.

I made sure that Polish Programmer's Keyboard is turned on which gives me correct encoding in almost all Windows applications, including Unicode editors like UniRed.

Still, Pythonwin shell in particular thinks that 
AltGr+a (standard way of entering 'LATIN SMALL LETTER A WITH OGONEK') is actually 'SUPERSCRIPT ONE' for example.

To summarize:

1. IDLE edits the text in Unicode correctly provided there's a #-*- coding: utf-8 -*- header in first line.

2. Pythonwin executes that file correctly.

3. Pythonwin enters national characters INCORRECTLY (at least as far as Polish is concerned, but I suspect this is also the case with other languages).

See attached screenshot for visualisation of the problem.


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

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

[pywin32-bugs] [ pywin32-Bugs-956654 ] Incomplete installation of v. 201.1 on Windows XP

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: installation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incomplete installation of v. 201.1 on Windows XP

Initial Comment:
I just installed pywin32 201.1 on a new Windows XP 
machine (using Python 2.3.3); this was the first 
pywin32 build I've installed on this machine.  The 
installation apparently succeeded, however, right-
clicking a .py file does not present "Edit" as a command 
(only "Edit with IDLE").  During installation, there was 
no option presented on whether to make Pythonwn my 
default python editor, as I believe used to be done with 
previous builds.

I've also installed 201.1 on another XP machine which 
has had several previous pywin32 builds installed and 
uninstalled.  There the "Edit" command is present in 
the context menu.


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

>Comment By: Roger Upole (rupole)
Date: 2007-07-01 19:34

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

This is the same issue as 1013126.  The appropriate
registry entries should be created in future
builds.




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

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

[pywin32-bugs] [ pywin32-Bugs-1157829 ] postinstall failure: LoadSystemModule on Win95

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

Bugs item #1157829, was opened at 2005-03-06 13:05
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1157829&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: Out of Date
Priority: 5
Private: No
Submitted By: xet7 (xet7)
Assigned to: Nobody/Anonymous (nobody)
Summary: postinstall failure: LoadSystemModule on Win95

Initial Comment:
On Win95 B (finnish), installed today from scratch
using vmware:
- IE 5.5 SP2
- Dcom for Win95 (DC95Inst)
- Office 97
- Updates from WindowsUpdate.microsoft.com
- python2.4.msi
- wxPython2.5-win32-unicode-2.5.3.1-py24
- wxPython2.5-win32-docs-demos-2.5.3.1
- MySQL-python.exe-1.2.0.win32-py2.4
- pywin32-203.win32-py2.4 (same error with build 202)

wxPython demo and all others installed and run fine,
but when installing pywin32 I got error:

Traceback (most recent call last):
  File "C:\Python24\Scripts\pywin32_postinstall.py",
line 358, in ?
    install()
  File "C:\Python24\Scripts\pywin32_postinstall.py",
line 155, in install
    LoadSystemModule(lib_dir, "pywintypes")
  File "C:\Python24\Scripts\pywin32_postinstall.py",
line 94, in LoadSystemModule
    ('.dll', 'rb', imp.C_EXTENSION))
ImportError: DLL load failed: Jestelm kytketty
laite ei toimi. (=>translation: device attached to
system does not work)
*** run_installscript: internal error 0xFFFFFFFF ***

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

>Comment By: Roger Upole (rupole)
Date: 2007-07-01 16:03

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

Windows 95 has been unsupported for some time now, so closing as out of
date.


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

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

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

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

Bugs item #1013126, was opened at 2004-08-20 15:54
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1013126&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: Jon McLin (jon_mclin)
Assigned to: Nobody/Anonymous (nobody)
Summary: PythonWin not installed in context menu.

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

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

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

>Comment By: Roger Upole (rupole)
Date: 2007-07-01 16:01

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

It appears this was missed when the installer switched to distutils.
The registry entries for the right-click context menu have been
added to the postinstall script. (pywin32_postinstall.py rev 1.19)



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

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

Message:
Logged In: YES 
user_id=1038590

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

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

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

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

Message:
Logged In: YES 
user_id=96775

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


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

Comment By: Jon McLin (jon_mclin)
Date: 2004-08-20 15:56

Message:
Logged In: YES 
user_id=1071288

PS - platform is Win XP Pro.

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

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

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

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

Bugs item #1731295, was opened at 2007-06-05 05:55
Message generated for change (Settings changed) made by rupole
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: Closed
>Resolution: Fixed
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)





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

>Comment By: Roger Upole (rupole)
Date: 2007-06-29 23:46

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

Rev 1.25 of win32serviceutil.py uses GetServiceKeyName which handles
unicode


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

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