pywin32-bugs Mailing List for Python for Windows Extensions (Page 111)
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...> - 2003-11-17 13:32:43
|
Feature Requests item #843683, was opened at 2003-11-17 13:32 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=843683&group_id=78018 Category: com Group: None Status: Open Priority: 5 Submitted By: Giles Brown (gilesbrown) Assigned to: Nobody/Anonymous (nobody) Summary: Minor Client Speedup Initial Comment: In CDispatch._ApplyTypes_ (win32com.client.dispatch) i get a small (but worthwhile) speed improvement if I replace (during lots of ADO recordset operations): result = self._oleobj_.InvokeTypes(*(dispid, LCID, wFlags, retType, argTypes) + args) With: result = self._oleobj_.InvokeTypes(dispid, LCID, wFlags, retType, argTypes, *args) I think they are functionally equivalent. Sorry I haven't worked out how to create this as a patch. Cheers, Giles ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=843683&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-11-13 18:25:51
|
Bugs item #841607, was opened at 2003-11-13 11: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=841607&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: bob gailer (ramrom) Assigned to: Nobody/Anonymous (nobody) Summary: Attempt to run script fails. Initial Comment: OPen a script. Hit F5. Error: Traceback (most recent call last): File "C:\Python22\lib\site-packages\Pythonwin\pywin\framework\scriptutils.py", line 307, in RunScript debugger.run(codeObject, __main__.__dict__, start_stepping=0) File "C:\Python22\lib\site-packages\Pythonwin\pywin\debugger\__init__.py", line 60, in run _GetCurrentDebugger().run(cmd, globals,locals, start_stepping) File "C:\Python22\lib\site-packages\Pythonwin\pywin\debugger\__init__.py", line 35, in _GetCurrentDebugger _CheckNeedGUI() File "C:\Python22\lib\site-packages\Pythonwin\pywin\debugger\__init__.py", line 21, in _CheckNeedGUI pywin.framework.app.CreateDefaultGUI(dbgpyapp.DebuggerPythonApp) File "C:\Python22\lib\site-packages\Pythonwin\pywin\framework\app.py", line 392, in CreateDefaultGUI appClass().InitInstance() File "C:\Python22\lib\site-packages\Pythonwin\pywin\debugger\dbgpyapp.py", line 33, in InitInstance win32ui.LoadStdProfileSettings(numMRU) win32ui: The profile settings have already been loaded. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=841607&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-11-13 18:24:16
|
Bugs item #841605, was opened at 2003-11-13 11: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=841605&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 5 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' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=841605&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-11-13 18:09:06
|
Bugs item #841597, was opened at 2003-11-13 18: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=841597&group_id=78018 Category: com Group: None Status: Open 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=841597&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-11-11 18:38:50
|
Bugs item #838232, was opened at 2003-11-07 14:16 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=838232&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: SetScrollInfo incorrectly raises exception Initial Comment: I'm using win32all build 163 on Windows XP. I just got an api exception with 0 error code when using win32gui.SetScrollInfo. It looks like the reason for this is that PySetScrollInfo treats the result of the SetScrollInfo api call as a BOOL, with a false result indicating error. My copy of the win32 api documentation states that SetScrollInfo returns the current position of the scroll box. This position happened to be 0 in my case, so PySetScrollInfo raised an exception. Also, I just discovered that win32gui.GetScrollInfo also generates an api error with a 0 error code. Looking at the source, I note that PyGetScrollInfo does not fill in the fMask field before calling GetScrollInfo. My documentation indicates the mask must be initialized to specify which members to retrieve. ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2003-11-11 09:38 Message: Logged In: YES user_id=86307 I'm attaching a diff file to indicate the changes I think are needed. I used the web CVS browser to get the win32gui.i file, so the date of the original is wrong, but it is revision 1.31. The changes included address both this report and report 838065. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2003-11-07 14:25 Message: Logged In: YES user_id=86307 Also concerning win32gui.GetScrollInfo, if it creates an exception because ok is false, it fails to return NULL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=838232&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-11-09 18:50:53
|
Bugs item #838866, was opened at 2003-11-09 12:12 Message generated for change (Settings changed) made by eplese You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=838866&group_id=78018 Category: win32 Group: None >Status: Deleted Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=838866&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-11-09 18:49:07
|
Bugs item #838881, was opened at 2003-11-09 12:49 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=838881&group_id=78018 Category: win32 Group: None Status: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=838881&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-11-09 18:12:54
|
Bugs item #838866, was opened at 2003-11-09 12:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=838866&group_id=78018 Category: win32 Group: None Status: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=838866&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-11-07 23:25:04
|
Bugs item #838232, was opened at 2003-11-07 14:16 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=838232&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: SetScrollInfo incorrectly raises exception Initial Comment: I'm using win32all build 163 on Windows XP. I just got an api exception with 0 error code when using win32gui.SetScrollInfo. It looks like the reason for this is that PySetScrollInfo treats the result of the SetScrollInfo api call as a BOOL, with a false result indicating error. My copy of the win32 api documentation states that SetScrollInfo returns the current position of the scroll box. This position happened to be 0 in my case, so PySetScrollInfo raised an exception. Also, I just discovered that win32gui.GetScrollInfo also generates an api error with a 0 error code. Looking at the source, I note that PyGetScrollInfo does not fill in the fMask field before calling GetScrollInfo. My documentation indicates the mask must be initialized to specify which members to retrieve. ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2003-11-07 14:25 Message: Logged In: YES user_id=86307 Also concerning win32gui.GetScrollInfo, if it creates an exception because ok is false, it fails to return NULL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=838232&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-11-07 23:16:17
|
Bugs item #838232, was opened at 2003-11-07 14: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=838232&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: SetScrollInfo incorrectly raises exception Initial Comment: I'm using win32all build 163 on Windows XP. I just got an api exception with 0 error code when using win32gui.SetScrollInfo. It looks like the reason for this is that PySetScrollInfo treats the result of the SetScrollInfo api call as a BOOL, with a false result indicating error. My copy of the win32 api documentation states that SetScrollInfo returns the current position of the scroll box. This position happened to be 0 in my case, so PySetScrollInfo raised an exception. Also, I just discovered that win32gui.GetScrollInfo also generates an api error with a 0 error code. Looking at the source, I note that PyGetScrollInfo does not fill in the fMask field before calling GetScrollInfo. My documentation indicates the mask must be initialized to specify which members to retrieve. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=838232&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-11-07 18:43:22
|
Bugs item #838065, was opened at 2003-11-07 09: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=838065&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: documentation problems for GetScrollInfo/PySCROLLINFO Initial Comment: The help file for win32all v. 163 gives this as the prototype for win32gui.GetScrollInfo: PySCROLLINFO = GetScrollInfo(nBar, mask ) Looking at the source code, it appears that (as one would expect) the first param is an hwnd and the second is nBar. Also, in the documentation for PySCROLLINFO, the "Comments" section has a paragraph referring to "userob". This does not appear to be relevant to PySCROLLINFO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=838065&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-10-30 23:30:51
|
Bugs item #833280, was opened at 2003-10-30 14:43 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=833280&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Mischo (mischod) Assigned to: Nobody/Anonymous (nobody) Summary: PythonWin.exe crashes after ODBC driver error. Initial Comment: PythonWin.exe crashes after ODBC driver error. Windows Professional XP; Python 2.3.2.1; Win32All-159 for 2.3 Occurs after getting a reported ODBC driver error finding a table name and I then either re-running script or exit Pythonwin. Happens against either Excel and CSV ODBC sources. In the Excel example, the table name error was because the select statement needed to put the table name in quotes because it referenced a multi-tabbed system table with a $. Select * from Payments needed to be Select * from Payments$. import dbi, odbc try: s = odbc.odbc('AdvWorksExcel') cur = s.cursor() cur.execute('select ProductName from Payments') print cur.description for tup in cur.description: print tup[0], print while 1: rec = cur.fetchmany(10) if not rec: break print rec except NameError,e: print 'error ', e, 'undefined' Traceback (most recent call last): File "C:\PROGRA~1\Python\lib\site- packages\Pythonwin\pywin\framework\scriptutils.py", line 310, in RunScript exec codeObject in __main__.__dict__ File "C:\Documents and Settings\DW\Script3.py", line 6, in ? cur.execute('select ProductName from Payments') dbi.program-error: [Microsoft][ODBC Excel Driver] The Microsoft Jet database engine could not find the object 'Payments'. Make sure the object exists and that you spell its name and the path name correctly. in EXEC >>> Exit PythonWin or Re-Run Script again produces: Unhandled exception in Pythonwin.exe (ODBC.PYD): 0xC0000005: Access Violation ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2003-10-30 18:30 Message: Logged In: YES user_id=771074 This is fixed in build 160 and greater. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=833280&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-10-30 19:43:34
|
Bugs item #833280, was opened at 2003-10-30 14: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=833280&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Mischo (mischod) Assigned to: Nobody/Anonymous (nobody) Summary: PythonWin.exe crashes after ODBC driver error. Initial Comment: PythonWin.exe crashes after ODBC driver error. Windows Professional XP; Python 2.3.2.1; Win32All-159 for 2.3 Occurs after getting a reported ODBC driver error finding a table name and I then either re-running script or exit Pythonwin. Happens against either Excel and CSV ODBC sources. In the Excel example, the table name error was because the select statement needed to put the table name in quotes because it referenced a multi-tabbed system table with a $. Select * from Payments needed to be Select * from Payments$. import dbi, odbc try: s = odbc.odbc('AdvWorksExcel') cur = s.cursor() cur.execute('select ProductName from Payments') print cur.description for tup in cur.description: print tup[0], print while 1: rec = cur.fetchmany(10) if not rec: break print rec except NameError,e: print 'error ', e, 'undefined' Traceback (most recent call last): File "C:\PROGRA~1\Python\lib\site- packages\Pythonwin\pywin\framework\scriptutils.py", line 310, in RunScript exec codeObject in __main__.__dict__ File "C:\Documents and Settings\DW\Script3.py", line 6, in ? cur.execute('select ProductName from Payments') dbi.program-error: [Microsoft][ODBC Excel Driver] The Microsoft Jet database engine could not find the object 'Payments'. Make sure the object exists and that you spell its name and the path name correctly. in EXEC >>> Exit PythonWin or Re-Run Script again produces: Unhandled exception in Pythonwin.exe (ODBC.PYD): 0xC0000005: Access Violation ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=833280&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-10-25 05:56:33
|
Bugs item #721634, was opened at 2003-04-15 17:07 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=721634&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Matt R Hall (mhcomputing) Assigned to: Nobody/Anonymous (nobody) Summary: Defective LFN Handling in Version 1.53 Installer Initial Comment: Summary: Using the win32all-153.exe installer on Windows XP SP1 to install the extensions when the base version of Python resides in a directory path containing spaces results in an Access Violation. Testing Methodology / Error Reproduction: The installer crashed while attempting to register some of the COM components it installs when I attempted to use the installer to add the Win32 components when Python was installed into "C:\Program Files\python23" but functioned perfectly when Python was installed in "C:\python23". Possible Cause: I have observed that various Windows installer utilites perform improper conversion between LFN and non-LFN versions of file and path names used during installation. Perhaps a defective filename string causes the COM component registration procedures to fail. I would first attempt installing patches and updates for the installer generation utility to see if the errors in its LFN handling improve. It can with a high surety be stated that said upgrade would likely result in a resolution of the issue. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-10-25 15:56 Message: Logged In: YES user_id=14198 I explicitly tested the win32all I am preparing to release in this scenario, and it works. It is likely the bug has since been fixed. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=721634&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-10-24 12:11:59
|
Bugs item #829513, was opened at 2003-10-24 10:48 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=829513&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhard König (rkoenigts) Assigned to: Nobody/Anonymous (nobody) Summary: Word 10.0 CentimetersToPoints crashes Initial Comment: I'm using Python 2.3.1 with win32all-157 and have used makepy for the Word 10.0 object library. I get: Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import win32com.client >>> app = win32com.client.Dispatch("Word.Application") >>> app.CentimetersToPoints(3.) Traceback (most recent call last): File "<stdin>", line 1, in ? File "00020905-0000-0000-C000-000000000046x0x8x2.py", line 16324, in CentimetersToPoints return self._oleobj_.InvokeTypes(371, LCID, 1, (4, 0), ((4, 1),),Centimeters) pywintypes.com_error: (-2147467259, 'Unbekannter Fehler', None, None) >>> CentimetersToPoints is a method of Application, so, the invoation should be ok? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=829513&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-10-23 20:42:06
|
Patches item #797087, was opened at 2003-08-29 13:39 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=797087&group_id=78018 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: LsaStorePrivateData, LsaRegisterPolicyChangeNotification Initial Comment: Patch includes inverse functions also LsaRetrievePrivateDate, LsaUnregisterPolicyChangeNotification ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-10-23 10:58 Message: Logged In: YES user_id=14198 All done I think! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=797087&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-10-23 11:58:19
|
Patches item #776836, was opened at 2003-07-24 19:40 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=776836&group_id=78018 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Marc ENGEL (marcengel) Assigned to: Nobody/Anonymous (nobody) Summary: genpy : _NewEnum for dynamic collections Initial Comment: In a previous thread on comp.lang.python a request was made to have _NewEnum called for each for blocks and not only once and then cached in the python proxy class generated by genpy: http://groups.google.com/groups?hl=fr&lr=&ie=UTF- 8&oe=UTF-8&threadm=8ecta7%24nn5%241% 40nnrp1.deja.com&rnum=1&prev=/groups%3Fhl%3Dfr% 26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm% 3D8ecta7%2524nn5%25241%2540nnrp1.deja.com Indeed the _NewEnum normally gives an iterator that iterates on a copy of the collection data. This is the desired behaviour when iterating on a for block but next time if the collection is updated, it is desired to iterate on the latest copy so we need to get a new iterator. I made a change in genpy to create the __iter__ method that is called each time an iterator is requested before the __getitem__ is called. I also added in win32com.client.util the WrapIter function with its associated class. It seems to work well for my collection. Hope it may help someone. The modified files are attached ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-10-23 11:24 Message: Logged In: YES user_id=14198 The next win32all will have much better __iter__ support, but done slightly differently than your patch. Please test the semantics out when the next version is released, and open a bug if there is still an issue. Thanks!. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=776836&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-10-23 03:21:46
|
Bugs item #721636, was opened at 2003-04-15 17:10 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=721636&group_id=78018 Category: pythonwin Group: None Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Matt R Hall (mhcomputing) Assigned to: Nobody/Anonymous (nobody) Summary: Naming Convention Inconsistent for Installation Log File Initial Comment: Summary: A minor typographical / naming convention error removal of the Win32 extensions. Problem: The installer mistakenly copies the installation log into Python23\Lib\site-packages\W32INST.LOG instead of INSTALL.LOG which causes it to fail when attempting to uninstall the Win32 extensions. Potential Fix: Either the location of the install log or the call to the uninstaller placed in the registry should be modified to correct this, or potentially both. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-10-23 12:37 Message: Logged In: YES user_id=14198 I can't repro this. You are correct about the filename, but my testing shows that the uninstall key for win32all does point correctly to the W32INST.LOG file, that this log file contains the correct entries, and that uninstall works correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=721636&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-10-23 02:47:47
|
Patches item #777793, was opened at 2003-07-26 06:41 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=777793&group_id=78018 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jason Petrone (jpetrone) Assigned to: Nobody/Anonymous (nobody) Summary: GetLongPathName() Initial Comment: Implementation of the GetLongPathName function. Converts 8.3 pathnames into the longer version. See http://msdn.microsoft.com/library/en-us/fileio/base/getlongpathname.asp ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-10-23 11:20 Message: Logged In: YES user_id=14198 I've checked something like this in :) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-07-29 16:24 Message: Logged In: YES user_id=14198 This doesn't work on Windows NT or 95. I have already dropped support for 95, and I think it is about time to drop NT support too - so I will add this later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=777793&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-10-23 01:53:10
|
Patches item #725608, was opened at 2003-04-22 21:58 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=725608&group_id=78018 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Marc ENGEL (marcengel) Assigned to: Nobody/Anonymous (nobody) Summary: Modification made to have enum working under .NET Initial Comment: In order to get enum working with .NET wrapped enum, I had to modify the code of __getitem__ from class CDispatch in dynamic.py. Indeed the "for" loop tries to access all index until it gets an IndexError but when trying to access an non-existent index under .NET, I got this error from mscorlib: (-2147352567, "Une exception s'est produite.", (0, 'mscorlib', "L'index \xe9tait hors limites. Il ne doit pas \xeatre n\xe9gatif et doit \xeatre inf\xe9rieur \xe0 la taille de la collection.\r\nNom du param\xe8tre\xa0: index", None, 0, -2146233086), None) The error message translated is: "index out of bounds. It must not be negative or less than the collection size. Parameter name: index" In order to get the for loop working, I modified the code to raise an IndexError and it works. Hope it will help ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-10-23 11:25 Message: Logged In: YES user_id=14198 The next win32all will have much better __iter__ support, but done slightly differently than your patch. Please test the semantics out when the next version is released, and open a bug if there is still an issue. Thanks!. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=725608&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-10-22 19:48:19
|
Bugs item #828466, was opened at 2003-10-22 14:48 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=828466&group_id=78018 Category: com Group: None Status: Open Resolution: None 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; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=828466&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-10-22 11:30:07
|
Bugs item #828151, was opened at 2003-10-22 13:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=828151&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Johan Fredrik Öhman (johanfo) Assigned to: Nobody/Anonymous (nobody) Summary: win32pdh.AddCounter changes comma symbol Initial Comment: This bug caused me some major headache. On some machines (not all) the win32pdh.AddCounter(base, path) causes some trouble with the Locale so that the decimal is changed from "." to "," This has to be a bug? BTW What is the easiste way to check what version number of your win32 extentions I am running? print "wgetCpu1 (0.3):", float(0.3) counter = win32pdh.AddCounter(base, path) print "wgetCpu2 (0.3):", float(0.3) ============================== wgetCpu1 (0.3): 0.3 wgetCpu2 (0.3): 0,3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=828151&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-10-20 03:16:43
|
Patches item #812181, was opened at 2003-09-25 13:26 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=812181&group_id=78018 Category: None Group: None Status: Open Resolution: Out of Date Priority: 5 Submitted By: Roger Upole (rupole) >Assigned to: Roger Upole (rupole) Summary: EnumResourceTypes, EnumResourceLanguages Initial Comment: Unicode versions ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-10-19 09:49 Message: Logged In: YES user_id=14198 Can you please regenerate this patch (or just check it in!) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=812181&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-10-20 01:19:11
|
Patches item #825294, was opened at 2003-10-17 15:05 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=825294&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) >Assigned to: Roger Upole (rupole) Summary: StgOpenStorageEx Initial Comment: Opens extended property sets for normal files (StgOpenStorage only accesses properties for compound object documents - Microsoft binder files, *.obd). Requires Win2k or higher and NTFS. Files changed: PyStorage.cpp - added StgOpenStorageEx storagecon.py - add constants needed by above PythonCOM.cpp - added FMTID's PythonCOM.h - add forward declaration of PyCom_PyObjectFromSTATPROPSETSTG Register.cpp - add IEnumSTATPROPSETSTG PyComHelpers.cpp - add PyCom_PyObjectAsSTGOPTIONS, move PyCom_PyObjectFromSTATPROPSETSTG here (renamed) PyIEnumSTATPROPSETSTG.cpp - new PyIEnumSTATPROPSETSTG.h -new PyIPropertyStorage.cpp - move conversion of STATPROPSETSTG to PyComHelpers ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=825294&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-10-19 11:49:21
|
Patches item #808465, was opened at 2003-09-18 20:21 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=808465&group_id=78018 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Fraser (davidfraser) Assigned to: Nobody/Anonymous (nobody) Summary: Fix PyTime.Format Initial Comment: currently PyTime.Format does not return proper values for day of week and day of year. This is because these are not set in the tm struct that is given to _tcsftime This patch fixes that by calling mktime to convert to a time_t representation, and localtime to convert it back. This is done because although day of week is available in SYSTEMTIME as st.wDayOfWeek, day of year is not available and it would be fairly complex to calculate (I don't know another system function that will do this). In addition, I increased the buffer size for the Format for 256 (I was getting blank strings returned when testing long format strings - see patch 808464 which contains a test for PyTime.Format). ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-10-19 09:36 Message: Logged In: YES user_id=14198 Thanks! Checking in PyTime.cpp; new revision: 1.8; previous revision: 1.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=808465&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
