pywin32-bugs Mailing List for Python for Windows Extensions (Page 107)
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...> - 2004-04-22 08:41:49
|
Bugs item #823401, was opened at 2003-10-14 22:30 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=823401&group_id=78018 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Vassilis Ereliadis (erelv) Assigned to: Nobody/Anonymous (nobody) Summary: active scripting engine doesnt seem to work Initial Comment: It seems that active scripting doesnt work. This is a simple scenario: I install python 2.3.2 and win32all-157. I run the pyscript_rexec.py to register the scripting engine. Everything works fine so far. The problem is when i test the calc.htm example in \python23\lib\site-packages\win32comext\axscript\dem os\client\ie. It doesnt work. No error is reported but pressing any of the calculator's buttons does nothing. In python 2.1.2 and win32all-145, i ve seen that example working. A second scenario concerning ASP page: When i open the following asp page ------------------------------------------------------ <HTML> <SCRIPT Language="Python" RUNAT=Server> for i in range(3,8): Response.Write("<FONT SIZE=%d>Hello World!! <BR>" % i) </SCRIPT> </HTML> ------------------------------------------------------- for the first time, it works fine. If i refresh it or open it for a second time, i get the message: Python ActiveX Scripting Engine error 'ASP 0211' Object out of scope A built-in ASP object has been referenced, which is no longer valid (my pc works on windows 2000 pro SP4, IIS 5.0, IE 6 SP1) ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-22 18:41 Message: Logged In: YES user_id=14198 The ASP problem has been fixed. The IE problem has not, but unfortunately will not be - Python no longer has any kind of "sandbox" we can use. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=823401&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-22 08:40:20
|
Bugs item #787974, was opened at 2003-08-13 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=787974&group_id=78018 Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ian Parker (ianparker) Assigned to: Nobody/Anonymous (nobody) Summary: PyGetCounterInfo() fails on XP Initial Comment: PyGetCounterInfo() in win32pdh needs the same fix as previously made to PyEnumObjectItems(). The return from the call to pPdhGetCounterInfo to obtain the buffer size is PDH_MORE_DATA on XP instead of zero. Are ther any more call with this problem? ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-22 18:40 Message: Logged In: YES user_id=14198 Fixed, thanks! I scanned the file for any others, and this appears to be the last. Checking in win32pdhmodule.cpp; new revision: 1.11; previous revision: 1.10 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=787974&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-22 08:24:03
|
Bugs item #753154, was opened at 2003-06-12 19:34 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=753154&group_id=78018 Category: com Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Andrea Babini (ababini) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak wrapping object having _typelib_guid_ attribute Initial Comment: Problem experimented using win32all build 152, Python 2.2.2. The attached .zip file contains: A) TestServer.tlb that defines the IPippo interface B) CPippo.py that implements IPippo referring the typelib using _com_interfaces and _typelib_guid_ attributes C) PyPippo.py that implements IPippo using _public_method_ attribute D) CTest.py that reproduce the problem using CPippo E) PyTest.py that is the same as CTest.py but use PyPippo and doesn't have the leak F) universal.py as modified by me to reduce the size of the leak. My changes are only a workaround to reduce the leak in my specific use (only one interface for object, no lcid and typelib version support). Moreover I think that with this change the performances are improved as well. The steps to reproduce the problem are: 1. COM registrations 1.1 python regtlb.py TestServer.tlb 1.2 python CPippo.py 1.3 python CTest.py 2. Test to highlight the leak (it use CPippo class) 2.1 python CTest.py ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-22 18:24 Message: Logged In: YES user_id=14198 I meant to mention - I added "pippo" to the standard test suite, including the IDL etc. It currently doesn't do much beyond a simple leak test, but is a great framework for further tests - thanks! ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-04-22 17:49 Message: Logged In: YES user_id=14198 Thanks! I found the underlying memory leaks, and fixed them. Your sample no longer leaks at all, even though I didn't implement the cache in your patch. Note that by using gencache.EnsureModule(), you get the same benefits of the cache (and not even take the hit each time the process starts 0 just once as a .py is generated) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=753154&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-22 07:50:44
|
Bugs item #753154, was opened at 2003-06-12 19:34 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=753154&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrea Babini (ababini) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak wrapping object having _typelib_guid_ attribute Initial Comment: Problem experimented using win32all build 152, Python 2.2.2. The attached .zip file contains: A) TestServer.tlb that defines the IPippo interface B) CPippo.py that implements IPippo referring the typelib using _com_interfaces and _typelib_guid_ attributes C) PyPippo.py that implements IPippo using _public_method_ attribute D) CTest.py that reproduce the problem using CPippo E) PyTest.py that is the same as CTest.py but use PyPippo and doesn't have the leak F) universal.py as modified by me to reduce the size of the leak. My changes are only a workaround to reduce the leak in my specific use (only one interface for object, no lcid and typelib version support). Moreover I think that with this change the performances are improved as well. The steps to reproduce the problem are: 1. COM registrations 1.1 python regtlb.py TestServer.tlb 1.2 python CPippo.py 1.3 python CTest.py 2. Test to highlight the leak (it use CPippo class) 2.1 python CTest.py ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-22 17:49 Message: Logged In: YES user_id=14198 Thanks! I found the underlying memory leaks, and fixed them. Your sample no longer leaks at all, even though I didn't implement the cache in your patch. Note that by using gencache.EnsureModule(), you get the same benefits of the cache (and not even take the hit each time the process starts 0 just once as a .py is generated) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=753154&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-22 04:06:57
|
Bugs item #828466, was opened at 2003-10-23 05:48 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=828466&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Eugene Yakubovich (eyakubovich) Assigned to: Nobody/Anonymous (nobody) Summary: EnumClassesOfCategories fails if 2nd param is None Initial Comment: PyICatInformation.EnumClassesOfCategories fails with E_POINTER if the listIIdRequired parameter is None. Although not documented in MSDN, ICatInformation::EnumClassesOfCategories's rgcatidReq parameter MUST be NULL if cRequired parameter is -1. Looking at PyICatInformation.cpp:82 shows that this parameter is always initialized to a non-NULL value: 81: GUID iidTemp; 82: GUID *pIDsReqd = &iidTemp; ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-22 14:06 Message: Logged In: YES user_id=14198 Fixed in rev 1.5 of PyICatInformation, so will be in the next build. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=828466&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-22 04:06:13
|
Bugs item #841597, was opened at 2003-11-14 05:09 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=841597&group_id=78018 Category: com Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Stephen White (swhite) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] win32com doesn't work with Sun's Java/ActiveX Bridge Initial Comment: Having created an ActiveX/COM object using Sun's Java/ActiveX bridge I found it worked fine in VBA and also using Perl's Win32::OLE - but was disappointed to find it didn't work in Python. >>> import win32com.client >>> o = win32com.client.Dispatch("Simple.Bean") >>> o.Greeting() Traceback (most recent call last): File "<interactive input>", line 1, in ? File "win32com\client\dynamic.py", line 471, in __getattr__ raise pythoncom.com_error, details com_error: (-2147352567, 'Exception occurred.', (0, None, 'java.lang.NullPointerException', None, 0, -2147352567), None) Read/write access to attributes did work, which I found puzzling so I checked the code. It would appear that win32com relies on access to an attribute returning 'ERRORS_BAD_CONTEXT' when it doesn't exist, in which case win32com then tries the equivalent method. Sun's Java/ActiveX bridge isn't returning this error code, so win32com never tries to execute the method. The attached patch causes win32com to operate correctly in this case. I'm not very familiar with COM so I'm not sure if it's Java or win32com at fault here, or if there's a better fix, but this one works for me. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-22 14:05 Message: Logged In: YES user_id=14198 Doh - The error code is in the bug report - DISP_E_EXCEPTION. 'm not comfortable with including that error in the list without more thought. The basic problem is that the patch as it stands could cause simple property references which cause an error to behave very strangely (as we will silently consume the error, and consider it a method!) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-04-07 15:31 Message: Logged In: YES user_id=14198 What error code does Sun/Jave use? I'd prefer to add that error to the list ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=841597&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-22 03:59:52
|
Bugs item #925584, was opened at 2004-03-30 06:15 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=925584&group_id=78018 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Withnail & I (alphasixty) Assigned to: Nobody/Anonymous (nobody) Summary: PythonService.exe Dr Watson Errors Initial Comment: I am using Tim Golden's WMI module (version 0.5, obtained from http://tgolden.sc.sabren.com/python/wmi.html I have several services that I have written using win32all, and they have been running for several weeks. I want to use wmi functions, but I can only run servicename.exe update If I servicename.exe start I get a window that says: Pythonservice.e.exe has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created. Here is the line I added to my service program file: import wmi If I copy all the code from wmi.py and paste it into my service program, no error occurs on startup. It only seems to happen if I import wmi as a module. As soon as I remove "import wmi" from my program the service works again. A Dr. Watson logfile might contain sensitive info about my system, so I cannot really post it here (the computer belongs to my employer). If you need the logfile, I can send it privately. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-22 13:58 Message: Logged In: YES user_id=14198 Have you downloaded the pythonservice update in the file-releases section for build 200? If not, this bug is fixed there. If so, please reopen this bug. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=925584&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-22 01:24:55
|
Bugs item #939727, was opened at 2004-04-21 19:24 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=939727&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: achan (alccmb) Assigned to: Nobody/Anonymous (nobody) Summary: There was an error in the DDE conversation with Pythonwin Initial Comment: There are times when I'm starting Pythonwin, I get this error: "There was an error in the DDE conversation with Pythonwin" After pressing 'ok' button. The debugger loads. What's with this error? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=939727&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-22 00:27:58
|
Bugs item #887212, was opened at 2004-01-30 06:43 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=887212&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Phil Rittenhouse (prittenh) Assigned to: Nobody/Anonymous (nobody) Summary: Exception raised accessing REG_EXPAND_SZ type in registry Initial Comment: I ran into two problems using Makepy and the COM Browser both caused by the same type library registry entry. This entry was of the type REG_EXPAND_SZ instead of the usual REG_SZ. When running the COM Browser and expanding the registered type libraries, I woud get the following exception: File "win32com\client\combrowse.py", line 498, in GetSubList name = win32api.RegQueryValue(subKey, versionStr) pywintypes.error: (13, 'RegQueryValue', 'The data is invalid.') win32ui: Exception in OnNotify() handler When running Makepy, I got the following: File "win32com\client\selecttlb.py", line 122, in EnumTlbs spec.ver_desc = tlbdesc + " (" + version + ")" TypeError: unsupported operand types for +: 'NoneType' and 'str' In both cases I traced the source of the error to a call to win32api.RegQueryValue(). From what I can tell, this function does not handle the REG_EXPAND_SZ type. The documentation for this function, that I found on ActiveState, says that this function should be avoided, and win32api.RegQueryValueEx() should be used instead. So, in combrowse.py I replaced name = win32api.RegQueryValue(subKey, versionStr) with: subSubKey = win32api.RegOpenKey(subKey, versionStr) name = win32api.RegQueryValueEx(subSubKey, '')[0] And in selecttlp.py, EnumKeys() I replaced val = win32api.RegQueryValue(root, item) to: subKey = win32api.RegOpenKey(root, item) val = win32api.RegQueryValueEx(subKey, '')[0] This seems to work, but I am completely new to this API, so I make no guarantees. It looks like there are many other places that use RegQueryValue(), so they may need to be changed aswell. I am running Python 2.2.3, with win32all build 162, on windows XP. The registry entry that caused the problem was for the LDMView ActiveX Control module. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-22 10:27 Message: Logged In: YES user_id=14198 Thanks! The fix I came up with is a little different, but I was able to reproduce the problem, so I'm fairly sure it is fixed. Checking in selecttlb.py; new revision: 1.7; previous revision: 1.6 Checking in combrowse.py; new revision: 1.6; previous revision: 1.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=887212&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-21 23:57:32
|
Bugs item #838881, was opened at 2003-11-09 12:49 Message generated for change (Comment added) made by eplese You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=838881&group_id=78018 Category: win32 Group: None Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Ed Plese (eplese) Assigned to: Nobody/Anonymous (nobody) Summary: win32file.FindFilesW behavior with Unicode Initial Comment: When passing a Unicode string into win32file.FindFilesW, this string is converted to a regular string using I believe the default codepage. This is then converted back to Unicode with the win32 API function MultiByteToWideChar and then passed to the win32 API function FindFirstFileW. Doing this leads to errors like the following: File "checkfiles.py", line 14, in RecursiveDir files = win32file.FindFilesW(searchpath) UnicodeEncodeError: 'ascii' codec can't encode character '\uf1' in position 61: ordinal not in range(128) When passing in Unicode to this function, shouldn't it be preserved exactly without the unnecessary conversions? I have tried first converting the Unicode to a normal string with a number of different code pages. Sometimes that would help, but the error would appear on a different file in the directory structure that contained some other Unicode characters in the filename. The only way I could get this to work without fail was to download the source and modify this function to accept only Unicode strings, and then pass those directly to FindFirstFileW. ---------------------------------------------------------------------- >Comment By: Ed Plese (eplese) Date: 2004-04-21 18:57 Message: Logged In: YES user_id=629838 I was originally having these problems with build 156. Checking the CVS history shows that this was fixed in revision 1.36 of win32file.i on February 28, 2004. Thanks for checking this out. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-04-21 01:56 Message: Logged In: YES user_id=14198 Does this still exist? I just verified that in the current build, FindFilesW does not translate the string and uses the Unicode characters directly. Sorry for the delay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=838881&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-21 17:20:34
|
Bugs item #900551, was opened at 2004-02-19 19:26 Message generated for change (Comment added) made by ericp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=900551&group_id=78018 Category: win32 Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Eric Promislow (ericp) Assigned to: Nobody/Anonymous (nobody) Summary: Build 200 doesn't set registry Modules\py* entries Initial Comment: Visual Python depends on the presence of the pythoncom extensions, and checks for the correct registry entries, based on the version of Python, as an MSI Launch Condition. This is because I use pythoncom as part of the registration process, and it's better to check for its presence in advance than to fall flat on my face in the CustomAction section. I noticed with build 200 that the registry entries HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2. 3\Modules\{pythoncom,Pythonwin,pywintypes} aren't created. If this is deliberate, could I please have them back? ---------------------------------------------------------------------- >Comment By: Eric Promislow (ericp) Date: 2004-04-21 17:20 Message: Logged In: YES user_id=63713 For the record, we discussed this after I posted the problem, and agreed on following the current .pth mechanism. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-04-21 06:43 Message: Logged In: YES user_id=14198 Hi Eric - I think we discussed this via email. The module entries are evil and cause conflicts. Please reopen if you want to discuss further. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=900551&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-21 12:46:24
|
Bugs item #841605, was opened at 2003-11-14 05:24 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=841605&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Duplicate Priority: 9 Submitted By: bob gailer (ramrom) Assigned to: Nobody/Anonymous (nobody) Summary: com->Excel: 'int' object has no attribute 'GetTypeInfo' Initial Comment: win32all Version 154 ------------ CODE --------------- import win32com.client ex = win32com.client.Dispatch("excel.application");ex.Visible = 1 wb = ex.Workbooks.Open('i:\samis\data\graph_base.xls') sheets = ex.Worksheets.Count ex.Worksheets(1).Copy(None, ex.Worksheets(1)) wk2 = ex.Worksheets(sheets + 1) co = wk2.ChartObjects(1) ch = co.Chart ch.ChartType = 4 # xlLine series_range = ex.Range("C25:D27") ch.SeriesCollection().Add(series_range, 2) ------------ ERROR --------------- File "i:\samis\python\super_out.py", line 11 ch.SeriesCollection().Add(series_range, 2) File "<COMObject SeriesCollection>", line 3, in Add File "C:\Python22\lib\site-packages\win32com\client\__init__.py", line 93, in Dispatch return __WrapDispatch(dispatch, userName, resultCLSID, typeinfo, UnicodeToString, clsctx) File "C:\Python22\lib\site-packages\win32com\client\__init__.py", line 41, in __WrapDispatch return dynamic.Dispatch(dispatch, userName, WrapperClass, typeinfo, UnicodeToString=UnicodeToString,clsctx=clsctx) File "C:\Python22\lib\site-packages\win32com\client\dynamic.py", line 90, in Dispatch typeinfo = IDispatch.GetTypeInfo() AttributeError: 'int' object has no attribute 'GetTypeInfo' ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-21 22:46 Message: Logged In: YES user_id=14198 As discussed on the win32 list, I'm really tempted to call this an Excel bug. At the very least, I'm going to close this bug, and track it in the other. A work around should be to replace this line: ch.SeriesCollection().Add(series_range, 2) with: sc = ch.SeriesCollection() sc_hack = win32com.client.dynamic.DumbDispatch(sc) sc_hack.Add(series_range, 2) and adding 'import win32com.client.dynamic' somewhere, should work around the problem by avoiding the typeinfo. Please follow up in bug 938098: http://sourceforge.net/tracker/index.php?func=detail&aid=938098&group_id=78018&atid=551954 ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2004-04-20 05:27 Message: Logged In: YES user_id=587593 I have researched this more. I have posted a new bug 938098 with the new research. I am posting a new bug because I have gone as far as I can and really need help, as my clients are waiting to use the program. ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2003-11-22 07:54 Message: Logged In: YES user_id=587593 I really need help with this one, as I cannot serve my client's needs until it is fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=841605&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-21 06:56:45
|
Bugs item #838881, was opened at 2003-11-10 05:49 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=838881&group_id=78018 Category: win32 Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Ed Plese (eplese) Assigned to: Nobody/Anonymous (nobody) Summary: win32file.FindFilesW behavior with Unicode Initial Comment: When passing a Unicode string into win32file.FindFilesW, this string is converted to a regular string using I believe the default codepage. This is then converted back to Unicode with the win32 API function MultiByteToWideChar and then passed to the win32 API function FindFirstFileW. Doing this leads to errors like the following: File "checkfiles.py", line 14, in RecursiveDir files = win32file.FindFilesW(searchpath) UnicodeEncodeError: 'ascii' codec can't encode character '\uf1' in position 61: ordinal not in range(128) When passing in Unicode to this function, shouldn't it be preserved exactly without the unnecessary conversions? I have tried first converting the Unicode to a normal string with a number of different code pages. Sometimes that would help, but the error would appear on a different file in the directory structure that contained some other Unicode characters in the filename. The only way I could get this to work without fail was to download the source and modify this function to accept only Unicode strings, and then pass those directly to FindFirstFileW. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-21 16:56 Message: Logged In: YES user_id=14198 Does this still exist? I just verified that in the current build, FindFilesW does not translate the string and uses the Unicode characters directly. Sorry for the delay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=838881&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-21 06:43:45
|
Bugs item #900551, was opened at 2004-02-20 06:26 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=900551&group_id=78018 Category: win32 Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Eric Promislow (ericp) Assigned to: Nobody/Anonymous (nobody) Summary: Build 200 doesn't set registry Modules\py* entries Initial Comment: Visual Python depends on the presence of the pythoncom extensions, and checks for the correct registry entries, based on the version of Python, as an MSI Launch Condition. This is because I use pythoncom as part of the registration process, and it's better to check for its presence in advance than to fall flat on my face in the CustomAction section. I noticed with build 200 that the registry entries HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2. 3\Modules\{pythoncom,Pythonwin,pywintypes} aren't created. If this is deliberate, could I please have them back? ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-21 16:43 Message: Logged In: YES user_id=14198 Hi Eric - I think we discussed this via email. The module entries are evil and cause conflicts. Please reopen if you want to discuss further. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=900551&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-21 06:42:26
|
Bugs item #929490, was opened at 2004-04-05 11:30 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=929490&group_id=78018 Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Win2K Priority class definitions missing from win32process Initial Comment: The ABOVE_NORMAL_PRIORITY_CLASS and BELOW_NORMAL_PRIORITY_CLASS flags are missing from win32process, although they are in the documentation. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-21 16:42 Message: Logged In: YES user_id=14198 Thanks - fixed. Checking in win32process.i; new revision: 1.13; previous revision: 1.12 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=929490&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-20 13:43:26
|
Bugs item #938577, was opened at 2004-04-20 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=938577&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Denis (abcdenis) Assigned to: Nobody/Anonymous (nobody) Summary: cant change text background to [X] default Initial Comment: Pythonwin win32all build 163 comes with ActiveState Python 2.3.2 When I go to View/Options/Format/String and change background to (for sample) light green, its looks fine. When I tired seeing light green, I go to options and set backround to default, but this not work! My experience results: to restore backround I must delete registry record with address "HKEY_CURRENT_USER\Software\Python 2.3\Python for Win32\Format\String background" So, I think, there must be another algorithm to save background: 1. remove "<element> background" registry record 2. if background not default, then create "<element> background" registry record. Regards, Denis ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=938577&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-19 19:27:52
|
Bugs item #841605, was opened at 2003-11-13 11:24 Message generated for change (Comment added) made by ramrom You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=841605&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 9 Submitted By: bob gailer (ramrom) Assigned to: Nobody/Anonymous (nobody) >Summary: com->Excel: 'int' object has no attribute 'GetTypeInfo' Initial Comment: win32all Version 154 ------------ CODE --------------- import win32com.client ex = win32com.client.Dispatch("excel.application");ex.Visible = 1 wb = ex.Workbooks.Open('i:\samis\data\graph_base.xls') sheets = ex.Worksheets.Count ex.Worksheets(1).Copy(None, ex.Worksheets(1)) wk2 = ex.Worksheets(sheets + 1) co = wk2.ChartObjects(1) ch = co.Chart ch.ChartType = 4 # xlLine series_range = ex.Range("C25:D27") ch.SeriesCollection().Add(series_range, 2) ------------ ERROR --------------- File "i:\samis\python\super_out.py", line 11 ch.SeriesCollection().Add(series_range, 2) File "<COMObject SeriesCollection>", line 3, in Add File "C:\Python22\lib\site-packages\win32com\client\__init__.py", line 93, in Dispatch return __WrapDispatch(dispatch, userName, resultCLSID, typeinfo, UnicodeToString, clsctx) File "C:\Python22\lib\site-packages\win32com\client\__init__.py", line 41, in __WrapDispatch return dynamic.Dispatch(dispatch, userName, WrapperClass, typeinfo, UnicodeToString=UnicodeToString,clsctx=clsctx) File "C:\Python22\lib\site-packages\win32com\client\dynamic.py", line 90, in Dispatch typeinfo = IDispatch.GetTypeInfo() AttributeError: 'int' object has no attribute 'GetTypeInfo' ---------------------------------------------------------------------- >Comment By: bob gailer (ramrom) Date: 2004-04-19 13:27 Message: Logged In: YES user_id=587593 I have researched this more. I have posted a new bug 938098 with the new research. I am posting a new bug because I have gone as far as I can and really need help, as my clients are waiting to use the program. ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2003-11-21 13:54 Message: Logged In: YES user_id=587593 I really need help with this one, as I cannot serve my client's needs until it is fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=841605&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-19 19:25:29
|
Bugs item #938098, was opened at 2004-04-19 13:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=938098&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 5 Submitted By: bob gailer (ramrom) Assigned to: Nobody/Anonymous (nobody) Summary: InvokeTypes returns int instead of PYIDispatch object Initial Comment: Python program fragment. Assumes excel dispatched as a COM object, with a worksheet with a chart: sc = chart.SeriesCollection() sc.Add(series_range, seriesAddDirection) The last line causes an error. Here's the method code generated for Add by the dispatch module: def Add(self, Source=pythoncom.Missing, Rowcol=2, SeriesLabels=pythoncom.Missing, CategoryLabels=pythoncom.Missing, Replace=pythoncom.Missing): ret = self._oleobj_.InvokeTypes(181, LCID, 1, (9, 0), ((12, 1), (3, 49), (12, 17), (12, 17), (12, 17)),Source, Rowcol, SeriesLabels, CategoryLabels, Replace) if ret is not None: ret = Dispatch(ret, 'Add', '{0002086B-0000-0000-C000-000000000046}', UnicodeToString=0) return ret The call to InvokeTypes returns integer 1 rather than a PyIDispatch object. Originally reported under Bug 841605. Creating new bug since I have researched this in much more detail than before. This is as far as I can go without help. I have clients waiting to use my program as soon as we can fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=938098&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-19 10:14:50
|
Patches item #937779, was opened at 2004-04-19 10:14 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=937779&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andre Reitz (inworks) Assigned to: Nobody/Anonymous (nobody) Summary: ODBC-Metadata Initial Comment: Hi all, please aplly this patch. We use pywin32 to connect ODBC-Databases. Our DB-adapter reads the column-metadata after sending a query. Everything works great except that all column names are in lowercase. The patch deletes only the line which is responsible for that: _strlwr(name); I am looking forward, that somebody applies this patch before nexts release of pywin32. Greetings, Andre' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=937779&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-15 19:52:56
|
Bugs item #935071, was opened at 2004-04-14 11:14 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=935071&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Coombs (jaraco) Assigned to: Nobody/Anonymous (nobody) Summary: testall.py fails with space in install path Initial Comment: When I run testall.py, some of the tests run, but others fail opening the file. It appears to be a bug with the install location and the presence of a space. Below is the output of testall on my machine. After the output below, the program hangs. Note, I have removed all non-standard modules from the test folder. Build is 200 for Python 2.3. C:\Program Files\Python\Lib\site-packages\win32 \test>testall .......................Time zone in effect is Mountain Daylight Time Next timezone change happens at 04/01/00 02:00:00 .............python.exe: can't open file 'C:\Program' python.exe: can't open file 'C:\Program' python.exe: can't open file 'C:\Program' python.exe: can't open file 'C:\Program' python.exe: can't open file 'C:\Program' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=935071&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-08 14:27:15
|
Bugs item #874096, was opened at 2004-01-09 14:56 Message generated for change (Comment added) made by dboreham You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=874096&group_id=78018 Category: com Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: David Boreham (dboreham) Assigned to: Nobody/Anonymous (nobody) Summary: Race condition with genpy.py and stdout Initial Comment: I've been investigating a problem for a client of mine where the symptoms were that a generated python file in the ...\win32com\gen_py directory had become corrupted. It looked mostly ok, but contained one line of text which was not Python. I tracked that string down to another part of the application, completely unrelated. Upon investigation I believe that the cause is this code in genpy.py: def generate(self, file, is_for_demand = 0): if is_for_demand: self.generate_type = GEN_DEMAND_BASE else: self.generate_type = GEN_FULL self.file = file oldOut = sys.stdout sys.stdout = file try: self.do_generate() finally: sys.stdout = oldOut self.file = None self.progress.Finished() It's redirecting stdout for the generated python file. In the application this happens underneath a call to gencache.EnsureModule(). Unfortunately the application is concurrently executing another thread which is also writing to stdout. The result is that the two sets of output are intermingled. I guess that it would be possible to refactor the code in genpy.py such that it outputs to a file rather than to stdout (the file could be stdout for cases where the code is run as a standalone utility). I see the checkin comment for version 1.30 suggests that this is a known problem: >Also started a move to "print >>" for the generation. Thanks. ---------------------------------------------------------------------- >Comment By: David Boreham (dboreham) Date: 2004-04-08 07:27 Message: Logged In: YES user_id=264605 Great ! I'll see about integrating this patch back into the app where we saw this problem. Thanks ! ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-04-07 21:06 Message: Logged In: YES user_id=14198 I "just did it" :) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-04-06 22:26 Message: Logged In: YES user_id=14198 Yes, this could happen :) I'd love patches to address this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=874096&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-08 04:06:09
|
Bugs item #874096, was opened at 2004-01-10 08:56 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=874096&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Boreham (dboreham) Assigned to: Nobody/Anonymous (nobody) Summary: Race condition with genpy.py and stdout Initial Comment: I've been investigating a problem for a client of mine where the symptoms were that a generated python file in the ...\win32com\gen_py directory had become corrupted. It looked mostly ok, but contained one line of text which was not Python. I tracked that string down to another part of the application, completely unrelated. Upon investigation I believe that the cause is this code in genpy.py: def generate(self, file, is_for_demand = 0): if is_for_demand: self.generate_type = GEN_DEMAND_BASE else: self.generate_type = GEN_FULL self.file = file oldOut = sys.stdout sys.stdout = file try: self.do_generate() finally: sys.stdout = oldOut self.file = None self.progress.Finished() It's redirecting stdout for the generated python file. In the application this happens underneath a call to gencache.EnsureModule(). Unfortunately the application is concurrently executing another thread which is also writing to stdout. The result is that the two sets of output are intermingled. I guess that it would be possible to refactor the code in genpy.py such that it outputs to a file rather than to stdout (the file could be stdout for cases where the code is run as a standalone utility). I see the checkin comment for version 1.30 suggests that this is a known problem: >Also started a move to "print >>" for the generation. Thanks. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-08 14:06 Message: Logged In: YES user_id=14198 I "just did it" :) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-04-07 15:26 Message: Logged In: YES user_id=14198 Yes, this could happen :) I'd love patches to address this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=874096&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-07 05:40:26
|
Bugs item #798452, was opened at 2003-09-01 22:02 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=798452&group_id=78018 Category: win32 Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: win32gui_taskbar.py broken in Python 2.3 Initial Comment: The win32gui_taskbar.py demo causes Python 2.3 to unexpectedly terminate, although it works fine in Python 2.2.3. No idea about why... ---------------------------------------------------------------------- >Comment By: Tony Meyer (anadelonbrin) Date: 2004-04-07 17:40 Message: Logged In: YES user_id=552329 Confirmed that this is indeed fixed with build 200. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-04-07 17:35 Message: Logged In: YES user_id=14198 Fixed in the last build I believe ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=798452&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-07 05:35:19
|
Bugs item #798452, was opened at 2003-09-01 20:02 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=798452&group_id=78018 Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: win32gui_taskbar.py broken in Python 2.3 Initial Comment: The win32gui_taskbar.py demo causes Python 2.3 to unexpectedly terminate, although it works fine in Python 2.2.3. No idea about why... ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-07 15:35 Message: Logged In: YES user_id=14198 Fixed in the last build I believe ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=798452&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-04-07 05:34:10
|
Bugs item #799063, was opened at 2003-09-02 20:40 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=799063&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Kirst (mattkirst) Assigned to: Nobody/Anonymous (nobody) Summary: Registering Python COM Server component category crashes Initial Comment: When registering the Python COM Server component category, Python crashes with Dr.Watson. The crash happens when executing the last line in the function: def RegisterPyComCategory(): """ Register the Python COM Server component category. """ regCat = _cat_registrar() regCat.RegisterCategories( [ (CATID_PythonCOMServer, 0x0409, "Python COM Server") ] ) ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-04-07 15:34 Message: Logged In: YES user_id=14198 All fixed now ---------------------------------------------------------------------- Comment By: Eric Promislow (ericp) Date: 2004-01-16 06:35 Message: Logged In: YES user_id=63713 I got occasional crashes when registering a Python COM Server on a clean Win2K system with ActivePython 2.3.2 build 232. When attempting to register a COM server the first time, I would get an access violation reported in PyNode_Future ---------------------------------------------------------------------- Comment By: Stuart Rackham (sjrackham) Date: 2003-09-28 10:49 Message: Logged In: YES user_id=655059 Observed on Win98/XP/2000/NT4. A workaround is to have your installer write the following registry entry *before* registering the server: [HKEY_CLASSES_ROOT\Component Categories\{B3EF80D0-68E2-11D0-A689-00C04FD658FF}] "409"="Python COM Server" ---------------------------------------------------------------------- Comment By: Matthias Kirst (mattkirst) Date: 2003-09-05 16:55 Message: Logged In: YES user_id=397984 Bingo! The installation crashed as well with 154 (NT/XP). Since I experienced my crash with a customized Python/PythonCOM version I did not register the scripting engine -> the crash occured when I registered my first COM component. Since win32all does not unregister the Python COM Server component category when uninstalling you succeed when preinstalling an older version of win32all. ---------------------------------------------------------------------- Comment By: John J Smith (johnjsmith) Date: 2003-09-05 04:47 Message: Logged In: YES user_id=830565 Is this related to bug #784962 (Installation crash in recent win32all's)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=799063&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
