pywin32-bugs Mailing List for Python for Windows Extensions (Page 77)
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...> - 2006-02-27 12:07:22
|
Bugs item #1208551, was opened at 2005-05-26 01:47 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1208551&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: PJ Tremblay (piairjooles) Assigned to: Nobody/Anonymous (nobody) Summary: pywin build 204 fails to build in --debug Initial Comment: Host information: - Windows XP Pro 2002 SP1 - MSVC7.1 (.NET 2003) - Windows Server 2003 SP1 Platform SDK (latest available on MSDN) - Python 2.4.1 official release installed. - Python 2.4.1 debug version, locally built, installed. running the following: unzip -U pywin32-204.zip cd pywin32-204 python setup.py -q build --debug I get the following error, then the build aborts. PyComHelpers.cpp c:\dev\pywin32-204\com\win32com\src\PyComHelpers.cpp(334) : error C2039: 'pwcsTemplateFile' : is not a member of 'tagSTGOPTIONS' C:\Program Files\Microsoft Platform SDK\Include\ObjBase.h(913) : see declaration of 'tagSTGOPTIONS' c:\dev\pywin32-204\com\win32com\src\PyComHelpers.cpp(340) : error C2039: 'pwcsTemplateFile' : is not a member of 'tagSTGOPTIONS' C:\Program Files\Microsoft Platform SDK\Include\ObjBase.h(913) : see declaration of 'tagSTGOPTIONS' error: command 'C:\Tools\MSVCNET.2003\Vc7\bin\cl.exe' failed with exit status 2 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-02-27 23:07 Message: Logged In: YES user_id=14198 Please reopen if this is still a problem. Thanks ---------------------------------------------------------------------- Comment By: PJ Tremblay (piairjooles) Date: 2005-05-26 03:02 Message: Logged In: YES user_id=1285236 Note that cvs checkout as of today works fine in the case where the Platform SDK is not installed. This was probably the same problem as reported in bug #1203701. Originally submitted problem exists in cvs, though, when Plaform SDK is installed. ---------------------------------------------------------------------- Comment By: PJ Tremblay (piairjooles) Date: 2005-05-26 02:33 Message: Logged In: YES user_id=1285236 build also fails when Platform SDK is not installed (registry key removed): C:\Tools\MSVCNET.2003\Vc7\bin\cl.exe /c /nologo /Od /MDd /W3 /GX /Z7 /D_DEBUG -DDISTUTILS_BUILD -Icom/win32com/src/include -Iwin32/src -Ic:\Tools\Python\include -Ic:\Tools\Python\PC /Tpc:\dev\pywin32-204\com\win32comext\directsound\src\PyDS BCAPS.cpp /Fobuild\temp.win32-2.4\Debug\com\win32comext\directsound\src\PyDSBCAP S.obj /YXdirectsound_pch.h /Fpbuild\temp.win32-2.4\Debug\directsound.pch PyDSBCAPS.cpp c:\dev\pywin32-204\com\win32comext\directsound\src\PyDSBCAPS.cpp(7) : fatal error C1083: Cannot open include file: 'directsound_pch.h': No such file or directory The corresponding build log is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1208551&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-27 12:06:26
|
Bugs item #1203701, was opened at 2005-05-18 01:47 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1203701&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George van den Driessche (gbmvdd) Assigned to: Nobody/Anonymous (nobody) Summary: DirectSound-related files missing from source distribution Initial Comment: A handful of files are missing from com/win32comext/directsound/src directory in the zipped source distribution of version 2.04. They're available via CVS though. I've attached them here so that other people can fetch them easily, and as an easy way for whoever wants to fix this to determine exactly which files are missing. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-02-27 23:06 Message: Logged In: YES user_id=14198 Should be fixed - please re-open if not! ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-05-19 10:10 Message: Logged In: YES user_id=14198 Thanks - this has already been fixed, so the next build will include them. I'll leave this open until I make a new release so people can still find the files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1203701&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-27 12:03:07
|
Bugs item #1243330, was opened at 2005-07-23 07:09 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1243330&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Arioch (thomasjeffrey) Assigned to: Nobody/Anonymous (nobody) Summary: Cant find an installed platform SDK Initial Comment: I'm trying to install the pywin32 extension and keep getting the following error whenever I try to do it " warning-can cant find all and installed form platform SDK error: Python was built with version 6 of Visual Studio, and extensions need to be built with the same version of the compiler, but but it isn't installed." I successfully installed the platform SDK for Microsoft and tried reinstalling the extension I'm still getting the same error. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-02-27 23:03 Message: Logged In: YES user_id=14198 No word from reporter, and works for everyone else ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-07-27 08:48 Message: Logged In: YES user_id=14198 You need both a compiler (VC6 for Python 2.3 and earlier, VC7 for later) and the platform SDK to build these extensions from source-code. However, it isn't clear that you actually need to build from source code - is there a reason you can't use the pre-built binaries? ---------------------------------------------------------------------- Comment By: Arioch (thomasjeffrey) Date: 2005-07-27 01:54 Message: Logged In: YES user_id=1317225 Does this mean actually have to have Microsoft Visual Studio 6 installed? I just installed the Microsoft software development kit available online, as I assumed that's what the prerequisites were. if you are saying they actually need visual C. version 6 and I will go and see if I can locate it thanks for your assistance so far ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-07-25 08:21 Message: Logged In: YES user_id=14198 This error sounds like it is MSVC6 itself that can not be located. If you recently installed it, you must start the MSVC6 dev environment before it will be found by distutils. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1243330&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-27 12:01:31
|
Bugs item #1258840, was opened at 2005-08-14 17:18 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1258840&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Frank Millman (frankmillman) Assigned to: Nobody/Anonymous (nobody) Summary: odbc - select 'bit' type returns str, not int Initial Comment: I use odbc to connect to MS SQL Server. I have just started using the 'bit' datatype, which stores an integer value of 1 or 0. If I execute a SELECT which inludes a 'bit' column, the value is returned correctly, but it is returned as a str ('1' or '0') instead of an int. It is easy to convert the result to an int, but it would be nice if odbc returned an int in the first place. Thanks Frank Millman ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-02-27 23:01 Message: Logged In: YES user_id=14198 Checking in src/odbc.cpp; new revision: 1.15; previous revision: 1.14 Checking in test/test_odbc.py; new revision: 1.2; previous revision: 1.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1258840&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-27 11:07:35
|
Bugs item #1348618, was opened at 2005-11-05 07:28 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1348618&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: IndentationError Initial Comment: latest build 205 / py2.4: occasional error message in interactive window: [Dbg]>>> Traceback (most recent call last): File "C:\Python24\Lib\site-packages\pythonwin\pywin\framework\editor\color\coloreditor.py", line 51, in OnInitialUpdate SyntEditViewParent.OnInitialUpdate(self) File "C:\Python24\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 210, in OnInitialUpdate self.OnWinIniChange(None) File "C:\Python24\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 223, in OnWinIniChange self.DoConfigChange() File "C:\Python24\Lib\site-packages\pythonwin\pywin\framework\editor\color\coloreditor.py", line 162, in DoConfigChange ext.set_indentation_params(1) File "C:\Python24\Lib\site-packages\pythonwin\pywin\idle\AutoIndent.py", line 140, in set_indentation_params i = self.guess_indent() File "C:\Python24\Lib\site-packages\pythonwin\pywin\idle\AutoIndent.py", line 473, in guess_indent opener, indented = IndentSearcher(self.text, self.tabwidth).run() File "C:\Python24\Lib\site-packages\pythonwin\pywin\idle\AutoIndent.py", line 546, in run _tokenize.tokenize(self.readline, self.tokeneater) File "C:\Python24\lib\tokenize.py", line 153, in tokenize tokenize_loop(readline, tokeneater) File "C:\Python24\lib\tokenize.py", line 159, in tokenize_loop for token_info in generate_tokens(readline): File "C:\Python24\lib\tokenize.py", line 229, in generate_tokens raise IndentationError( IndentationError: unindent does not match any outer indentation level win32ui: OnInitialUpdate() virtual handler (<bound method SyntEditView.OnInitialUpdate of <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x00EE57D8>>) raised an exception Traceback (most recent call last): File "C:\Python24\Lib\site-packages\pythonwin\pywin\framework\editor\color\coloreditor.py", line 51, in OnInitialUpdate SyntEditViewParent.OnInitialUpdate(self) File "C:\Python24\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 210, in OnInitialUpdate self.OnWinIniChange(None) File "C:\Python24\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 223, in OnWinIniChange self.DoConfigChange() File "C:\Python24\Lib\site-packages\pythonwin\pywin\framework\editor\color\coloreditor.py", line 162, in DoConfigChange ext.set_indentation_params(1) File "C:\Python24\Lib\site-packages\pythonwin\pywin\idle\AutoIndent.py", line 140, in set_indentation_params i = self.guess_indent() File "C:\Python24\Lib\site-packages\pythonwin\pywin\idle\AutoIndent.py", line 473, in guess_indent opener, indented = IndentSearcher(self.text, self.tabwidth).run() File "C:\Python24\Lib\site-packages\pythonwin\pywin\idle\AutoIndent.py", line 546, in run _tokenize.tokenize(self.readline, self.tokeneater) File "C:\Python24\lib\tokenize.py", line 153, in tokenize tokenize_loop(readline, tokeneater) File "C:\Python24\lib\tokenize.py", line 159, in tokenize_loop for token_info in generate_tokens(readline): File "C:\Python24\lib\tokenize.py", line 229, in generate_tokens raise IndentationError( IndentationError: unindent does not match any outer indentation level win32ui: OnInitialUpdate() virtual handler (<bound method SyntEditView.OnInitialUpdate of <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x00EE59E0>>) raised an exception [Dbg]>>> ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-02-27 22:07 Message: Logged In: YES user_id=14198 Checking in AutoIndent.py; new revision: 1.2; previous revision: 1.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1348618&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-27 10:53:29
|
Bugs item #1376001, was opened at 2005-12-08 18:26 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1376001&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None >Status: Closed >Resolution: Duplicate Priority: 8 Submitted By: O.R.Senthil Kumaran (orsenthil) Assigned to: Nobody/Anonymous (nobody) Summary: Build 205 pythonwin.exe crashes on Win2k3 Initial Comment: As soon the installation is completed on Windows 2003 Operating System.Starting the pythonwin IDE,the pythonwin32.exe crashes with the message: Pythonwin:Pythonwin.exe - Application Error The instruction of "0x00c25fa4" referenced memory at "0x00c25fa4". The Memory could not be written. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-02-27 21:53 Message: Logged In: YES user_id=14198 I believe this is a dupe of "[ 1414160 ] DDE sets off DEP (in demos and pythonwin too)" - which I believe has been fixed so should be in build 208 ---------------------------------------------------------------------- Comment By: Morena Chris Matthews (mcvgmatthews) Date: 2005-12-21 18:44 Message: Logged In: YES user_id=1408439 It is the Data Execution Prevention (DEP)that cause the crash. See "How can I tell if DEP is available on my computer?" below. I selected "DEP for all programs and services except those I select" and then ticked Pythonwin. For good measure I ticked Windows Installer, and reinstalled Python 2.3.5 + Pythonwin 205, Python 2.4.2 + Pythonwin 205. I deleted the old Pythonwin entries and added the newly installed ones. And Voila! Pythonwin works again. The one help I found was: Data Execution Prevention (DEP) helps prevent damage from viruses and other security threats that attack by running (executing) malicious code from memory locations that only Windows and other programs should use. This type of threat causes damage by taking over one or more memory locations in use by a program. Then it spreads and harms other programs, files, and even your e-mail contacts. Unlike a firewall or antivirus program, DEP does not help prevent harmful programs from being installed on your computer. Instead, it monitors your programs to determine if they use system memory safely. To do this, DEP software works alone or with compatible microprocessors to mark some memory locations as "non-executable." If a program tries to run codeâmalicious or notâfrom a protected location, DEP closes the program and notifies you. DEP can take advantage of software and hardware support. To use DEP, your computer must be running Microsoft Windows XP with Service Pack 2 (SP2), Microsoft Windows Server 2003 with Service Pack 1 (SP1), or an x64-based version of a Windows Server 2003 or Windows XP operating system. DEP software alone helps protect against certain types of malicious code attacks but to take full advantage of the protection that DEP can offer, your processor must support "execution protection." This is a hardware-based technology designed to mark memory locations as non-executable. If your processor does not support hardware-based DEP, it's a good idea to upgrade to a processor that offers execution protection features. Is it safe to run a program again if DEP has closed it? Yes, but only if you leave DEP turned on for that program. Windows can continue to detect attempts to execute code from protected memory locations and help prevent attacks. In cases where a program does not run correctly with DEP turned on, you can reduce security risks by getting a DEP-compatible version of the program from the software publisher. For more information about what to do after DEP closes a program, click Related Topics. How can I tell if DEP is available on my computer? 1. To open System Properties, click Start, click Control Panel, and then double-click System. 2. Click the Advanced tab and, under Performance, click Settings. 3. Click the Data Execution Prevention tab. Note ⢠By default, DEP is only turned on for essential Windows operating system programs and services. To help protect more programs with DEP, select Turn on DEP for all programs and services except those I select. ---------------------------------------------------------------------- Comment By: Morena Chris Matthews (mcvgmatthews) Date: 2005-12-20 18:18 Message: Logged In: YES user_id=1408439 Not sure if this may help. Some crash information. python 2.4.2 Faulting application Pythonwin.exe, version 2.4.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00ac1514. Running it again crash consistently at: Faulting application Pythonwin.exe, version 2.4.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00ab816c. I run: Microsoft(R) Windows(R) Server 2003, Standard Edition 5.2.3790 Service Pack 1 Build 3790 and the following MFC's were loaded: version 6.6.8063.0 <Data> <Name><![CDATA[mfc42]]> <Version><![CDATA[6.06.8063.0]]> <Size><![CDATA[1.11 MB (1,160,704 bytes)]]> <File_Date><![CDATA[2005/11/16 09:52 AM]]> <Manufacturer><![CDATA[Microsoft Corporation]]> <Path><![CDATA[c:\windows\system32\mfc42.dll]]> version 6.6.8063.0 <Data> <Name><![CDATA[mfc42u]]> <Version><![CDATA[6.06.8063.0]]> <Size><![CDATA[1.11 MB (1,163,776 bytes)]]> <File_Date><![CDATA[2005/11/16 09:52 AM]]> <Manufacturer><![CDATA[Microsoft Corporation]]> <Path><![CDATA[c:\windows\system32\mfc42u.dll]]> version 7.10.3077.0 <Data> <Name><![CDATA[mfc71]]> <Version><![CDATA[7.10.3077.0]]> <Size><![CDATA[1.01 MB (1,060,864 bytes)]]> <File_Date><![CDATA[2003/03/19 07:19 AM]]> <Manufacturer><![CDATA[Microsoft Corporation]]> <Path><![CDATA[c:\windows\system32\mfc71.dll]]> version 7.10.3077.0 <Data> <Name><![CDATA[mfc71enu]]> <Version><![CDATA[7.10.3077.0]]> <Size><![CDATA[56.00 KB (57,344 bytes)]]> <File_Date><![CDATA[2003/03/19 06:44 AM]]> <Manufacturer><![CDATA[Microsoft Corporation]]> <Path><![CDATA[c:\windows\system32\mfc71enu.dll]]> 00AB8166 add byte ptr [eax],al 00AB8168 or al,byte ptr [eax] 00AB816A add byte ptr [eax],al 00AB816C pop eax 00AB816D push 0AB8118h 00AB8172 push eax 00AB8173 push 1E504C10h 00AB8178 ret Stack: 00ab816c() user32.dll!77387050() user32.dll!77387dc3() user32.dll!77387101() user32.dll!7738e3f0() user32.dll!7739c3b7() user32.dll!7739c484() user32.dll!7739c43a() user32.dll!7739c73c() user32.dll!7738e406() > MFC71.dll!AfxInternalPumpMessage() Line 188 C++ MFC71.dll!CWinThread::Run() Line 637 + 0x7 C++ win32ui.pyd!1e2b62a7() Pythonwin.exe!004015cc() MFC71.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00142545, int nCmdShow=10) Line 49 + 0x7 C++ Pythonwin.exe!004019f1() kernel32.dll!77e523cd() Last source code window: AfxInternalPumpMessage(void) file thrdcore.cpp line 181-189 181: // process this message 182: 183: if (pState->m_msgCur.message != WM_KICKIDLE && !AfxPreTranslateMessage(&(pState->m_msgCur))) 7C169054 cmp dword ptr [edi+34h],36Ah 7C16905B je AfxInternalPumpMessage+3Eh (7C169076h) 7C16905D push esi 7C16905E call AfxPreTranslateMessage (7C169121h) 7C169063 test eax,eax 7C169065 pop ecx 7C169066 jne AfxInternalPumpMessage+3Eh (7C169076h) 184: { 185: ::TranslateMessage(&(pState->m_msgCur)); 7C169068 push esi 7C169069 call dword ptr [__imp__TranslateMessage@4 (7C141728h)] 186: ::DispatchMessage(&(pState->m_msgCur)); 7C16906F push esi 7C169070 call dword ptr [__imp__DispatchMessageA@4 (7C14166Ch)] 187: } 188: return TRUE; >>Instruction cursor>>7C169076 xor eax,eax 7C169078 inc eax 7C169079 pop edi 7C16907A pop esi 189: } 7C16907B ret Registers: EAX = 00000000 EBX = 773E20E0 ECX = 000080A2 EDX = 0014B678 ESI = 0012FCF8 EDI = 7FFDF6CC EIP = 00AB816C ESP = 0012FCD4 EBP = 0012FD04 EFL = 00010246 ---------------------------------------------------------------------- Comment By: Morena Chris Matthews (mcvgmatthews) Date: 2005-12-20 03:09 Message: Logged In: YES user_id=1408439 I also get the error on Win2003 Server. I upgraded to 205, because of a __setitem__ problem of the COMObject. Thereafter I have been experiencing the problem. Now the strange thing is that it crashes regardless of the python and Pythonwin version (I have installed and re-installed and booted, etc.). I also deinstalled my python 2.4. python 2.3.5 build 205 Faulting application Pythonwin.exe, version 2.3.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00bfdb04. python 2.3.5 build 204 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c1db04. Downgrade to: python 2.3 build 203 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c36f0c. python 2.3 build 204 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c36f0c. python 2.3 build 202 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c36f0c. Upgrade to: python 2.3.5 build 202 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c68d4c. Upgrade to: python 2.4.1 build 205 Faulting application Pythonwin.exe, version 2.4.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00ac1aa4. Upgrade to: python 2.4.2 build 205 Faulting application Pythonwin.exe, version 2.4.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00aecefc. Thereafter it crashed at: Faulting application Pythonwin.exe, version 2.4.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00baebac. Shout if I can provide more info. Thanks ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2005-12-08 22:14 Message: Logged In: YES user_id=942711 Am sorry,Mark. -Python 2.4 Build 205. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-12-08 19:22 Message: Logged In: YES user_id=14198 What Python version? ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2005-12-08 18:27 Message: Logged In: YES user_id=942711 Please let me know if I need to provide more debugging information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1376001&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-27 10:51:09
|
Bugs item #1408484, was opened at 2006-01-18 07:54 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1408484&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: v1.0 (example) >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Michael Kleehammer (mkleehammer) Assigned to: Nobody/Anonymous (nobody) Summary: Increment reference to OVERLAPPED Initial Comment: It would be helpful if the reference count of OVERLAPPED objects was incremented by each overlapped I/O function that "posts" the object to the OS. I'm using I/O completion ports with sockes, and if the OVERLAPPED object is not stored somewhere, it is deallocated even after calling WSASend or WSARecv. (This is my assumption based on an error message stating the OVERLAPPED was deallocated.) In the WSAxxx function cases, it makes sense to approach this as if the OVERLAPPED were "referenced" by the operating system. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-02-27 21:51 Message: Logged In: YES user_id=14198 I'm afraid I can't do this without making pywin32 unable to interact with a completion-port implemented in (say) C++, without leaking. If you can point me at places where I could flag this in the documentation I would appreciate it. I do agree they should be hashable (which I will get to when I get a few minutes) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1408484&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-27 10:47:17
|
Bugs item #1408486, was opened at 2006-01-18 07:57 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1408486&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: v1.0 (example) >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Kleehammer (mkleehammer) Assigned to: Nobody/Anonymous (nobody) Summary: WSARecv exception states the error is from "WSASend" Initial Comment: The WSARecv wrapper contains the following line: PyWin_SetAPIError("WSASend", rc); This shoud say WSARecv. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-02-27 21:47 Message: Logged In: YES user_id=14198 Fixed - thanks! Checking in win32file.i; new revision: 1.52; previous revision: 1.51 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1408486&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-27 10:20:54
|
Bugs item #978096, was opened at 2004-06-23 19:54 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=978096&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: George Tegos (gtegos) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with nested dispatches in build 201 Initial Comment: We have an application which exposes an automation object Application. One member of Application is Zip which is another automation object which has a property Recursive of type BOOL. In a Python script we have: Application.Zip.Recursive = 1 With build 201 we get a COM error saying that we have a wrong number of parameters. The same was working fine with build 200 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-02-27 21:20 Message: Logged In: YES user_id=14198 It appears you forgot to attach the .odl file - I did try to reproduce it here, but got stuck. I applied the following patch to the pywin32 distribution: Index: com/TestSources/PyCOMTest/PyCOMTest.idl =================================================================== RCS file: /cvsroot/pywin32/pywin32/com/TestSources/PyCOMTest/PyCOMTest.idl,v retrieving revision 1.12 diff -u -r1.12 PyCOMTest.idl --- com/TestSources/PyCOMTest/PyCOMTest.idl 13 Feb 2006 01:23:49 -0000 1.12 +++ com/TestSources/PyCOMTest/PyCOMTest.idl 27 Feb 2006 10:11:06 -0000 @@ -225,6 +225,7 @@ [propput] HRESULT IntProp([in] int val); [propget] HRESULT CurrencyProp([out, retval] CY* retval); [propput] HRESULT CurrencyProp([in] CY val); + BOOL BoolProp; }; // Define a new class to test how Python handles derived interfaces! (with a few different variations) but MSVC6 fails to compile the .idl file. Would it be possible for you to try and reproduce the problem in this test COM object? If it gets added to the test suite, it will get fixed :) You will need the source pywin32 distro (or CVS would be even better!) and open and build pywin32\com\TestSources\PyCOMTest\PyCOMTest.dsp in MSVC6. If you can give me an IDL patch that builds (ignoring the existing warnings), I should be able to manage the rest (or if you do manage to add an implementation for a new property, win32com\test\testPyComTest.py is the driver) Thanks! ---------------------------------------------------------------------- Comment By: George Tegos (gtegos) Date: 2006-02-22 01:36 Message: Logged In: YES user_id=464497 It seems the problem is with properties listed under the properties: section in the ODL. If the property is defined like this: [id(5)] BOOL NoDirectoryEntries; we get an error (wrong number of parameters) but if it is defined like this: [propget, id(5)] HRESULT NoDirectoryEntries([out, retval] VARIANT_BOOL* result); [propput, id(5)] HRESULT NoDirectoryEntries([in] VARIANT_BOOL setting); it works OK. I think the problem is in _GetDescInvokeType, which when called from CDispatch.__setattr__ returns pythoncom.INVOKE_PROPERTYGET | pythoncom.INVOKE_FUNC instead of pythoncom.INVOKE_PROPERTYPUT which was returned in versio 200 which was working. ---------------------------------------------------------------------- Comment By: George Tegos (gtegos) Date: 2006-02-20 20:33 Message: Logged In: YES user_id=464497 After a long while, I am reopening this issue, as I am trying to upgrade from pythonwin 200 to pythonwin207 for Python 2.3. The problem still exists. I attach the file Problem.odl, in which I define two interfaces, IApplicationAuto and IZipAuto. The interface IApplicationAuto has a member Zip, which returns an object implementing the IZipAuto interface. When setting, from a script, Application.Zip.NoDirectoryEntries = 0 I am getting the following error: Source line: Application.Zip.NoDirectoryEntries = 0 Traceback... c:\python\lib\site-packages\win32com\client\dynamic.py line 528 in __setattr__ self._oleobj_.Invoke(entry.dispid, 0, invoke_type, 0, value) COM Error: Invalid number of parameters (0x8002000e...) The Application automation class is implemented in MFC using BEGIN_DISPATCH_MAP(CApplicationAuto, CHHCmdTarget) //{{AFX_DISPATCH_MAP(CApplicationAuto) DISP_PROPERTY_EX(CApplicationAuto, "SerialNumber", GetSerialNumber, SetNotSupported, VT_BSTR) DISP_PROPERTY_EX(CApplicationAuto, "Zip", GetZip, SetZip, VT_DISPATCH) ... END_DISPATCH_MAP() ---------------------------------------------------------------------- Comment By: George Tegos (gtegos) Date: 2004-10-12 19:31 Message: Logged In: YES user_id=464497 I attach a strip down version of the odl file describing Application and Zip objects. I debugged the code using versions 203 and 200. The problem seems to be in CDispatch.__setattr__ if self.__LazyMap__(attr): # Check the "general" property map. if self._olerepr_.propMap.has_key(attr): entry = self._olerepr_.propMap[attr] invoke_type = _GetDescInvokeType ... self._oleobj_.Invoke(entry.dispid, 0, invoke_type, 0, value) return invoke_type has the value of 3 in version 203 instead of 4 (pythoncom.INVOKE_PROPERTYPUT) in version 200, which works. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-09 11:48 Message: Logged In: YES user_id=14198 Could you please provide a sample or some way for me to repro this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=978096&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-25 08:28:40
|
Bugs item #1017504, was opened at 2004-08-27 10:44 Message generated for change (Comment added) made by erik_andersen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Closed Resolution: Fixed Priority: 4 Submitted By: Martin Gfeller (gfe) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger fills Registry with 100s of ToolbarDefault-Bar-n Initial Comment: On Windows 2000, PythonWin creates many hundreds of ToolbarDefault-Bar-n keys in the registry once the debugger is invoked (either by debug or post-mortem) and the 'go' or 'close' button is clicked. It seems to be specific to Windows 2000, where it occurs each time, and makes the debugger pretty unusable, because the registry slows down Windows to the point of unusability and instability. I could not reproduce it on Windows XP Pro. Environment: PythonWin Build 202 PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32. Windows 2000, SP4, Build 2195 Best regards, Martin ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2006-02-25 08:28 Message: Logged In: YES user_id=364358 I removed all registy entries for pythonwin and that solved the problem. Obviously, upgrades to new versions don't delete the bad registry entries that cause the bug. Erik ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2005-11-14 09:51 Message: Logged In: YES user_id=884167 I cannot reproduce it after installing 204. For me, the problem is solved. Martin ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2005-11-13 20:11 Message: Logged In: YES user_id=364358 It still exists in both 205 and 204. To trigger it, start pythonwin, enter and leave the debugger a couple of times, and you will have the junk in the registry. Win XP SP2 Python 2.4.2 Erik ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-11-10 20:54 Message: Logged In: YES user_id=14198 This bug is already marked as fixed - assumikng you have the latest pywin32 extensions, there should be no need to change anything. ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2005-11-10 19:28 Message: Logged In: YES user_id=364358 This can be fixed by commenting out the line self.saveBarState("ToolBarbefault") in intpyapp.py. Of couse, then pythonwin cannot remeber its bar state between sessions, but it is necessary to solve this problem -- otherwise pythonwin becames impossibly slow after the debugger has been entered and exited a number of times. The huge number of barstates saved can also cause interference to other applications running. Patch: 58c58 < self.SaveBarState("ToolbarDefault") --- > ## self.SaveBarState("ToolbarDefault") ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-06 00:54 Message: Logged In: YES user_id=14198 The problem probably appeared ok in 2.4 due to another bug which caused a crash at shutdown, possibly preventing the toolbar state from being saved (and thereby not hitting the problem). That bug was also recently fixed. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-03-05 15:12 Message: Logged In: YES user_id=285587 Thanks Mark, I'll be watching for 204. Incidentally, with very limited usage so far, I have the impression that the problem did not exist with Python 2.4.2 Colin W. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-05 05:07 Message: Logged In: YES user_id=14198 Fixed - will be in build 204 ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2005-01-10 09:25 Message: Logged In: YES user_id=884167 I never encountered this AssertionError, nevertheless the registry gets filled regularly. I zap the PyWin part of the registry now routinely after using the debugger. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-01-08 20:48 Message: Logged In: YES user_id=285587 The following traceback appears to be connected with the flood of toolbar entries to the registry of Windows XP with PythonWin build 203. The work around is to uninstall PythonWin and then remove the Python for win32 entry in the registry (uninstall doesn't do this). Finally, reinstall PythonWin. >>> Traceback (most recent call last): File "C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py", line 65, in OnStepOver self._DoOrStart("do_set_next", scriptutils.RS_DEBUGGER_STEP) File "C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py", line 57, in _DoOrStart method() File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 632, in do_set_next if self.GUIAboutToRun(): File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 791, in GUIAboutToRun if not self.StopDebuggerPump(): File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 487, in StopDebuggerPump assert self.pumping, "Can't stop the debugger pump if Im not pumping!" AssertionError: Can't stop the debugger pump if Im not pumping! win32ui: Error in Command Message handler for command ID 15021, Code 0 Best wishes, Colin W. ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2004-12-22 21:48 Message: Logged In: YES user_id=884167 It also happens to me on Windows XP SP2 now (with PyWin 203). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-09 05:52 Message: Logged In: YES user_id=14198 As I said in 944506: I've failed again to solve this. It sounds alot like Q151446, but that is pre MFC6, and doesn't solve the problem. It *nearly* does. I'm closing this and will keep "[ 1017504 ] Debugger fills Registry with 100s of ToolbarDefault-Bar-n" open (only as it has a better name) The next release will have that SaveBarState() call commented out. Dropping priority as this should mean the bug is much less severe. ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2004-08-28 13:19 Message: Logged In: YES user_id=587593 *This problem has also been entered under 894191 and 944506. It definitely causes problems, and has not, to my knowledge been addressed. 944506 has never been assigned! Please, someone who knows the details of what should happen help us. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-21 14:36:51
|
Bugs item #978096, was opened at 2004-06-23 09:54 Message generated for change (Comment added) made by gtegos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=978096&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: George Tegos (gtegos) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with nested dispatches in build 201 Initial Comment: We have an application which exposes an automation object Application. One member of Application is Zip which is another automation object which has a property Recursive of type BOOL. In a Python script we have: Application.Zip.Recursive = 1 With build 201 we get a COM error saying that we have a wrong number of parameters. The same was working fine with build 200 ---------------------------------------------------------------------- >Comment By: George Tegos (gtegos) Date: 2006-02-21 14:36 Message: Logged In: YES user_id=464497 It seems the problem is with properties listed under the properties: section in the ODL. If the property is defined like this: [id(5)] BOOL NoDirectoryEntries; we get an error (wrong number of parameters) but if it is defined like this: [propget, id(5)] HRESULT NoDirectoryEntries([out, retval] VARIANT_BOOL* result); [propput, id(5)] HRESULT NoDirectoryEntries([in] VARIANT_BOOL setting); it works OK. I think the problem is in _GetDescInvokeType, which when called from CDispatch.__setattr__ returns pythoncom.INVOKE_PROPERTYGET | pythoncom.INVOKE_FUNC instead of pythoncom.INVOKE_PROPERTYPUT which was returned in versio 200 which was working. ---------------------------------------------------------------------- Comment By: George Tegos (gtegos) Date: 2006-02-20 09:33 Message: Logged In: YES user_id=464497 After a long while, I am reopening this issue, as I am trying to upgrade from pythonwin 200 to pythonwin207 for Python 2.3. The problem still exists. I attach the file Problem.odl, in which I define two interfaces, IApplicationAuto and IZipAuto. The interface IApplicationAuto has a member Zip, which returns an object implementing the IZipAuto interface. When setting, from a script, Application.Zip.NoDirectoryEntries = 0 I am getting the following error: Source line: Application.Zip.NoDirectoryEntries = 0 Traceback... c:\python\lib\site-packages\win32com\client\dynamic.py line 528 in __setattr__ self._oleobj_.Invoke(entry.dispid, 0, invoke_type, 0, value) COM Error: Invalid number of parameters (0x8002000e...) The Application automation class is implemented in MFC using BEGIN_DISPATCH_MAP(CApplicationAuto, CHHCmdTarget) //{{AFX_DISPATCH_MAP(CApplicationAuto) DISP_PROPERTY_EX(CApplicationAuto, "SerialNumber", GetSerialNumber, SetNotSupported, VT_BSTR) DISP_PROPERTY_EX(CApplicationAuto, "Zip", GetZip, SetZip, VT_DISPATCH) ... END_DISPATCH_MAP() ---------------------------------------------------------------------- Comment By: George Tegos (gtegos) Date: 2004-10-12 09:31 Message: Logged In: YES user_id=464497 I attach a strip down version of the odl file describing Application and Zip objects. I debugged the code using versions 203 and 200. The problem seems to be in CDispatch.__setattr__ if self.__LazyMap__(attr): # Check the "general" property map. if self._olerepr_.propMap.has_key(attr): entry = self._olerepr_.propMap[attr] invoke_type = _GetDescInvokeType ... self._oleobj_.Invoke(entry.dispid, 0, invoke_type, 0, value) return invoke_type has the value of 3 in version 203 instead of 4 (pythoncom.INVOKE_PROPERTYPUT) in version 200, which works. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-09 01:48 Message: Logged In: YES user_id=14198 Could you please provide a sample or some way for me to repro this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=978096&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-20 09:33:35
|
Bugs item #978096, was opened at 2004-06-23 09:54 Message generated for change (Comment added) made by gtegos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=978096&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: George Tegos (gtegos) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with nested dispatches in build 201 Initial Comment: We have an application which exposes an automation object Application. One member of Application is Zip which is another automation object which has a property Recursive of type BOOL. In a Python script we have: Application.Zip.Recursive = 1 With build 201 we get a COM error saying that we have a wrong number of parameters. The same was working fine with build 200 ---------------------------------------------------------------------- >Comment By: George Tegos (gtegos) Date: 2006-02-20 09:33 Message: Logged In: YES user_id=464497 After a long while, I am reopening this issue, as I am trying to upgrade from pythonwin 200 to pythonwin207 for Python 2.3. The problem still exists. I attach the file Problem.odl, in which I define two interfaces, IApplicationAuto and IZipAuto. The interface IApplicationAuto has a member Zip, which returns an object implementing the IZipAuto interface. When setting, from a script, Application.Zip.NoDirectoryEntries = 0 I am getting the following error: Source line: Application.Zip.NoDirectoryEntries = 0 Traceback... c:\python\lib\site-packages\win32com\client\dynamic.py line 528 in __setattr__ self._oleobj_.Invoke(entry.dispid, 0, invoke_type, 0, value) COM Error: Invalid number of parameters (0x8002000e...) The Application automation class is implemented in MFC using BEGIN_DISPATCH_MAP(CApplicationAuto, CHHCmdTarget) //{{AFX_DISPATCH_MAP(CApplicationAuto) DISP_PROPERTY_EX(CApplicationAuto, "SerialNumber", GetSerialNumber, SetNotSupported, VT_BSTR) DISP_PROPERTY_EX(CApplicationAuto, "Zip", GetZip, SetZip, VT_DISPATCH) ... END_DISPATCH_MAP() ---------------------------------------------------------------------- Comment By: George Tegos (gtegos) Date: 2004-10-12 09:31 Message: Logged In: YES user_id=464497 I attach a strip down version of the odl file describing Application and Zip objects. I debugged the code using versions 203 and 200. The problem seems to be in CDispatch.__setattr__ if self.__LazyMap__(attr): # Check the "general" property map. if self._olerepr_.propMap.has_key(attr): entry = self._olerepr_.propMap[attr] invoke_type = _GetDescInvokeType ... self._oleobj_.Invoke(entry.dispid, 0, invoke_type, 0, value) return invoke_type has the value of 3 in version 203 instead of 4 (pythoncom.INVOKE_PROPERTYPUT) in version 200, which works. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-09 01:48 Message: Logged In: YES user_id=14198 Could you please provide a sample or some way for me to repro this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=978096&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-20 01:34:00
|
Feature Requests item #1414413, was opened at 2006-01-25 20:29 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1414413&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: HVB bei TUP (hvb_tup) Assigned to: Nobody/Anonymous (nobody) Summary: Support JobObject functions Initial Comment: JobObject functions are very useful. The basic usage is: CreateJobObject CreateProcess suspended AddProcessToJobObject ResumeThread Then the child process you started belongs to the job, as well as any processes the child process starts (the property of belonging to a job is inherited). You can then kill the child process AND all grandchildren etc. using TerminateJobObject. This is very similar to the *nix world. References: MSDN: CreateJobObject TerminateJobObject AddProcessToJobObject QueryInformationJobObject http://www.microsoft.com/msj/0698/win320698.aspx see the last paragraphs mentioning JobObjects. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-02-20 12:33 Message: Logged In: YES user_id=14198 Look out for the new win32job module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1414413&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-13 10:36:58
|
Feature Requests item #1429820, was opened at 2006-02-11 15:23 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429820&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Norman Rasmussen (normanr) Assigned to: Nobody/Anonymous (nobody) Summary: Better documentation for CtxtHandleType, and others Initial Comment: PyCredHandle does it right: In the Comments section in the help file it tells you to use win32security.CredHandleType() to create an instance. These classes require the same code, but the help doesn't tell you that: - PyCtxtHandle - PySecBufferDesc - PySecBuffer Possibly: Is there anyway to make a default constructor for these classes so you don't have to call ThingType() to create a new PyThing. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-02-13 05:36 Message: Logged In: YES user_id=771074 Sorry, I didn't realize that the name was the issue. After looking thru some old stuff, it appears the type originally was named just CtxtHandleType, and I forgot to change the attributes in win32security when the names changed. I'll go ahead and add some aliases for these with the Py prefix for consistency's sake. Roger ---------------------------------------------------------------------- Comment By: Norman Rasmussen (normanr) Date: 2006-02-13 03:28 Message: Logged In: YES user_id=336265 Agreed, I don't mind which naming convention is used, but I think it makes sense to use only one. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-02-12 18:08 Message: Logged In: YES user_id=14198 I think you are simply saying that the name of the type in the module isn't the same as what __name__ returns? I'm inclined to agree that should be fixed, and that __name__ should match the name in the dict. I haven't been very consistent myself with that, but it certainly makes more sense when using real types here. ---------------------------------------------------------------------- Comment By: Norman Rasmussen (normanr) Date: 2006-02-12 10:01 Message: Logged In: YES user_id=336265 My objection is to the ThingType object itself. (the only thing is does is allow you to create a PyThing object) eg: >>> import win32security >>> win32security.CtxtHandleType.__name__ 'PyCtxtHandle' The docs all reference PyCtxtHandle, and not CtxtHandleType. So why can't I use win32security.PyCtxtHandle() ? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-02-12 09:37 Message: Logged In: YES user_id=771074 Calling win32security.CtxtHandleType() calls the type's __new__ constructor. A distinct function to create the handle would be just a pass-thru to the same type constructor, so there's really no advantage to having a function separate from the type object. Roger ---------------------------------------------------------------------- Comment By: Norman Rasmussen (normanr) Date: 2006-02-12 07:37 Message: Logged In: YES user_id=336265 Cool. Is there no way to make a constructor for these objects on the same object? Either via setting a __init__ method, or even providing a 'new' static method on the object. i.e. win32security.PyCtxtHandle.New() instead of win32security.CtxtHandleType(). I'm guessing that win32security.PyCtxtHandle() is much harder? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-02-12 06:12 Message: Logged In: YES user_id=771074 Just checked in win32security_sspi.cpp 1.5 with some clarifications and corrections. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429820&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-13 08:28:20
|
Feature Requests item #1429820, was opened at 2006-02-11 22:23 Message generated for change (Comment added) made by normanr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429820&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Norman Rasmussen (normanr) Assigned to: Nobody/Anonymous (nobody) Summary: Better documentation for CtxtHandleType, and others Initial Comment: PyCredHandle does it right: In the Comments section in the help file it tells you to use win32security.CredHandleType() to create an instance. These classes require the same code, but the help doesn't tell you that: - PyCtxtHandle - PySecBufferDesc - PySecBuffer Possibly: Is there anyway to make a default constructor for these classes so you don't have to call ThingType() to create a new PyThing. ---------------------------------------------------------------------- >Comment By: Norman Rasmussen (normanr) Date: 2006-02-13 10:28 Message: Logged In: YES user_id=336265 Agreed, I don't mind which naming convention is used, but I think it makes sense to use only one. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-02-13 01:08 Message: Logged In: YES user_id=14198 I think you are simply saying that the name of the type in the module isn't the same as what __name__ returns? I'm inclined to agree that should be fixed, and that __name__ should match the name in the dict. I haven't been very consistent myself with that, but it certainly makes more sense when using real types here. ---------------------------------------------------------------------- Comment By: Norman Rasmussen (normanr) Date: 2006-02-12 17:01 Message: Logged In: YES user_id=336265 My objection is to the ThingType object itself. (the only thing is does is allow you to create a PyThing object) eg: >>> import win32security >>> win32security.CtxtHandleType.__name__ 'PyCtxtHandle' The docs all reference PyCtxtHandle, and not CtxtHandleType. So why can't I use win32security.PyCtxtHandle() ? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-02-12 16:37 Message: Logged In: YES user_id=771074 Calling win32security.CtxtHandleType() calls the type's __new__ constructor. A distinct function to create the handle would be just a pass-thru to the same type constructor, so there's really no advantage to having a function separate from the type object. Roger ---------------------------------------------------------------------- Comment By: Norman Rasmussen (normanr) Date: 2006-02-12 14:37 Message: Logged In: YES user_id=336265 Cool. Is there no way to make a constructor for these objects on the same object? Either via setting a __init__ method, or even providing a 'new' static method on the object. i.e. win32security.PyCtxtHandle.New() instead of win32security.CtxtHandleType(). I'm guessing that win32security.PyCtxtHandle() is much harder? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-02-12 13:12 Message: Logged In: YES user_id=771074 Just checked in win32security_sspi.cpp 1.5 with some clarifications and corrections. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429820&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-12 23:09:00
|
Feature Requests item #1429820, was opened at 2006-02-12 07:23 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429820&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Norman Rasmussen (normanr) Assigned to: Nobody/Anonymous (nobody) Summary: Better documentation for CtxtHandleType, and others Initial Comment: PyCredHandle does it right: In the Comments section in the help file it tells you to use win32security.CredHandleType() to create an instance. These classes require the same code, but the help doesn't tell you that: - PyCtxtHandle - PySecBufferDesc - PySecBuffer Possibly: Is there anyway to make a default constructor for these classes so you don't have to call ThingType() to create a new PyThing. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-02-13 10:08 Message: Logged In: YES user_id=14198 I think you are simply saying that the name of the type in the module isn't the same as what __name__ returns? I'm inclined to agree that should be fixed, and that __name__ should match the name in the dict. I haven't been very consistent myself with that, but it certainly makes more sense when using real types here. ---------------------------------------------------------------------- Comment By: Norman Rasmussen (normanr) Date: 2006-02-13 02:01 Message: Logged In: YES user_id=336265 My objection is to the ThingType object itself. (the only thing is does is allow you to create a PyThing object) eg: >>> import win32security >>> win32security.CtxtHandleType.__name__ 'PyCtxtHandle' The docs all reference PyCtxtHandle, and not CtxtHandleType. So why can't I use win32security.PyCtxtHandle() ? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-02-13 01:37 Message: Logged In: YES user_id=771074 Calling win32security.CtxtHandleType() calls the type's __new__ constructor. A distinct function to create the handle would be just a pass-thru to the same type constructor, so there's really no advantage to having a function separate from the type object. Roger ---------------------------------------------------------------------- Comment By: Norman Rasmussen (normanr) Date: 2006-02-12 23:37 Message: Logged In: YES user_id=336265 Cool. Is there no way to make a constructor for these objects on the same object? Either via setting a __init__ method, or even providing a 'new' static method on the object. i.e. win32security.PyCtxtHandle.New() instead of win32security.CtxtHandleType(). I'm guessing that win32security.PyCtxtHandle() is much harder? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-02-12 22:12 Message: Logged In: YES user_id=771074 Just checked in win32security_sspi.cpp 1.5 with some clarifications and corrections. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429820&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-12 15:14:13
|
Feature Requests item #1429815, was opened at 2006-02-11 22:19 Message generated for change (Comment added) made by normanr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429815&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Norman Rasmussen (normanr) Assigned to: Nobody/Anonymous (nobody) Summary: win32security missing several constants (listed) Initial Comment: Please can you include the following sets of constants: ISC_REQ_* ISC_RET_* ASC_REQ_* ASC_RET_* SECBUFFER_* SECPKG_ATTR_* SECPKG_CONTEXT_* SECPKG_FLAG_* SECPKG_NEGOTIATION_* SECPKG_OPTIONS_* SECURITY_*_DREP SEC_E_OK SEC_I_* SEC_WINNT_* Some are referenced in the help files, but they're not defined. I had to go and dig in sspi.h in the SDK to find the vaules. Some used for AcceptSecurityContext and InitializeSecurityContext are only metioned by wildcard, and should be listed (like PyCtxtHandle.QueryContextAttributes does) (sspi.h attached) ---------------------------------------------------------------------- >Comment By: Norman Rasmussen (normanr) Date: 2006-02-12 17:14 Message: Logged In: YES user_id=336265 what about linking to the search page? e.g. http://search.msdn.microsoft.com/search/results.aspx?qu=AcceptSecurityContext That way the links shouldn't change that often. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-02-12 16:18 Message: Logged In: YES user_id=771074 I added SEC_E_OK to sspicon. It probably got missed since it's in winerror.h rather than sspi.h. Unfortunately, MSDN doesn't keep their URLs constant. It would create a real maintenance headache to keep all those links in synch. Roger ---------------------------------------------------------------------- Comment By: Norman Rasmussen (normanr) Date: 2006-02-12 14:41 Message: Logged In: YES user_id=336265 Shot, those demo's should make my code much simpler. FYI : SEC_E_OK = 0 is missing from the sspicon.py file. I hear you on the 'maybe we shouldn't include all the MSDN docs in the pywin32 ones, because it's just duplication. Maybe provide links to the MSDN pages from the pywin32 ones would assist with that? I generally open my local copy of the MSDN anyways, but I expected the pywin32 docs to include everything. I think a link to the MSDN doc per page would go a long way to remind people that the pywin32 docs only show the _differences_ to the c implementations. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-02-12 12:26 Message: Logged In: YES user_id=771074 These constants are all in sspicon.py. Check out \win32\Demos\security\sspi for some good examples of how the sspi objects work. (also \win32\test\test_sspi.py) They use a couple of classes for client and server auth that abstract away most of the messy details. Generally speaking, individual constants are usually listed in the docs when there are different types of python objects involved depending on what flags are passed. Some of the functions have so many combinations of flags that it would bloat the help file, and most of it would just be a rehash of the MSDN docs. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429815&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-12 15:01:21
|
Feature Requests item #1429820, was opened at 2006-02-11 22:23 Message generated for change (Comment added) made by normanr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429820&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Norman Rasmussen (normanr) Assigned to: Nobody/Anonymous (nobody) Summary: Better documentation for CtxtHandleType, and others Initial Comment: PyCredHandle does it right: In the Comments section in the help file it tells you to use win32security.CredHandleType() to create an instance. These classes require the same code, but the help doesn't tell you that: - PyCtxtHandle - PySecBufferDesc - PySecBuffer Possibly: Is there anyway to make a default constructor for these classes so you don't have to call ThingType() to create a new PyThing. ---------------------------------------------------------------------- >Comment By: Norman Rasmussen (normanr) Date: 2006-02-12 17:01 Message: Logged In: YES user_id=336265 My objection is to the ThingType object itself. (the only thing is does is allow you to create a PyThing object) eg: >>> import win32security >>> win32security.CtxtHandleType.__name__ 'PyCtxtHandle' The docs all reference PyCtxtHandle, and not CtxtHandleType. So why can't I use win32security.PyCtxtHandle() ? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-02-12 16:37 Message: Logged In: YES user_id=771074 Calling win32security.CtxtHandleType() calls the type's __new__ constructor. A distinct function to create the handle would be just a pass-thru to the same type constructor, so there's really no advantage to having a function separate from the type object. Roger ---------------------------------------------------------------------- Comment By: Norman Rasmussen (normanr) Date: 2006-02-12 14:37 Message: Logged In: YES user_id=336265 Cool. Is there no way to make a constructor for these objects on the same object? Either via setting a __init__ method, or even providing a 'new' static method on the object. i.e. win32security.PyCtxtHandle.New() instead of win32security.CtxtHandleType(). I'm guessing that win32security.PyCtxtHandle() is much harder? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-02-12 13:12 Message: Logged In: YES user_id=771074 Just checked in win32security_sspi.cpp 1.5 with some clarifications and corrections. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429820&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-12 14:37:35
|
Feature Requests item #1429820, was opened at 2006-02-11 15:23 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429820&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Norman Rasmussen (normanr) Assigned to: Nobody/Anonymous (nobody) Summary: Better documentation for CtxtHandleType, and others Initial Comment: PyCredHandle does it right: In the Comments section in the help file it tells you to use win32security.CredHandleType() to create an instance. These classes require the same code, but the help doesn't tell you that: - PyCtxtHandle - PySecBufferDesc - PySecBuffer Possibly: Is there anyway to make a default constructor for these classes so you don't have to call ThingType() to create a new PyThing. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-02-12 09:37 Message: Logged In: YES user_id=771074 Calling win32security.CtxtHandleType() calls the type's __new__ constructor. A distinct function to create the handle would be just a pass-thru to the same type constructor, so there's really no advantage to having a function separate from the type object. Roger ---------------------------------------------------------------------- Comment By: Norman Rasmussen (normanr) Date: 2006-02-12 07:37 Message: Logged In: YES user_id=336265 Cool. Is there no way to make a constructor for these objects on the same object? Either via setting a __init__ method, or even providing a 'new' static method on the object. i.e. win32security.PyCtxtHandle.New() instead of win32security.CtxtHandleType(). I'm guessing that win32security.PyCtxtHandle() is much harder? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-02-12 06:12 Message: Logged In: YES user_id=771074 Just checked in win32security_sspi.cpp 1.5 with some clarifications and corrections. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429820&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-12 14:19:05
|
Feature Requests item #1429815, was opened at 2006-02-11 15:19 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429815&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Norman Rasmussen (normanr) Assigned to: Nobody/Anonymous (nobody) Summary: win32security missing several constants (listed) Initial Comment: Please can you include the following sets of constants: ISC_REQ_* ISC_RET_* ASC_REQ_* ASC_RET_* SECBUFFER_* SECPKG_ATTR_* SECPKG_CONTEXT_* SECPKG_FLAG_* SECPKG_NEGOTIATION_* SECPKG_OPTIONS_* SECURITY_*_DREP SEC_E_OK SEC_I_* SEC_WINNT_* Some are referenced in the help files, but they're not defined. I had to go and dig in sspi.h in the SDK to find the vaules. Some used for AcceptSecurityContext and InitializeSecurityContext are only metioned by wildcard, and should be listed (like PyCtxtHandle.QueryContextAttributes does) (sspi.h attached) ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-02-12 09:18 Message: Logged In: YES user_id=771074 I added SEC_E_OK to sspicon. It probably got missed since it's in winerror.h rather than sspi.h. Unfortunately, MSDN doesn't keep their URLs constant. It would create a real maintenance headache to keep all those links in synch. Roger ---------------------------------------------------------------------- Comment By: Norman Rasmussen (normanr) Date: 2006-02-12 07:41 Message: Logged In: YES user_id=336265 Shot, those demo's should make my code much simpler. FYI : SEC_E_OK = 0 is missing from the sspicon.py file. I hear you on the 'maybe we shouldn't include all the MSDN docs in the pywin32 ones, because it's just duplication. Maybe provide links to the MSDN pages from the pywin32 ones would assist with that? I generally open my local copy of the MSDN anyways, but I expected the pywin32 docs to include everything. I think a link to the MSDN doc per page would go a long way to remind people that the pywin32 docs only show the _differences_ to the c implementations. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-02-12 05:26 Message: Logged In: YES user_id=771074 These constants are all in sspicon.py. Check out \win32\Demos\security\sspi for some good examples of how the sspi objects work. (also \win32\test\test_sspi.py) They use a couple of classes for client and server auth that abstract away most of the messy details. Generally speaking, individual constants are usually listed in the docs when there are different types of python objects involved depending on what flags are passed. Some of the functions have so many combinations of flags that it would bloat the help file, and most of it would just be a rehash of the MSDN docs. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429815&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-12 12:41:40
|
Feature Requests item #1429815, was opened at 2006-02-11 22:19 Message generated for change (Comment added) made by normanr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429815&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Norman Rasmussen (normanr) Assigned to: Nobody/Anonymous (nobody) Summary: win32security missing several constants (listed) Initial Comment: Please can you include the following sets of constants: ISC_REQ_* ISC_RET_* ASC_REQ_* ASC_RET_* SECBUFFER_* SECPKG_ATTR_* SECPKG_CONTEXT_* SECPKG_FLAG_* SECPKG_NEGOTIATION_* SECPKG_OPTIONS_* SECURITY_*_DREP SEC_E_OK SEC_I_* SEC_WINNT_* Some are referenced in the help files, but they're not defined. I had to go and dig in sspi.h in the SDK to find the vaules. Some used for AcceptSecurityContext and InitializeSecurityContext are only metioned by wildcard, and should be listed (like PyCtxtHandle.QueryContextAttributes does) (sspi.h attached) ---------------------------------------------------------------------- >Comment By: Norman Rasmussen (normanr) Date: 2006-02-12 14:41 Message: Logged In: YES user_id=336265 Shot, those demo's should make my code much simpler. FYI : SEC_E_OK = 0 is missing from the sspicon.py file. I hear you on the 'maybe we shouldn't include all the MSDN docs in the pywin32 ones, because it's just duplication. Maybe provide links to the MSDN pages from the pywin32 ones would assist with that? I generally open my local copy of the MSDN anyways, but I expected the pywin32 docs to include everything. I think a link to the MSDN doc per page would go a long way to remind people that the pywin32 docs only show the _differences_ to the c implementations. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-02-12 12:26 Message: Logged In: YES user_id=771074 These constants are all in sspicon.py. Check out \win32\Demos\security\sspi for some good examples of how the sspi objects work. (also \win32\test\test_sspi.py) They use a couple of classes for client and server auth that abstract away most of the messy details. Generally speaking, individual constants are usually listed in the docs when there are different types of python objects involved depending on what flags are passed. Some of the functions have so many combinations of flags that it would bloat the help file, and most of it would just be a rehash of the MSDN docs. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429815&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-12 12:37:58
|
Feature Requests item #1429820, was opened at 2006-02-11 22:23 Message generated for change (Comment added) made by normanr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429820&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Norman Rasmussen (normanr) Assigned to: Nobody/Anonymous (nobody) Summary: Better documentation for CtxtHandleType, and others Initial Comment: PyCredHandle does it right: In the Comments section in the help file it tells you to use win32security.CredHandleType() to create an instance. These classes require the same code, but the help doesn't tell you that: - PyCtxtHandle - PySecBufferDesc - PySecBuffer Possibly: Is there anyway to make a default constructor for these classes so you don't have to call ThingType() to create a new PyThing. ---------------------------------------------------------------------- >Comment By: Norman Rasmussen (normanr) Date: 2006-02-12 14:37 Message: Logged In: YES user_id=336265 Cool. Is there no way to make a constructor for these objects on the same object? Either via setting a __init__ method, or even providing a 'new' static method on the object. i.e. win32security.PyCtxtHandle.New() instead of win32security.CtxtHandleType(). I'm guessing that win32security.PyCtxtHandle() is much harder? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-02-12 13:12 Message: Logged In: YES user_id=771074 Just checked in win32security_sspi.cpp 1.5 with some clarifications and corrections. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429820&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-12 11:13:01
|
Feature Requests item #1429820, was opened at 2006-02-11 15:23 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429820&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Norman Rasmussen (normanr) Assigned to: Nobody/Anonymous (nobody) Summary: Better documentation for CtxtHandleType, and others Initial Comment: PyCredHandle does it right: In the Comments section in the help file it tells you to use win32security.CredHandleType() to create an instance. These classes require the same code, but the help doesn't tell you that: - PyCtxtHandle - PySecBufferDesc - PySecBuffer Possibly: Is there anyway to make a default constructor for these classes so you don't have to call ThingType() to create a new PyThing. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-02-12 06:12 Message: Logged In: YES user_id=771074 Just checked in win32security_sspi.cpp 1.5 with some clarifications and corrections. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429820&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-12 10:26:34
|
Feature Requests item #1429815, was opened at 2006-02-11 15:19 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429815&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Norman Rasmussen (normanr) Assigned to: Nobody/Anonymous (nobody) Summary: win32security missing several constants (listed) Initial Comment: Please can you include the following sets of constants: ISC_REQ_* ISC_RET_* ASC_REQ_* ASC_RET_* SECBUFFER_* SECPKG_ATTR_* SECPKG_CONTEXT_* SECPKG_FLAG_* SECPKG_NEGOTIATION_* SECPKG_OPTIONS_* SECURITY_*_DREP SEC_E_OK SEC_I_* SEC_WINNT_* Some are referenced in the help files, but they're not defined. I had to go and dig in sspi.h in the SDK to find the vaules. Some used for AcceptSecurityContext and InitializeSecurityContext are only metioned by wildcard, and should be listed (like PyCtxtHandle.QueryContextAttributes does) (sspi.h attached) ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-02-12 05:26 Message: Logged In: YES user_id=771074 These constants are all in sspicon.py. Check out \win32\Demos\security\sspi for some good examples of how the sspi objects work. (also \win32\test\test_sspi.py) They use a couple of classes for client and server auth that abstract away most of the messy details. Generally speaking, individual constants are usually listed in the docs when there are different types of python objects involved depending on what flags are passed. Some of the functions have so many combinations of flags that it would bloat the help file, and most of it would just be a rehash of the MSDN docs. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429815&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-11 20:24:02
|
Feature Requests item #1429820, was opened at 2006-02-11 22:23 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=1429820&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Norman Rasmussen (normanr) Assigned to: Nobody/Anonymous (nobody) Summary: Better documentation for CtxtHandleType, and others Initial Comment: PyCredHandle does it right: In the Comments section in the help file it tells you to use win32security.CredHandleType() to create an instance. These classes require the same code, but the help doesn't tell you that: - PyCtxtHandle - PySecBufferDesc - PySecBuffer Possibly: Is there anyway to make a default constructor for these classes so you don't have to call ThingType() to create a new PyThing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429820&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
