pywin32-bugs Mailing List for Python for Windows Extensions (Page 97)
OLD project page for the Python extensions for Windows
Brought to you by:
mhammond
Menu
▾
▴
pywin32-bugs — Automated tracker notifications (not for bug reports!)
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(24) |
May
(19) |
Jun
(15) |
Jul
(43) |
Aug
(39) |
Sep
(25) |
Oct
(43) |
Nov
(19) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(21) |
Feb
(18) |
Mar
(14) |
Apr
(80) |
May
(56) |
Jun
(24) |
Jul
(30) |
Aug
(17) |
Sep
(36) |
Oct
(106) |
Nov
(38) |
Dec
(30) |
| 2005 |
Jan
(14) |
Feb
(14) |
Mar
(48) |
Apr
(28) |
May
(49) |
Jun
(23) |
Jul
(9) |
Aug
(13) |
Sep
(28) |
Oct
(21) |
Nov
(8) |
Dec
(26) |
| 2006 |
Jan
(56) |
Feb
(33) |
Mar
(33) |
Apr
(18) |
May
(16) |
Jun
(9) |
Jul
(24) |
Aug
(16) |
Sep
(14) |
Oct
(37) |
Nov
(38) |
Dec
(22) |
| 2007 |
Jan
(7) |
Feb
(16) |
Mar
(11) |
Apr
(15) |
May
(15) |
Jun
(8) |
Jul
(24) |
Aug
(26) |
Sep
(18) |
Oct
(11) |
Nov
(20) |
Dec
(1) |
| 2008 |
Jan
(19) |
Feb
(55) |
Mar
(7) |
Apr
(35) |
May
(66) |
Jun
(38) |
Jul
(26) |
Aug
(5) |
Sep
(25) |
Oct
(25) |
Nov
(18) |
Dec
(18) |
| 2009 |
Jan
(25) |
Feb
(38) |
Mar
(29) |
Apr
(25) |
May
(5) |
Jun
(11) |
Jul
(16) |
Aug
(16) |
Sep
(16) |
Oct
(1) |
Nov
(15) |
Dec
(33) |
| 2010 |
Jan
(13) |
Feb
(11) |
Mar
(1) |
Apr
(24) |
May
(26) |
Jun
(19) |
Jul
(22) |
Aug
(51) |
Sep
(38) |
Oct
(39) |
Nov
(25) |
Dec
(27) |
| 2011 |
Jan
(40) |
Feb
(31) |
Mar
(21) |
Apr
(42) |
May
(11) |
Jun
(16) |
Jul
(20) |
Aug
(14) |
Sep
(6) |
Oct
(8) |
Nov
(34) |
Dec
(7) |
| 2012 |
Jan
(60) |
Feb
(24) |
Mar
(6) |
Apr
(28) |
May
(41) |
Jun
(15) |
Jul
(14) |
Aug
(25) |
Sep
(30) |
Oct
(18) |
Nov
(30) |
Dec
(9) |
| 2013 |
Jan
(3) |
Feb
(8) |
Mar
(17) |
Apr
(23) |
May
(34) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2004-10-09 01:48:57
|
Bugs item #968201, was opened at 2004-06-08 00:41 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=968201&group_id=78018 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Geisinger (geisinger) Assigned to: Nobody/Anonymous (nobody) Summary: Browse CVS Repository broken Initial Comment: browsing the CVS repository will fail with the following message Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /viewcvs.py/pywin32. Reason: Max-Forwards has reached zero - proxy loop? ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2004-06-08 07:59 Message: Logged In: YES user_id=552329 This is a sourceforge problem (see the site status link on the left), and applies to projects starting with various letters, including 'p'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=968201&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 01:48:32
|
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 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: 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...> - 2004-10-09 01:45:46
|
Bugs item #971513, was opened at 2004-06-12 10:46 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=971513&group_id=78018 Category: installation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dave Cook (caveduck) Assigned to: Nobody/Anonymous (nobody) Summary: Can't install pywin32 on XP limited user account Initial Comment: Attempting to install pywin32 on a limited user account under XP is met with a "you don't appear to have enough privileges" dialog. This is then followed by two error dialogs about freopen on stderr etc. Is it fundamentally impossible for pywin32 to operate in a limited account? Base python will work with only a few limitations. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 11:45 Message: Logged In: YES user_id=14198 This should largely work in build 202. Please reopen if you still have problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=971513&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 01:44:45
|
Bugs item #971565, was opened at 2004-06-12 15:30 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=971565&group_id=78018 Category: installation Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Dave Cook (caveduck) Assigned to: Nobody/Anonymous (nobody) Summary: Can't install pywin32 on XP limited user account Initial Comment: Attempting to install pywin32 on a limited user account under XP is met with a "you don't appear to have enough privileges" dialog. This is then followed by two error dialogs about freopen on stderr etc. Is it fundamentally impossible for pywin32 to operate in a limited account? Base python will work with only a few limitations. ---------------------------------------------------------------------- Comment By: Dave Cook (caveduck) Date: 2004-06-12 15:31 Message: Logged In: YES user_id=140414 Sorry for the duplicate post, kids refreshed the window :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=971565&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 01:44:14
|
Bugs item #964406, was opened at 2004-06-02 03:06 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=964406&group_id=78018 Category: installation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Edouard Mercier (edouard_mercier) Assigned to: Nobody/Anonymous (nobody) Summary: Installation problem (V201.1) under Windows NT Initial Comment: Hello; trying to install the pywin32 V201.1 (aimed for Python V2.3) under Windows NT, using the .exe installation package with Python V2.3.3 installed (via Zope), I get the following pop-up window: 'Python version 2.3 required, which was not found in the registry.'. Could someone tell me what to do as a work-around, please ? Regards, Edouard ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 11:44 Message: Logged In: YES user_id=14198 I'm sorry, I missed this. You can set an "InstallPath" in the registry. Mail me for more details if it is still a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=964406&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 01:42:41
|
Bugs item #979270, was opened at 2004-06-25 07:03 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=979270&group_id=78018 Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Patrick Mezard (trickos) Assigned to: Nobody/Anonymous (nobody) Summary: SetFilePointer fails with negative offset Initial Comment: I failed to make SetFilePointer work with negative offsets (using FILE_CURRENT or FILE_END) where the equivalent C call works correctly. The attached code demonstrates the problem. Running it returns: ###################### Traceback (most recent call last): File "test_win32file.py", line 34, in ? assert s==data AssertionError ###################### Making wild guess about the C++ code, I would say the routine/macro decoding or repacking the Py_LARGEINTEGER into a pair of (LONG,LONG) might mess with signed/unsigned integers. I have no debugging proof to support that claim though. I tested with the package provided with "Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit (Intel)] on win32", Windows XP Pro SP1. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 11:42 Message: Logged In: YES user_id=14198 You should find this fixed in build 202 - if not, then build 203 :) I checked your test code into win32\test\test_win32file.py - thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=979270&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 01:34:20
|
Bugs item #982700, was opened at 2004-06-30 22:19 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=982700&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fedor Baart (siggyf) Assigned to: Nobody/Anonymous (nobody) Summary: unicode default arguments raises an error Initial Comment: A function with a default unicode argument raises an error if pywin shows the argument-popup. Reproduction: Enter the folowing in the interactive window: def test(a=u'a'): pass Enter "test(" and an error will be raised: TypeError: array initializer must be list or string The cause is that array's are created with the text of the default arguments. This is done with typecode 'c'. This isn't unicode compatible. (PythonWin 2.3.4 (#53, May 25 2004, 21:17:02) build 201, Windows XP) ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 11:34 Message: Logged In: YES user_id=14198 Fixed - thanks Checking in control.py; new revision: 1.14; previous revision: 1.13 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=982700&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 01:21:26
|
Bugs item #979641, was opened at 2004-06-25 20:30 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=979641&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thorsten Kohnhorst (monsterkodi) Assigned to: Nobody/Anonymous (nobody) Summary: win32com.shell.shell.SHEmptyRecycleBin crashes on Win XP Initial Comment: win32com.shell.shell.SHEmptyRecycleBin works correctly (it empties the trash bin) but fails to return without a crash (read access violation) on Windows XP. tested for builds 200 and 201.1 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 11:21 Message: Logged In: YES user_id=14198 Fixed - thanks! Checking in shell.cpp; new revision: 1.29; previous revision: 1.28 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=979641&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 00:37:28
|
Bugs item #987401, was opened at 2004-07-09 02:18 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=987401&group_id=78018 Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: Support for layered windows? Initial Comment: Could win32gui be extended to support the layered window functionality of Windows 2000+? I'm looking in particular for UpdateLayeredWindow, SetLayeredWindowAttributes, and AnimateWindow. See the following MSDN article. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/layerwin.asp ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 10:37 Message: Logged In: YES user_id=14198 These will be in build 203's winxpgui. I would love it if you could submit back a sample once I release it. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=987401&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-08 23:45:38
|
Bugs item #986673, was opened at 2004-07-08 01:54 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=986673&group_id=78018 Category: com Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Phil Rittenhouse (prittenh) >Assigned to: Mark Hammond (mhammond) Summary: Python exceptions through COM custom interface Initial Comment: The problem occurs with Python COM servers raising COM exceptions across a custom interface. Using the dispatch interface works fine, but in the custom interface the exception's error information is lost. The problem appears to be in PyGatewayBase::InterfaceSupportsErrorInfo() in PyGatewayBase.cpp. It is called to determine whether the GetErrorInfo API should be used to extract an error after an error HRESULT is returned from an interface. The function is passed an IID of an interface, the code compares this to the return value of GetIID() which is always IID_IUnknown. The comparison fails, so the function returns S_FALSE and no error info is extracted. The comment above the definition of GetIID() says: // Currently this is used only for ISupportErrorInfo, // so hopefully this will never be called in this base class. // (however, this is not a rule, so we wont assert or anything!) But it appears that it is called in the base class (or at least not overloaded by anyone inheriting from it). Everything seems to work fine if you just change InterfaceSupportsErrorInfo() to always return S_OK. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 09:45 Message: Logged In: YES user_id=14198 What do you mean by "custom interface" in this context? A custom interface should be implemented such that GetIID() returns other than IUnknown. The ISupportErrorInfo semantics indicate we do need to check the IID. I'll need more specific details. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=986673&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-08 23:40:38
|
Bugs item #1039231, was opened at 2004-10-03 10:33 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1039231&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: greenmetdave (greenmtdave) Assigned to: Nobody/Anonymous (nobody) Summary: pythonwin2.4 won't install Initial Comment: I've just spent 3 hours installing/uninstalling python/pythonwin about 5 times. Hate to think what my registry looks like (WindowsXP). Bottom Line: I don't think pywin32-202.win32-py2.4 works with python-2.4a3.2. PythonWin never shows up in the Python program group, even though both installers indicated everything went OK. Also: You can't select the 'install for this user only' option when installing python, or else when you go to install pythonwin you get the error message "Can't load Python for pre-install script". I went back to python-2.2.3 with pywin32-202.win32- py2.2.exe and this worked OK. (What's with these version numbers anyway? 2.2.3 goes with 2.2?) Only now I can't delete the c:\Python24 directory because I don't have access rights to some directory named c:\Python24\Lib\test. Man, if this keeps up, I may have to go back to plan B (VBScript). ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 09:40 Message: Logged In: YES user_id=14198 This has been fixed for build 203 which should be a few days away ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1039231&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-08 23:38:24
|
Bugs item #990048, was opened at 2004-07-13 20:18 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=990048&group_id=78018 Category: installation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Kerim Borchaev (warkid) Assigned to: Nobody/Anonymous (nobody) Summary: pywin32-202.win32-py2.4.exe: Postinstall script failure. Initial Comment: This is how it fails: Creating .PTH file C:\Python24\pywin32.pth Copied pythoncom24.dll to C:\WINDOWS\System32 \pythoncom24.dll Copied pywintypes24.dll to C:\WINDOWS\System32 \pywintypes24.dll Registered: Python.Interpreter Registered: Python.Dictionary Traceback (most recent call last): File "C:\Python24\Scripts\pywin32_postinstall.py", line 313, in ? install() File "C:\Python24\Scripts\pywin32_postinstall.py", line 210, in install SetPyKeyVal("Help", None, None) File "C:\Python24\Scripts\pywin32_postinstall.py", line 97, in SetPyKeyVal root_hkey = get_root_hkey() NameError: global name 'get_root_hkey' is not defined *** run_installscript: internal error 0xFFFFFFFF *** ##################################### I've uninstalled previous version of pywin32 and Python before installing pywin32-202. I'm using Python2.4a1 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 09:38 Message: Logged In: YES user_id=14198 Will be fixed in 203 ---------------------------------------------------------------------- Comment By: Andrew Payn Barnert (payn) Date: 2004-09-09 08:12 Message: Logged In: YES user_id=96775 Until a new version comes our, here's what you can do: 1. Run an install through until it fails. 2. Go to your C:\Python24\Scripts directory, and get rid of pywin32_postinstall.{pyc,pyo} if present. 3. Edit the pywin32_postinstall.py file in that directory to unindent the definition for get_root_hkey. 4. Run the installer again, and tell it to never replace existing files. The installer will now use the hacked postinstall script, which will succeed, so it will proceed to the next step and install everything (Start Menu items, Explorer integration, etc.) properly. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2004-08-03 08:56 Message: Logged In: YES user_id=552329 FWIW, Mark knows about this problem (it resulted because the latest pywin32 came out before 2.4a1, so Mark couldn't test it properly). I believe he said on the mailing list that he's fixed the problem already, so it should be resolved in the next build. ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2004-08-03 03:29 Message: Logged In: YES user_id=599869 I received the same error. I was installing to a Windows XP SP1 with no version of Python ever installed. ---------------------------------------------------------------------- Comment By: Jaros³aw Zabie³³o (zbiru) Date: 2004-07-23 05:02 Message: Logged In: YES user_id=309001 I uninstalled previous version of Python, PythonWin and all pythonic stuff. The same problem appears for Windows 2003 Server: Creating .PTH file C:\opt\Python24\pywin32.pth Copied pythoncom24.dll to C:\WINDOWS\system32\pythoncom24.dll Copied pywintypes24.dll to C:\WINDOWS\system32\pywintypes24.dll Registered: Python.Interpreter Registered: Python.Dictionary Traceback (most recent call last): File "C:\opt\Python24\Scripts\pywin32_postinstall.py", line 313, in ? install() File "C:\opt\Python24\Scripts\pywin32_postinstall.py", line 210, in install SetPyKeyVal("Help", None, None) File "C:\opt\Python24\Scripts\pywin32_postinstall.py", line 97, in SetPyKeyVal root_hkey = get_root_hkey() NameError: global name 'get_root_hkey' is not defined *** run_installscript: internal error 0xFFFFFFFF *** ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=990048&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-08 23:00:07
|
Bugs item #1028735, was opened at 2004-09-16 04:56 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1028735&group_id=78018 Category: installation Group: None >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Trent Mick (tmick) Assigned to: Nobody/Anonymous (nobody) Summary: install error: NameError: global name 'get_root_hkey' is not Initial Comment: I got this install error when installing PyWin32 b202 onto Python 2.4a3: Creating .PTH file C:\Python24\pywin32.pth Copied pythoncom24.dll to C:\WINNT\system32\pythoncom24.dll Copied pywintypes24.dll to C:\WINNT\system32\pywintypes24.dll Registered: Python.Interpreter Registered: Python.Dictionary Traceback (most recent call last): File "C:\Python24\Scripts\pywin32_postinstall.py", line 313, in ? install() File "C:\Python24\Scripts\pywin32_postinstall.py", line 210, in install SetPyKeyVal("Help", None, None) File "C:\Python24\Scripts\pywin32_postinstall.py", line 97, in SetPyKeyVal root_hkey = get_root_hkey() NameError: global name 'get_root_hkey' is not defined *** run_installscript: internal error 0xFFFFFFFF *** My machine is Win2k, but I don't think that is relevant. Is get_root_hkey() not defined by the bdist_wininst installer? Did it used to be? This is not affecting me (a subsequent run of pywin32_postinstall.py manually worked) but I thought I should report it. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 09:00 Message: Logged In: YES user_id=14198 get_root_hkey() is a new feature in 2.4 (and I use 2.4 distutils to build *all* wininst installers). I neglected to rebuild the bdist_wininst installer with 2.4. I've tested this and it works now. Thanks. ---------------------------------------------------------------------- Comment By: Andrew Payn Barnert (payn) Date: 2004-09-16 11:17 Message: Logged In: YES user_id=96775 This is the same as bug 990048. If running the script manually doesn't work, you can edit it (move the def of get_root_hkey outside of the if) and either run it manually, or re-run the installer (and tell it to not overwrite existing files) and everything is fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1028735&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-08 21:57:47
|
Bugs item #993793, was opened at 2004-07-20 00:12 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=993793&group_id=78018 Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Niki Spahiev (nikis) Assigned to: Nobody/Anonymous (nobody) Summary: win32gui linked to missing FlashWindowEx Initial Comment: user32.FlashWindowEx is missing export function WindowsNT 4 SP6 pywin32-202 python 2.3 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 07:57 Message: Logged In: YES user_id=14198 Sorry for vanishing Tony - i'm trying to get on top of a few things :) Checking in win32gui.i; new revision: 1.51; previous revision: 1.50 ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2004-07-20 09:40 Message: Logged In: YES user_id=552329 FWIW, this is also causing problems with the latest SpamBayes releases (not sure if you're keeping track of it or not, Mark). Kenny was going to look into it, I think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=993793&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-08 17:28:04
|
Bugs item #1043205, was opened at 2004-10-08 19:28 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=1043205&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: occasional rectUndock exceptions in <interactive> Initial Comment: b201. occasionally I get: win32ui: Exception in OnNotify() handler Traceback (most recent call last): File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\docking\DockingBar.py", line 346, in OnNcHitTest elif PtInRect(self.rectUndock, pt): File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\mfc\object.py", line 18, in __getattr__ return getattr(o, attr) AttributeError: rectUndock I use docking view of <interactive> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1043205&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-08 12:51:26
|
Bugs item #1031907, was opened at 2004-09-21 23:56 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1031907&group_id=78018 Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Fedor Ezeev (ezeev) Assigned to: Nobody/Anonymous (nobody) Summary: python ActiveX scripting - GetTypeInfo() didn't work Initial Comment: I use some third party ActiveX Scripting host, named "OpenConf". OpenConf load some scripts, and show script's subroutines for user's choice. And there is visible difference between vba (or java) scripts and python scripts. Subroutines in vba scripts - are visible, but subroutines in python scripts - are not. As OpenConf's author say, this is because python's IDispatch::GetTypeInfo() return NULL, instead of real TypeInfo. Also IDispatch::GetTypeInfoCount() return 0, instead of 1. There is some simple application in attach, that demonstrate this problem. Code, that call GetTypeInfo() placed in file ascriptDlg.cpp inside CAscriptDlg:: OnInitDialog() method. This sources are compiled with MS Visual C++ 6.0 Python - 2.3.4 pywin - 202 OS - Win2000 prof sp4 russian ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-08 22:51 Message: Logged In: YES user_id=14198 GetTypeInfo and GetTypeInfoCount are optional, and that is clearly documented by IDispatch. The AXScript engine simply reuses the generic IDispatch support implemented by Python - so your bug report should say *all* Python COM objects must implement GetTypeInfo, rather than this specific AXScript case. I'm afraid that is clearly "invalid" - but marking "wont fix" anyway :) ---------------------------------------------------------------------- Comment By: Fedor Ezeev (ezeev) Date: 2004-10-08 18:48 Message: Logged In: YES user_id=969473 Sorry for my persistence. There is probably a very small numbers of AXScript engines, that need to run not a whole script, but a single macros from the script. And there is even less AXScript engines, that gives to user an ability to choice that macros to run (like OpenConf do). Moreover, VBScript and JScript correctly realize GetTypeInfo() and GetTypeInfoCount(), so those users of OpenConf, who want to write their scripts on python - write parrallel script-runner on VBScript, that do nothing but running pointed macroses. So, if you wont to do it - just say "wont fix", not "invalid", please. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-08 16:22 Message: Logged In: YES user_id=14198 It does return an empty type info - but the Dispatch object does support dynamic dispatch. ie, a browser would not be able to see them, but they can be called. OpenConf should just query the IDispatch object for whatever function name the user is trying to call. Other AXScript engines work fine with Python, as they correctly treat the typeinfo as optional. ---------------------------------------------------------------------- Comment By: Fedor Ezeev (ezeev) Date: 2004-09-21 23:58 Message: Logged In: YES user_id=969473 sorry, here is the example ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1031907&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-08 09:56:34
|
Bugs item #1037629, was opened at 2004-09-30 12:11 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1037629&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: Works For Me Priority: 9 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: Framework exception on file save after confirmation Initial Comment: b201 - See the traceback below: after that the file is saved once, but when editing more in the editor window, the document-changed-flag is always OFF (toolbar-icon-disksave grey), thus no more saving is possible/or requested !! I regularly loose code by this! >>> Traceback (most recent call last): File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\framework\editor\document.py", line 83, in OnSaveDocument self._DocumentStateChanged() File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\framework\editor\document.py", line 175, in _DocumentStateChanged pywin.debugger.currentDebugger.UpdateDocumentLineStates(self) File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 880, in UpdateDocumentLineStates doc.MarkerDeleteAll( MARKER_BREAKPOINT ) File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\document.py", line 117, in MarkerDeleteAll self.GetEditorView().SCIMarkerDeleteAll(marker) AttributeError: SCIMarkerDeleteAll win32ui: OnSaveDocument() virtual handler (<bound method SyntEditDocument.OnSaveDocument of <pywin.framework.editor.color.coloreditor.SyntEditDocument instance at 0x01333878>>) raised an exception ---------------------------------------------------------------------- >Comment By: Robert Kiendl (kxroberto) Date: 2004-10-08 11:56 Message: Logged In: YES user_id=972995 I found how to reproduce (& getting lots of exception going on): - open clean pywin - open a .py file / no more editing (dont set save-request flag) - set breakpoint somewhere (on top) - F5-run into breakpoint - when debugger stops: in that line editi something (e.g. enter SPACEs) - then immediately Ctrl-F4 to try close-window - on Save-Confirm: Cancel - ==> exceptions like above going on - Shift - F5 to stop debugging - Save file once - Edit more in the file - ===> no more change of save-request-flag (grey save toolbar button) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-08 08:26 Message: Logged In: YES user_id=14198 That is very strange, and I certainly can't reproduce it. That method does exist (in 'control.py' in that same directory) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1037629&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-08 09:39:55
|
Bugs item #1037579, was opened at 2004-09-30 10:05 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1037579&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: Often doesn't see absolute identity of path of edited files Initial Comment: Often after some programming session I have multiple instances of an edited file in the windows list with little differences in file name: Upper/lower case differences, "programme/xy..." & "progra~1/xy" differences somehow PythonWin doesn't see the identity of those files. PyWin should maybe use os.path.normcase(os.path.normpath(os.path.abspath(x))) somewhere in the framework code ? I rare cases edited code gets lost. But most times the auto-reload feature prevents more severe losses (unless I disable auto-reaload !) Robert ---------------------------------------------------------------------- >Comment By: Robert Kiendl (kxroberto) Date: 2004-10-08 11:39 Message: Logged In: YES user_id=972995 I checked to reproduce: I open a file - exited pywin - re-run - 1: select from menu/file/history 2: open-context-edit the same file from explorer => 2 windows .py / Edit command in Explorer C:\PYTHON23\pythonwin.exe "%1" (Uses DDE) the file path of all the different window instances is correctly always the same, but multiple windows with described problem: >>> a=win32ui.GetApp() >>> a.frame.MDIGetActive()[0].GetEditorView().GetDocument().GetPathName() 'C:\devel\TURBOM~1\tea_dscore.py' #switch to next window >>> a.frame.MDIGetActive()[0].GetEditorView().GetDocument().GetPathName() 'C:\devel\TURBOM~1\tea_dscore.py' #switch to next window >>> a.frame.MDIGetActive()[0].GetEditorView().GetDocument().GetPathName() 'C:\devel\TURBOM~1\tea_dscore.py' >>> ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-08 08:30 Message: Logged In: YES user_id=14198 Can you please tell me how to reproduce this - I can not. Whatever case I use to open the file, I never get the same file opened twice. I can reproduce the problem with "progra~1" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1037579&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-08 08:48:07
|
Bugs item #1031907, was opened at 2004-09-21 17:56 Message generated for change (Comment added) made by ezeev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1031907&group_id=78018 Category: None Group: None >Status: Open >Resolution: None Priority: 5 Submitted By: Fedor Ezeev (ezeev) Assigned to: Nobody/Anonymous (nobody) Summary: python ActiveX scripting - GetTypeInfo() didn't work Initial Comment: I use some third party ActiveX Scripting host, named "OpenConf". OpenConf load some scripts, and show script's subroutines for user's choice. And there is visible difference between vba (or java) scripts and python scripts. Subroutines in vba scripts - are visible, but subroutines in python scripts - are not. As OpenConf's author say, this is because python's IDispatch::GetTypeInfo() return NULL, instead of real TypeInfo. Also IDispatch::GetTypeInfoCount() return 0, instead of 1. There is some simple application in attach, that demonstrate this problem. Code, that call GetTypeInfo() placed in file ascriptDlg.cpp inside CAscriptDlg:: OnInitDialog() method. This sources are compiled with MS Visual C++ 6.0 Python - 2.3.4 pywin - 202 OS - Win2000 prof sp4 russian ---------------------------------------------------------------------- >Comment By: Fedor Ezeev (ezeev) Date: 2004-10-08 12:48 Message: Logged In: YES user_id=969473 Sorry for my persistence. There is probably a very small numbers of AXScript engines, that need to run not a whole script, but a single macros from the script. And there is even less AXScript engines, that gives to user an ability to choice that macros to run (like OpenConf do). Moreover, VBScript and JScript correctly realize GetTypeInfo() and GetTypeInfoCount(), so those users of OpenConf, who want to write their scripts on python - write parrallel script-runner on VBScript, that do nothing but running pointed macroses. So, if you wont to do it - just say "wont fix", not "invalid", please. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-08 10:22 Message: Logged In: YES user_id=14198 It does return an empty type info - but the Dispatch object does support dynamic dispatch. ie, a browser would not be able to see them, but they can be called. OpenConf should just query the IDispatch object for whatever function name the user is trying to call. Other AXScript engines work fine with Python, as they correctly treat the typeinfo as optional. ---------------------------------------------------------------------- Comment By: Fedor Ezeev (ezeev) Date: 2004-09-21 17:58 Message: Logged In: YES user_id=969473 sorry, here is the example ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1031907&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-08 07:20:23
|
Bugs item #969926, was opened at 2004-06-10 07:32 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=969926&group_id=78018 Category: win32 Group: None Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Joe Francia (scaba) Assigned to: Nobody/Anonymous (nobody) Summary: Access violation in win32file.DecryptFile Initial Comment: On both Windows 2000 and XP, decrypting an NTFS encrypted file or directory with win32file.DecryptFile() crashes Python. The decryption succeeds, but I get an access violation "instruction 0x00000000 referenced memory at 0x00000000". This happens with both normal and unicode strings passed as filenames. win32file.EncryptFile() works fine. I've attached the XP debug output. #Sample code import win32file win32file.EncryptFile('c:/temp/somefile.txt') win32file.DecryptFile('c:/temp/somefile.txt') ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-08 17:20 Message: Logged In: YES user_id=14198 This works fine for me. I've added it to the test suite. I can't find evidence of it having been fixed either - so I don't know what the story is there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=969926&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-08 06:36:58
|
Bugs item #1003415, was opened at 2004-08-05 03:21 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1003415&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Access violation in call to CoInitializeSecurity Initial Comment: I'm using pywin32 build 202 and Python 2.3.4. This call: pythoncom.CoInitializeSecurity(None, None, None, pythoncom.RPC_C_AUTHN_LEVEL_CONNECT, pythoncom.RPC_C_IMP_LEVEL_IMPERSONATE, None, 0, None) results in an access violation. Tracing through the call in a debugger, the problem is with the return from pythoncom_CoInitializeSecurity: the stack has apparently been corrupted so the function attempts to return to a NULL address. I believe the problem is in the declaration of the mypfn function pointer. Shouldn't there be a some sort of stdcall or WINAPI notation? I think both caller and callee of mypfn are popping the stack. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-08 16:36 Message: Logged In: YES user_id=14198 Fixed in rev 1.32 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1003415&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-08 06:33:33
|
Bugs item #1014149, was opened at 2004-08-23 17:50 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1014149&group_id=78018 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Alexandr Zamaraev (shura_zam) Assigned to: Nobody/Anonymous (nobody) Summary: bug invoce method old automation server Initial Comment: I have old automation server "CorelDRAW.Automation.7" Bat tlb in its installation - incorrect. I try invoce method .GetSize In Help descriptions: .GetSize .XSize = long*, .YSize = long* This VB code work correct: Set C = CreateObject("CorelDRAW.Automation.7") Dim FileName As String FileName = "C:\S01.cdr" C.FileOpen FileName C.SelectAllObjects Dim X As Long Dim Y As Long C.GetSize X, Y Bat python code not work: C = win32com.client.Dispatch('CorelDRAW.Automation.7') try: C.FileOpen(C:\S01.cdr) try: C.SelectAllObjects #If I try invoce GetSize cx, cy = 0, 0 cx, cy = C.GetSize(cx, cy) ##Error: com_error: (-2147352571, 'Type mismatch.', None, 1) #but if i try cx, cy = C.GetSize(cx, cy) ##Error: com_error: (-2147352567, 'Exception occurred.', (1000, CorelDRAW 7, 'All argiments needed', Nonr, 0, 0), None) print cx, cy finally: pass finally: C.FileExit() del C What correct invoced method GetSize ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-08 16:33 Message: Logged In: YES user_id=14198 Try running 'makepy' on the object (or just use win32com.client.gencache.EnsureDispatch() in place of Dispatch(). That should work - please reopen the bug if it doesn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1014149&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-08 06:30:21
|
Bugs item #1037579, was opened at 2004-09-30 18:05 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1037579&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None >Priority: 5 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: Often doesn't see absolute identity of path of edited files Initial Comment: Often after some programming session I have multiple instances of an edited file in the windows list with little differences in file name: Upper/lower case differences, "programme/xy..." & "progra~1/xy" differences somehow PythonWin doesn't see the identity of those files. PyWin should maybe use os.path.normcase(os.path.normpath(os.path.abspath(x))) somewhere in the framework code ? I rare cases edited code gets lost. But most times the auto-reload feature prevents more severe losses (unless I disable auto-reaload !) Robert ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-08 16:30 Message: Logged In: YES user_id=14198 Can you please tell me how to reproduce this - I can not. Whatever case I use to open the file, I never get the same file opened twice. I can reproduce the problem with "progra~1" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1037579&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-08 06:26:07
|
Bugs item #1037629, was opened at 2004-09-30 20:11 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1037629&group_id=78018 Category: pythonwin Group: None Status: Open >Resolution: Works For Me Priority: 9 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: Framework exception on file save after confirmation Initial Comment: b201 - See the traceback below: after that the file is saved once, but when editing more in the editor window, the document-changed-flag is always OFF (toolbar-icon-disksave grey), thus no more saving is possible/or requested !! I regularly loose code by this! >>> Traceback (most recent call last): File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\framework\editor\document.py", line 83, in OnSaveDocument self._DocumentStateChanged() File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\framework\editor\document.py", line 175, in _DocumentStateChanged pywin.debugger.currentDebugger.UpdateDocumentLineStates(self) File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 880, in UpdateDocumentLineStates doc.MarkerDeleteAll( MARKER_BREAKPOINT ) File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\document.py", line 117, in MarkerDeleteAll self.GetEditorView().SCIMarkerDeleteAll(marker) AttributeError: SCIMarkerDeleteAll win32ui: OnSaveDocument() virtual handler (<bound method SyntEditDocument.OnSaveDocument of <pywin.framework.editor.color.coloreditor.SyntEditDocument instance at 0x01333878>>) raised an exception ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-08 16:26 Message: Logged In: YES user_id=14198 That is very strange, and I certainly can't reproduce it. That method does exist (in 'control.py' in that same directory) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1037629&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-08 06:22:22
|
Bugs item #1031907, was opened at 2004-09-21 23:56 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1031907&group_id=78018 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Fedor Ezeev (ezeev) Assigned to: Nobody/Anonymous (nobody) Summary: python ActiveX scripting - GetTypeInfo() didn't work Initial Comment: I use some third party ActiveX Scripting host, named "OpenConf". OpenConf load some scripts, and show script's subroutines for user's choice. And there is visible difference between vba (or java) scripts and python scripts. Subroutines in vba scripts - are visible, but subroutines in python scripts - are not. As OpenConf's author say, this is because python's IDispatch::GetTypeInfo() return NULL, instead of real TypeInfo. Also IDispatch::GetTypeInfoCount() return 0, instead of 1. There is some simple application in attach, that demonstrate this problem. Code, that call GetTypeInfo() placed in file ascriptDlg.cpp inside CAscriptDlg:: OnInitDialog() method. This sources are compiled with MS Visual C++ 6.0 Python - 2.3.4 pywin - 202 OS - Win2000 prof sp4 russian ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-08 16:22 Message: Logged In: YES user_id=14198 It does return an empty type info - but the Dispatch object does support dynamic dispatch. ie, a browser would not be able to see them, but they can be called. OpenConf should just query the IDispatch object for whatever function name the user is trying to call. Other AXScript engines work fine with Python, as they correctly treat the typeinfo as optional. ---------------------------------------------------------------------- Comment By: Fedor Ezeev (ezeev) Date: 2004-09-21 23:58 Message: Logged In: YES user_id=969473 sorry, here is the example ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1031907&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
