pywin32-bugs Mailing List for Python for Windows Extensions (Page 67)
OLD project page for the Python extensions for Windows
Brought to you by:
mhammond
Menu
▾
▴
pywin32-bugs — Automated tracker notifications (not for bug reports!)
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(24) |
May
(19) |
Jun
(15) |
Jul
(43) |
Aug
(39) |
Sep
(25) |
Oct
(43) |
Nov
(19) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(21) |
Feb
(18) |
Mar
(14) |
Apr
(80) |
May
(56) |
Jun
(24) |
Jul
(30) |
Aug
(17) |
Sep
(36) |
Oct
(106) |
Nov
(38) |
Dec
(30) |
| 2005 |
Jan
(14) |
Feb
(14) |
Mar
(48) |
Apr
(28) |
May
(49) |
Jun
(23) |
Jul
(9) |
Aug
(13) |
Sep
(28) |
Oct
(21) |
Nov
(8) |
Dec
(26) |
| 2006 |
Jan
(56) |
Feb
(33) |
Mar
(33) |
Apr
(18) |
May
(16) |
Jun
(9) |
Jul
(24) |
Aug
(16) |
Sep
(14) |
Oct
(37) |
Nov
(38) |
Dec
(22) |
| 2007 |
Jan
(7) |
Feb
(16) |
Mar
(11) |
Apr
(15) |
May
(15) |
Jun
(8) |
Jul
(24) |
Aug
(26) |
Sep
(18) |
Oct
(11) |
Nov
(20) |
Dec
(1) |
| 2008 |
Jan
(19) |
Feb
(55) |
Mar
(7) |
Apr
(35) |
May
(66) |
Jun
(38) |
Jul
(26) |
Aug
(5) |
Sep
(25) |
Oct
(25) |
Nov
(18) |
Dec
(18) |
| 2009 |
Jan
(25) |
Feb
(38) |
Mar
(29) |
Apr
(25) |
May
(5) |
Jun
(11) |
Jul
(16) |
Aug
(16) |
Sep
(16) |
Oct
(1) |
Nov
(15) |
Dec
(33) |
| 2010 |
Jan
(13) |
Feb
(11) |
Mar
(1) |
Apr
(24) |
May
(26) |
Jun
(19) |
Jul
(22) |
Aug
(51) |
Sep
(38) |
Oct
(39) |
Nov
(25) |
Dec
(27) |
| 2011 |
Jan
(40) |
Feb
(31) |
Mar
(21) |
Apr
(42) |
May
(11) |
Jun
(16) |
Jul
(20) |
Aug
(14) |
Sep
(6) |
Oct
(8) |
Nov
(34) |
Dec
(7) |
| 2012 |
Jan
(60) |
Feb
(24) |
Mar
(6) |
Apr
(28) |
May
(41) |
Jun
(15) |
Jul
(14) |
Aug
(25) |
Sep
(30) |
Oct
(18) |
Nov
(30) |
Dec
(9) |
| 2013 |
Jan
(3) |
Feb
(8) |
Mar
(17) |
Apr
(23) |
May
(34) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2007-02-16 19:25:43
|
Bugs item #1659071, was opened at 2007-02-13 08:10 Message generated for change (Settings changed) made by jaraco You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1659071&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: v1.0 (example) >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jason R. Coombs (jaraco) Assigned to: Nobody/Anonymous (nobody) Summary: win32timezone breaks with Windows Vista Initial Comment: Windows Vista has introduced a new mechanism for handling of time zone names. Some of the functionality still works, but any functionality that depends on retrieving the local time zone will fail under Windows Vista. What needs to be done is to look into what Windows Vista does with tzapi.dll in the various registry settings and to put in the hooks to load the resources from that file as appropriate. I will code these fixes when I can find the time; otherwise, for now this is an open issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1659071&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-02-13 15:16:30
|
Bugs item #1659074, was opened at 2007-02-13 08:16 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=1659074&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: Jason R. Coombs (jaraco) Assigned to: Nobody/Anonymous (nobody) Summary: win32timezone limitations with changes in time zone policy Initial Comment: For 2007, Microsoft has changed the time zone parameters to comply with the new time zone dates for the U.S.. For more information, see http://support.microsoft.com/kb/928388. While win32timezone will continue to work with the new parameters, it will assume these parameters for all of history, so after the above patch is applied or Windows Vista is used, the time zone boundaries will be incorrect for dates prior to 2007. I intend to cache the values for the time zone boundaries prior to 2007 and use them for earlier years. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1659074&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-02-13 15:10:57
|
Bugs item #1659071, was opened at 2007-02-13 08:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1659071&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: v1.0 (example) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason R. Coombs (jaraco) Assigned to: Nobody/Anonymous (nobody) Summary: win32timezone breaks with Windows Vista Initial Comment: Windows Vista has introduced a new mechanism for handling of time zone names. Some of the functionality still works, but any functionality that depends on retrieving the local time zone will fail under Windows Vista. What needs to be done is to look into what Windows Vista does with tzapi.dll in the various registry settings and to put in the hooks to load the resources from that file as appropriate. I will code these fixes when I can find the time; otherwise, for now this is an open issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1659071&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-02-08 23:55:21
|
Bugs item #1655517, was opened at 2007-02-09 07:40 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1655517&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: Invalid Priority: 5 Private: No Submitted By: joshua_benuck (some_guy_coding) Assigned to: Nobody/Anonymous (nobody) Summary: PeekNamedPipe returning "Invalid Handle" Initial Comment: Using the following program: import win32api import win32pipe if __name__ == "__main__": pipe = win32api.GetStdHandle(win32api.STD_INPUT_HANDLE) buffer, bytesToRead, result = win32pipe.PeekNamedPipe(pipe, 1) on a Windows XP Professional machine. Running Python 2.5 and build 210 of the win32all installer yields this error message: Traceback (most recent call last): File "in.py", line 6, in <module> buffer, bytesToRead, result = win32pipe.PeekNamedPipe(pipe, 1) pywintypes.error: (6, 'PeekNamedPipe', 'The handle is invalid.') Is this expected? If it is, how would I go about querying the standard input to see if there is any data waiting? ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2007-02-09 10:55 Message: Logged In: YES user_id=14198 Originator: NO I'm afraid this is just a question about Windows itself and not related to pywin32. I'd suggest either mailing the pyt...@py... mailing list, or searching beyond the Python community to see how a C based program would achieve what you want directly via win32 - it will then be trivial to use that technique using pywin32. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2007-02-09 10:46 Message: Logged In: YES user_id=771074 Originator: NO Console handles won't work with the named pipe functions. You can use the win32console module to check std input. import win32console cb=win32console.PyConsoleScreenBufferType(pipe) if cb.PeekConsoleInput(1) ... Roger Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1655517&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-02-08 23:46:26
|
Bugs item #1655517, was opened at 2007-02-08 15:40 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1655517&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: joshua_benuck (some_guy_coding) Assigned to: Nobody/Anonymous (nobody) Summary: PeekNamedPipe returning "Invalid Handle" Initial Comment: Using the following program: import win32api import win32pipe if __name__ == "__main__": pipe = win32api.GetStdHandle(win32api.STD_INPUT_HANDLE) buffer, bytesToRead, result = win32pipe.PeekNamedPipe(pipe, 1) on a Windows XP Professional machine. Running Python 2.5 and build 210 of the win32all installer yields this error message: Traceback (most recent call last): File "in.py", line 6, in <module> buffer, bytesToRead, result = win32pipe.PeekNamedPipe(pipe, 1) pywintypes.error: (6, 'PeekNamedPipe', 'The handle is invalid.') Is this expected? If it is, how would I go about querying the standard input to see if there is any data waiting? ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2007-02-08 18:46 Message: Logged In: YES user_id=771074 Originator: NO Console handles won't work with the named pipe functions. You can use the win32console module to check std input. import win32console cb=win32console.PyConsoleScreenBufferType(pipe) if cb.PeekConsoleInput(1) ... Roger Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1655517&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-02-08 20:40:37
|
Bugs item #1655517, was opened at 2007-02-08 13:40 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=1655517&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: joe_bob (some_guy_coding) Assigned to: Nobody/Anonymous (nobody) Summary: PeekNamedPipe returning "Invalid Handle" Initial Comment: Using the following program: import win32api import win32pipe if __name__ == "__main__": pipe = win32api.GetStdHandle(win32api.STD_INPUT_HANDLE) buffer, bytesToRead, result = win32pipe.PeekNamedPipe(pipe, 1) on a Windows XP Professional machine. Running Python 2.5 and build 210 of the win32all installer yields this error message: Traceback (most recent call last): File "in.py", line 6, in <module> buffer, bytesToRead, result = win32pipe.PeekNamedPipe(pipe, 1) pywintypes.error: (6, 'PeekNamedPipe', 'The handle is invalid.') Is this expected? If it is, how would I go about querying the standard input to see if there is any data waiting? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1655517&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-02-07 23:13:40
|
Patches item #1651025, was opened at 2007-02-03 10:54 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1651025&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: Brandon Ehle (azverkan) Assigned to: Nobody/Anonymous (nobody) Summary: Use the specified type for constant values Initial Comment: When parsing constant types from the Type Library, the value can be casted incorrectly when converting unsigned integers to python types. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2007-02-08 10:13 Message: Logged In: YES user_id=14198 Originator: NO Excellent - thanks! Checking in TestSources/PyCOMTest/PyCOMImpl.cpp; new revision: 1.14; previous revision: 1.13 Checking in TestSources/PyCOMTest/PyCOMImpl.h; new revision: 1.13; previous revision: 1.12 Checking in TestSources/PyCOMTest/PyCOMTest.idl; new revision: 1.14; previous revision: 1.13 Checking in win32com/client/genpy.py; new revision: 1.51; previous revision: 1.50 Checking in win32com/servers/test_pycomtest.py; new revision: 1.12; previous revision: 1.11 Checking in win32com/src/oleargs.cpp; new revision: 1.37; previous revision: 1.36 Checking in win32com/src/extensions/PyVARDESC.cpp; new revision: 1.2; previous revision: 1.1 Checking in win32com/test/testPyComTest.py; new revision: 1.26; previous revision: 1.25 ---------------------------------------------------------------------- Comment By: Brandon Ehle (azverkan) Date: 2007-02-07 13:12 Message: Logged In: YES user_id=1616 Originator: YES File Added: pywin32.patch ---------------------------------------------------------------------- Comment By: Brandon Ehle (azverkan) Date: 2007-02-07 13:08 Message: Logged In: YES user_id=1616 Originator: YES I've got a test case cobbled together and updated the patch to call VariantClear(). The only problem is that the testcase doesn't automatically detect breakage because of the cache in the site-packages\win32com\gen_py directory. Is there something special when running the tests that you need to do to get it to regenerate the cached interfaces? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-02-05 14:08 Message: Logged In: YES user_id=14198 Originator: NO Sorry - I meant "diff -u" not "-c" ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-02-05 12:56 Message: Logged In: YES user_id=14198 Originator: NO Thanks for the patch. In principle this seems reasonable. Could you please submit a new patch generated with "-c", otherwise it might apply incorrectly. It looks like you should also VariantClear(&varValue)? Finally, can you please give some indication of how this bug manifests itself? My intent is to get something added to the test suite which demonstrates how things go wrong now, and how this patch fixes them. Looking at the patch, it looks simply like a huge constant value in an IDL should be able to provoke it. Cheers ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1651025&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-02-07 02:12:29
|
Patches item #1651025, was opened at 2007-02-02 15:54 Message generated for change (Comment added) made by azverkan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1651025&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: Brandon Ehle (azverkan) Assigned to: Nobody/Anonymous (nobody) Summary: Use the specified type for constant values Initial Comment: When parsing constant types from the Type Library, the value can be casted incorrectly when converting unsigned integers to python types. ---------------------------------------------------------------------- >Comment By: Brandon Ehle (azverkan) Date: 2007-02-06 18:12 Message: Logged In: YES user_id=1616 Originator: YES File Added: pywin32.patch ---------------------------------------------------------------------- Comment By: Brandon Ehle (azverkan) Date: 2007-02-06 18:08 Message: Logged In: YES user_id=1616 Originator: YES I've got a test case cobbled together and updated the patch to call VariantClear(). The only problem is that the testcase doesn't automatically detect breakage because of the cache in the site-packages\win32com\gen_py directory. Is there something special when running the tests that you need to do to get it to regenerate the cached interfaces? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-02-04 19:08 Message: Logged In: YES user_id=14198 Originator: NO Sorry - I meant "diff -u" not "-c" ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-02-04 17:56 Message: Logged In: YES user_id=14198 Originator: NO Thanks for the patch. In principle this seems reasonable. Could you please submit a new patch generated with "-c", otherwise it might apply incorrectly. It looks like you should also VariantClear(&varValue)? Finally, can you please give some indication of how this bug manifests itself? My intent is to get something added to the test suite which demonstrates how things go wrong now, and how this patch fixes them. Looking at the patch, it looks simply like a huge constant value in an IDL should be able to provoke it. Cheers ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1651025&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-02-07 02:08:40
|
Patches item #1651025, was opened at 2007-02-02 15:54 Message generated for change (Comment added) made by azverkan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1651025&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: Brandon Ehle (azverkan) Assigned to: Nobody/Anonymous (nobody) Summary: Use the specified type for constant values Initial Comment: When parsing constant types from the Type Library, the value can be casted incorrectly when converting unsigned integers to python types. ---------------------------------------------------------------------- >Comment By: Brandon Ehle (azverkan) Date: 2007-02-06 18:08 Message: Logged In: YES user_id=1616 Originator: YES I've got a test case cobbled together and updated the patch to call VariantClear(). The only problem is that the testcase doesn't automatically detect breakage because of the cache in the site-packages\win32com\gen_py directory. Is there something special when running the tests that you need to do to get it to regenerate the cached interfaces? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-02-04 19:08 Message: Logged In: YES user_id=14198 Originator: NO Sorry - I meant "diff -u" not "-c" ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-02-04 17:56 Message: Logged In: YES user_id=14198 Originator: NO Thanks for the patch. In principle this seems reasonable. Could you please submit a new patch generated with "-c", otherwise it might apply incorrectly. It looks like you should also VariantClear(&varValue)? Finally, can you please give some indication of how this bug manifests itself? My intent is to get something added to the test suite which demonstrates how things go wrong now, and how this patch fixes them. Looking at the patch, it looks simply like a huge constant value in an IDL should be able to provoke it. Cheers ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1651025&group_id=78018 |
|
From: Mark H. <mha...@sk...> - 2007-02-05 23:16:01
|
This mailing list is for bugs sent by the sourceforge bug tracker. Try the
pyt...@py... address for general queries, where you will find
some people with WMI experience. Unfortunately, I can't offer any clues to
what might be going wrong in this case.
Cheers,
Mark
> 1. I assume that what I have to do is create an instance of the
> TargetLoginOptions class, fill that in, then set the LoginOptions
> attribute of the Target class to what I just created:
>
> C = wmi.Get ("MSiSCSIInitiator_TargetLoginOptions")
> opts = C.SpawnInstance_ ()
> opts.Username = taskfile.user_name
> opts.Password = taskfile.password
> opts.AuthType = 1 # CHAP
> tp.LoginOptions = opts
> tp.Login ()
>
> I get a "generic error". From the behavior of the rest of the system,
> it looks like the operation is attempted, but the outcome is as if the
> LoginOptions had not been present.
>
> 2. Since the Login method has a set of inputs, one of which is
> LoginOptions, I tried passing "opts" that way.
>
> The intuitively obvious syntax is:
> tp.Login (LoginOptions = opts)
> but that doesn't work. It looks like method invocation knows about
> positional arguments but not keyword arguments.
>
> So I read an MSDN article that talks about constructing input
> arguments. It translates to this:
>
> ip = wmi.Get ("MSiSCSIInitiator_TargetClass"). \
> Methods_ ("Login").inParameters.SpawnInstance_()
> ip.LoginOptions = opts
> tp.Login (ip)
>
> Same result: no luck (operation is attempted but it acts as if
> LoginOptions was not present.
>
> I also tried changing the last line to:
> tp.ExecMethod_ ("Login", ip)
>
> Almost the same result -- a "Generic Failure" exception, but this time
> it appears that the operation was not actually attempted.
>
> Does anyone have any idea where I can go from here?
>
> paul
>
>
> --------------------------------------------------------------
> -----------
> Using Tomcat but need to do more? Need to support web
> services, security?
> Get stuff done quickly with pre-integrated technology to make
> your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on
> Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&
dat=121642
_______________________________________________
pywin32-bugs mailing list
pyw...@li...
https://lists.sourceforge.net/lists/listinfo/pywin32-bugs
|
|
From: Paul K. <pk...@eq...> - 2007-02-05 22:45:41
|
I'm using win32com.client to access WMI (via SWbemServices). Much of
it works -- very nice.
There are two things I'm trying to do that I can't get to work right.
Or rather, two approaches to the same thing, neither of which work. I
tried to dig through Microsoft docs to figure this out, but that
didn't help.
I'm dealing with a class (MSiSCSIInitiator_TargetClass). I have an
instance of that class (output of an InstancesOf call in
SWbemServices). According to the class definition -- and a browser I
have agrees -- that class has a LoginOptions property, of type
MSiSCSIInitiator_TargetLoginOptions.
In theory, I can set that property and then call the Login method of
the Target class, or I can pass a LoginOptions argument into the
Target.Login method instead.
I tried both.
1. I assume that what I have to do is create an instance of the
TargetLoginOptions class, fill that in, then set the LoginOptions
attribute of the Target class to what I just created:
C = wmi.Get ("MSiSCSIInitiator_TargetLoginOptions")
opts = C.SpawnInstance_ ()
opts.Username = taskfile.user_name
opts.Password = taskfile.password
opts.AuthType = 1 # CHAP
tp.LoginOptions = opts
tp.Login ()
I get a "generic error". From the behavior of the rest of the system,
it looks like the operation is attempted, but the outcome is as if the
LoginOptions had not been present.
2. Since the Login method has a set of inputs, one of which is
LoginOptions, I tried passing "opts" that way.
The intuitively obvious syntax is:
tp.Login (LoginOptions = opts)
but that doesn't work. It looks like method invocation knows about
positional arguments but not keyword arguments.
So I read an MSDN article that talks about constructing input
arguments. It translates to this:
ip = wmi.Get ("MSiSCSIInitiator_TargetClass"). \
Methods_ ("Login").inParameters.SpawnInstance_()
ip.LoginOptions = opts
tp.Login (ip)
Same result: no luck (operation is attempted but it acts as if
LoginOptions was not present.
I also tried changing the last line to:
tp.ExecMethod_ ("Login", ip)
Almost the same result -- a "Generic Failure" exception, but this time
it appears that the operation was not actually attempted.
Does anyone have any idea where I can go from here?
paul
|
|
From: SourceForge.net <no...@so...> - 2007-02-05 03:08:58
|
Patches item #1651025, was opened at 2007-02-03 10:54 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1651025&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: Brandon Ehle (azverkan) Assigned to: Nobody/Anonymous (nobody) Summary: Use the specified type for constant values Initial Comment: When parsing constant types from the Type Library, the value can be casted incorrectly when converting unsigned integers to python types. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2007-02-05 14:08 Message: Logged In: YES user_id=14198 Originator: NO Sorry - I meant "diff -u" not "-c" ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-02-05 12:56 Message: Logged In: YES user_id=14198 Originator: NO Thanks for the patch. In principle this seems reasonable. Could you please submit a new patch generated with "-c", otherwise it might apply incorrectly. It looks like you should also VariantClear(&varValue)? Finally, can you please give some indication of how this bug manifests itself? My intent is to get something added to the test suite which demonstrates how things go wrong now, and how this patch fixes them. Looking at the patch, it looks simply like a huge constant value in an IDL should be able to provoke it. Cheers ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1651025&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-02-05 01:56:11
|
Patches item #1651025, was opened at 2007-02-03 10:54 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1651025&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: Brandon Ehle (azverkan) Assigned to: Nobody/Anonymous (nobody) Summary: Use the specified type for constant values Initial Comment: When parsing constant types from the Type Library, the value can be casted incorrectly when converting unsigned integers to python types. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2007-02-05 12:56 Message: Logged In: YES user_id=14198 Originator: NO Thanks for the patch. In principle this seems reasonable. Could you please submit a new patch generated with "-c", otherwise it might apply incorrectly. It looks like you should also VariantClear(&varValue)? Finally, can you please give some indication of how this bug manifests itself? My intent is to get something added to the test suite which demonstrates how things go wrong now, and how this patch fixes them. Looking at the patch, it looks simply like a huge constant value in an IDL should be able to provoke it. Cheers ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1651025&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-02-02 23:54:14
|
Patches item #1651025, was opened at 2007-02-02 15:54 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=1651025&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: Brandon Ehle (azverkan) Assigned to: Nobody/Anonymous (nobody) Summary: Use the specified type for constant values Initial Comment: When parsing constant types from the Type Library, the value can be casted incorrectly when converting unsigned integers to python types. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1651025&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-01-31 10:09:54
|
Bugs item #1648655, was opened at 2007-01-31 19:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-01-25 09:21:37
|
Bugs item #1644201, was opened at 2007-01-25 10:21 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=1644201&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Kallas (mkallas) Assigned to: Nobody/Anonymous (nobody) Summary: Install of build 210 fails with Python 2.5 on Win XP Pro Initial Comment: In postinstall pywin32 seems to rely on the python24.dll so it gives this error: Traceback (most recent call last): File "<string>", line 365, in <module> File "<string>", line 157, in install ImportError: DLL load failed: Das angegebene Modul wurde nicht gefunden. *** run_installscript: internal error 0xFFFFFFFF *** See also the attached screenshot. I had installed python24 on that same machine but have uninstalled it meanwhile. NB: While there was accidentally a python24.dll in the same path I started the pywin32 installer, this one seemed to be executed but the another error appeared: Traceback (most recent call last): File "<string>", line 365, in <module> File "<string>", line 157, in install ImportError: Module use of python24.dll conflicts with this version of Python. *** run_installscript: internal error 0xFFFFFFFF *** ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1644201&group_id=78018 |
|
From: Mark H. <mha...@sk...> - 2007-01-19 00:28:42
|
The pyw...@li... mailing list is only for automated mails from the sourceforge bug tracker. The best list for this stuff is pyt...@py.... Please drop pywin32-bugs from any followups.. Note that in general, you *must* use the same compiler for extensions that you use for Python itself. However, without *any* details about the error I can't even start to guess what the problem might be. As pywin32 builds using distutils, I expect that any problems you have are not specific to pywin32 but will be common to all extensions you try and build - but that should become clearer once we get a clue as to what is going wrong. Cheers, Mark -----Original Message----- From: pyw...@li... [mailto:pyw...@li...]On Behalf Of Howard Lightstone Sent: Thursday, 18 January 2007 11:15 AM To: pyw...@li... Subject: [pywin32-bugs] Build problem with VC++ 2005 I am unable to build 210 (with distutils) using VC++ 2005. Unfortunately, I HAVE to use this compiler and rebuild everything (since VC 7 is no longer distributed) going forward. Is this just an issue with the setup.py script? Is it possible to just "manually" (shudder) make up a project file for pywin32 and build that way? -- Howard Lightstone hli...@gm... |
|
From: Howard L. <hli...@gm...> - 2007-01-18 00:15:14
|
I am unable to build 210 (with distutils) using VC++ 2005. Unfortunately, I HAVE to use this compiler and rebuild everything (since VC 7 is no longer distributed) going forward. Is this just an issue with the setup.py script? Is it possible to just "manually" (shudder) make up a project file for pywin32 and build that way? -- Howard Lightstone hli...@gm... |
|
From: SourceForge.net <no...@so...> - 2007-01-15 10:19:22
|
Feature Requests item #1635317, was opened at 2007-01-15 06:35 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1635317&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: Works For Me Priority: 5 Private: No Submitted By: bluescreen (bluescr33n) Assigned to: Nobody/Anonymous (nobody) Summary: Waiting for COM-events Initial Comment: Hello, I'm new to pywin32 and win32 programming in general, so maybe I'm missing something. In the OfficeEvents Example there is a function like this: def _WaitForFinish(): while 1: pythoncom.PumpWaitingMessages() stopEvent.wait(.2) if stopEvent.isSet(): stopEvent.clear() break While this works, I don't like the artificial delay introduced by Event.Wait() Since the COM-application "hangs" after producing an event, and PumpWaitingMessages() is needed to unfreeze it again, it would be nicer to just hang to some sort of Queue-object belonging to the COM-Message-queue instead of polling. Polling creates overhead when the delay is too short, or Application-lag when the delay is too long. I would like to see a construction like this: def _WaitForFinish(): while 1: WaitforMessage() pythoncom.PumpWaitingMessages() if stopEvent.isSet(): stopEvent.clear() break Maybe something like my made-up WaitforMessage already exists, or there already is some other way to accomplish what I want (GUI-like event-loop) that I'm not aware of, in that case I would like to hear more about it. btw: for any comments/answers/questions please email me at blu...@gm... since I don't check SF that often. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2007-01-15 21:19 Message: Logged In: YES user_id=14198 Originator: NO These are just demo scripts. Real-world apps would use something smarter - often using MsgWaitForMultipleObjects. The "Pump*" methods are just implementations of a "standard" message loop - if you prefer, you can use win32gui to roll your own version from the ground up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1635317&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-01-14 19:35:42
|
Feature Requests item #1635317, was opened at 2007-01-14 20:35 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=1635317&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: bluescreen (bluescr33n) Assigned to: Nobody/Anonymous (nobody) Summary: Waiting for COM-events Initial Comment: Hello, I'm new to pywin32 and win32 programming in general, so maybe I'm missing something. In the OfficeEvents Example there is a function like this: def _WaitForFinish(): while 1: pythoncom.PumpWaitingMessages() stopEvent.wait(.2) if stopEvent.isSet(): stopEvent.clear() break While this works, I don't like the artificial delay introduced by Event.Wait() Since the COM-application "hangs" after producing an event, and PumpWaitingMessages() is needed to unfreeze it again, it would be nicer to just hang to some sort of Queue-object belonging to the COM-Message-queue instead of polling. Polling creates overhead when the delay is too short, or Application-lag when the delay is too long. I would like to see a construction like this: def _WaitForFinish(): while 1: WaitforMessage() pythoncom.PumpWaitingMessages() if stopEvent.isSet(): stopEvent.clear() break Maybe something like my made-up WaitforMessage already exists, or there already is some other way to accomplish what I want (GUI-like event-loop) that I'm not aware of, in that case I would like to hear more about it. btw: for any comments/answers/questions please email me at blu...@gm... since I don't check SF that often. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1635317&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-01-03 14:19:08
|
Patches item #1446700, was opened at 2006-03-09 20:32 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1446700&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: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: 4 (+1) Patches to speed up edit-help-debug-run-cycle Initial Comment: Patches: 4 (+1) Patches to speed up the edit-help-debug-run-cycle significantly ================================ pywin.framework.interact : * Ctrl-RETURN in interactive window executes the command directly in debugger ( very nice to speedup edit-run-cycle 2x; don't know how to live without; very helpful also to enter quickly into source code of imported modules ) pywin.scintilla.view : * Ctrl-E : "Execute region" : runs code snippet (auto-unindented), which is marked currently in editor, in interactive namespace ( very nice to speedup edit-run-cycle 2x; don't know how to live without; ) ( similar to Python mode in XEmacs: "Execute Region" ) ( executes currently in __main__.__dict__ ; to be consistent during debugging the current interp-namespace should be used; found no easy link to get this namespace ) * Ctrl-Y : context senitive Python help for smartly guessed words/funcs around cursor in "c:/python23/Doc/Python23.chm" ( is hardwired as of now :-( . should take the CHM-location out of registry ) ( should be put to Ctrl-F1 and maybe to a framework module; Don't know how to bind keys like Ctrl-F1 ) * Ctrl-Q : context senitive PythonWin help for smartly guessed words/funcs around cursor parallel in hf= "c:/python23/lib/site-packages/pywin32.chm" and hf=r"C:\Programme\Microsoft Visual Studio\MSDN98\98VSa\1033\msdnvs6a.col" (hard wiring still to be virtualized; ) ( win32help.HtmlHelp doesn't raise if file non-existing, but returns 0; not checked/no error action as of now ) pywin.mfc.docview , pywin.framework.intpyapp : * repairs the fatal call from pywin.mfc.docview.DocTemplate._SetupSharedMenu_ into a framework module ( that problem crashed py2exe'd apps without Pythonwin framework, but which use the DocTemplate ) ================= apply: cd C:/python23/lib/site-packages/pythonwin/pywin patch -b -p 4 <pywrk.diff created with: diff -ur . /iBase/python/pywin-framework-patched-files >pywrk.diff ---------------------------------------------------------------------- >Comment By: kxroberto (kxroberto) Date: 2007-01-03 15:19 Message: Logged In: YES user_id=972995 Originator: YES pywin32_rkdev2.patch is updated & more clean. It loads the help files already as configured in the registry etc. The "Ctrl-RETURN debugger" (from interactive statement), and the "execute region" functions are more stable and clear now. Still not done are the keybindings for Ctrl-F1/Ctrl-Shift-F1 .. - as I have difficulties to figure out how to get this. Feature Request: Maybe there could be a new * Menu\\Interactive which has the * Menu\\Interactive\\History Back\tCtrl-Up * Menu\\Interactive\\History Forward\tCtrl-Down * Menu\\Interactive\\Debug Statement\tCtrl-RETURN * Menu\\Interactive\\--- * Menu\\Interactive\\Execute Marked Code Region/Line\tCtrl-E * Menu\\Interactive\\Interact Marked Code Region/Line\tCtrl-K and * Menu\\Help\\Python Manuals\tF1 * Menu\\Help\\PythonWin Reference\tShift-F1 * Menu\\Help\\Context Help Python\tCtrl-F1 * Menu\\Help\\Context Help PythonWin\tCtrl-Shift-F1 (mostly in order to announce the key bindings comfortably.) PS: And a strange frequent framework bug (around "SCIMarkerDeleteAll") is addressed though I don't know why "getattr(self.GetEditorView(),'SCIMarkerDeleteAll',None)" can at all return a None - but it actually did so. File Added: pywin32_rkdev2.patch ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-03-22 23:28 Message: Logged In: YES user_id=14198 OK, thanks. I'll try and get back to this - I obviously have a lot on my plate though, and getting this ready to check in isn't going to be an insignificant amount of time. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-03-22 12:59 Message: Logged In: YES user_id=972995 I'll probably not enhance the patch myself. The main remaining difficulties are to get the right key bindings (Ctrl-F1/Ctrl-Shitf-F1 ..) work and for Ctrl-ENTER-debug to get the virtual interactive globals from somewhere. I didn't grasp the required concepts in reasonable time. ======== Ctrl-Shift-Enter : also acceptable - but pressing [Ctrl]+[Enter] for '\'+'n' - thats a habit or :-) ========= help files from registry: found its just 2 lines: import regutil hf = regutil.GetRegisteredHelpFile("Main Python Documentation") import regutil hf = regutil.GetRegisteredHelpFile("Pythonwin Reference") ========== launching 2 helpfiles Pywin & MSDN in a row: thats maybe not a regular behavior, just practical for me: I often need to lookup the windows constants and other basics in parallel, as they are not in the pywin CHM. For a streamlined pythonwin: Maybe just drop the call to MSDN helpfile - or later a more expensive solution: menu item "Menu/help/Context sensitive help .." to add/see user definable key+helpfile pairs. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-03-22 11:00 Message: Logged In: YES user_id=14198 Interesting - this has potential! :) * I'm not that keen on adopting Ctrl+Enter - that is what I personally use for 'insert \n into code' - how about Ctrl+Shift+Enter * OnKeyCtrlE - print statements should be removed, but a nice concept! * hf="c:/python23/Doc/Python23.chm" etc - as you say, "hard wiring still to be virtualized" - please do! :) The block: + else: + hf=r"C:\Programme\Microsoft Visual Studio\MSDN98\98VSa\1033\msdnvs6a.col" + win32help.HtmlHelp(0, hf, win32help.HH_DISPLAY_INDEX, word) + hf= "c:/python23/lib/site-packages/pywin32.chm" + win32help.HtmlHelp(0, hf, win32help.HH_DISPLAY_INDEX, word) doesn't look right as it calls HtmlHelp twice. It would be great to work out how to do that help properly! * re "repairs the fatal call from pywin.mfc.docview.DocTemplate._SetupSharedMenu_" - can you be more specific about the problem you see? I'm not that happy with that patch - a patch that just changes all refernces to _SetupSharedMenu, rather than "injecting" it, would be preferred. I'm happy to see the interest, and hope you can update your patch! Just the .diff file is fine (.patch is my preference, but either is fine :) - no need to .zip, nor to attach the modified files. Cheers, Mark ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1446700&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-12-27 18:53:14
|
Patches item #1623093, was opened at 2006-12-27 19:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=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: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1623093&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-12-26 04:27:55
|
Bugs item #1540243, was opened at 2006-08-14 21:56 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1540243&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: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Doesn't work well as non-admin Initial Comment: win32com does not run very well as non-admin. It tries to write cache files to a Program Files directory (which can be changed, but only on a per-system basis in HKLM) and register classes in HKEY_CLASSES_ROOT, without failing over to HKEY_CURRENT_USER\Classes. ---------------------------------------------------------------------- >Comment By: Michael Hoffman (hoffmanm) Date: 2006-12-26 04:27 Message: Logged In: YES user_id=987664 Originator: YES Since the gencache stuff has changed, I think win32com works a lot better. Not using HKEY_CURRENT_USERS\Classes is still a problem though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1540243&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-12-20 02:07:52
|
Bugs item #1619086, was opened at 2006-12-19 11:07 Message generated for change (Comment added) made by craigch 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: Open 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: Craig (craigch) Date: 2006-12-19 15: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 |
|
From: SourceForge.net <no...@so...> - 2006-12-19 22:06:59
|
Bugs item #1619086, was opened at 2006-12-19 11:07 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=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: Open 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1619086&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
