pywin32-bugs Mailing List for Python for Windows Extensions (Page 32)
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...> - 2010-08-30 02:46:10
|
Bugs item #2989351, was opened at 2010-04-19 23:14 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2989351&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: DDE buffer size Initial Comment: I am attempting to communicate with a program called MPManager. The program has setup a DDE server for me to connect to. I am able to connect to it and perform a few actions with the server. When I attempt to execute the string: "LoadImage|1|4|C:\90A0043C.hex|CY8C27243|3.0|0|0" over the DDE interface, all the server receives is: "LoadImage|1|4|C:\90A0043C.hex|C" Can you help me to get this working? ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-30 12:46 Message: Sorry, not enough info to call this a bug in pywin32 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2989351&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-30 02:44:57
|
Bugs item #2993640, was opened at 2010-04-29 01:04 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2993640&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 Private: No Submitted By: ferrata (ferrata) Assigned to: Nobody/Anonymous (nobody) Summary: win32api.GetFullPathName converts unicode to non-unicode Initial Comment: win32api.GetFullPathName converts unicode string to non-unicode string Environment: python 2.5; pywin32-214.win32-py2.5.exe CODE FOR REPRODUCE: import win32api s = u'C:\\test' print repr( s ) print repr( win32api.GetFullPathName( s ) ) OUTPUT: u'C:\\test' 'C:\\test' -> BUG: string has been converted EXPECTED OUTPUT: u'C:\\test' u'C:\\test' ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-30 12:44 Message: Treating this as a doc bug - added a pointer to win32file.GetFullPathName in the docs. Checking in win32/src/win32apimodule.cpp; new revision: 1.103; previous revision: 1.102 ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2010-05-03 22:27 Message: win32file.GetFullPathName calls either the char or unicode API function depending on the input type, and returns the same type. The one in win32api will probably go away at some point, or just become an alias for the function in win32file when we go to an all-unicode build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2993640&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-30 02:41:06
|
Bugs item #3028647, was opened at 2010-07-13 07:24 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3028647&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: pythonwin keeps opening new processes (no dde on Win64) Initial Comment: Every time I run "pythonwin foo", PythonWin opens a new process and a new window. Previously it would open "foo" in any existing process, MDI style. I'm not sure what the culprit is, since I just installed PythonWin build 214. I also just started running Windows 7 64bit (I was previously on 32bit). ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-30 12:41 Message: Cool - I reenabled it and it works for me too. Checking in setup.py; new revision: 1.112; previous revision: 1.111 ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2010-07-21 03:19 Message: Good catch, apparently it just needs to be reenabled for x64 builds. The only changes I had in the project file were some irrelevant linker options. ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2010-07-20 09:33 Message: I got it to work! All I had to do was this: --- ..\pywin32.orig\setup.py 2010-07-19 16:22:14.034760000 -0700 +++ setup.py 2010-07-19 16:31:44.885410800 -0700 @@ -1837,7 +1837,7 @@ optional_headers=['afxres.h']), WinExt_pythonwin("dde", pch_header="stdafxdde.h", depends=["win32/src/stddde.h", "pythonwin/ddemodule.h"], - platforms=['win32'], + platforms=['win32', 'win-amd64'], optional_headers=['afxres.h']), ] # win32ui is large, so we reserve more bytes than normal ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2010-07-20 09:03 Message: What modifications need to be made to the project file? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2010-07-13 19:32 Message: The dde module will build for amd64 using a modified project file, but I haven't tried to integrate the necessary changes into the setup script yet. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-07-13 10:34 Message: This is because the DDE module hjasn't been ported to the 64bit world. It may be fixed in the future (probably by re-implementing the functionality using something other than DDE), but I really wouldn't hold my breath for me to get a round tuit for this specific problem... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3028647&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-30 02:38:17
|
Bugs item #2994205, was opened at 2010-04-30 00:51 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2994205&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: Invalid Priority: 5 Private: No Submitted By: adamhj (adamhj) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer behave strangely in win32 service Initial Comment: i found that when i run a SimpleXMLRPCServer instance in a windows service(using pywin32 win32service module), the server will occasionally refuse xml rpc request. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-30 12:38 Message: Python has the same issue in many contexts, not only services (eg, in a GUI app with no console attached). There is an open Python bug on this, and IMO that is where it needs to be fixed. Thanks for the report though! ---------------------------------------------------------------------- Comment By: adamhj (adamhj) Date: 2010-04-30 12:17 Message: ok, i think i have found where is the problem. after found this problem using pywin32 service module, i turned to use a wrapper service program (written in c# by me) to run my python script, and then found similar problem, the difference is that when using my wrapper service program, after certain number of client call, the xmlrpc port hangs(any further client request is accepted but no response come out and the tcp connection is not closed) the wrapper service program is set to redirect stdout and stderr, but i'm not sure if these codes can work correctly so i disable the pipe redirection of the wrapper service and restart the service, to my surprise, everything works right now. then i recall that the SimpleXmlRpcServer module have a logRequests parameter which is true by default will print a line of log message to stdout for each client call, this may be will the problem start. so i set logRequests to False in the test service script(the server.py i uploaded previously) and run the test, no problem happens this time. so this issue is caused by stdout output in a python script run as a windows service, maybe some error is raised when the stdout buffer if full and cause this unexpected behavior. still i am thinking this as a small bug in pywin service module, as it should properly deal with the stdout/stderr of running service script to avoid this problem. ---------------------------------------------------------------------- Comment By: adamhj (adamhj) Date: 2010-04-30 01:20 Message: and my testing environment is python 2.6.4, pywin32-214.win32-py2.6, windows 2003 server(x86) with sp2 ---------------------------------------------------------------------- Comment By: adamhj (adamhj) Date: 2010-04-30 01:16 Message: sorry, i'm using sf tracker for the first time and mistake the post button for upload attachment button. the bad response behavior (of SimpleXMLRPCServer in service) does not happen everytime but appears regularly, it seems it will occurs every a few calls the attachment i uploaded yet is my testing script of the server side, and the client side is a simple loop: #---------------------------------------------------------------------- #client.py import xmlrpclib s = xmlrpclib.ServerProxy('http://localhost:8000') while True: print s.func0() #---------------------------------------------------------------------- way to product the bug: 1. install server.py as windows service: python server.py install 2. start the service in service manager 3. run client.py in console: python client.py > output.txt and after a few calls, the error is raised: Traceback (most recent call last): File "D:\test\xmlrpcsvc\client.py", line 6, in <module> print s.func0() File "D:\Python26\lib\xmlrpclib.py", line 1199, in __call__ return self.__send(self.__name, args) File "D:\Python26\lib\xmlrpclib.py", line 1489, in __request verbose=self.__verbose File "D:\Python26\lib\xmlrpclib.py", line 1243, in request headers xmlrpclib.ProtocolError: <ProtocolError for localhost:8000/RPC2: -1 > i changed func0 to func1,2,3 to test different parameter type and size, and all output.txt have exactly 37 lines, so it seems that this error will happen every 38 client calls sniffer shows that in the failed session, the server will close the connection(TCP FIN) just after receive client request, without sending any response data or error info this behavior only exists in windows service process, when running a SimpleXMLRPCServer from console script, this does not happen, so i think maybe this is some issue in pywin32 service module ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2994205&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-30 02:35:18
|
Bugs item #3033529, was opened at 2010-07-23 22:38 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3033529&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 Private: No Submitted By: Jason R. Coombs (jaraco) Assigned to: Nobody/Anonymous (nobody) Summary: error in GetClipboardData - handle invalid on GlobalLock Initial Comment: A long time ago, a user reported problems getting a bitmap from the Windows clipboard: http://mail.python.org/pipermail/python-win32/2001-May/000056.html The tail end of that thread indicates that the patch was applied, but I see in the current code base, the NotImplementedError is not raised for CF_BITMAP. Instead, if I get the original error if I attempt to get a bitmap from the clipboard: # after hitting PrtScn to put a bitmap on the clipboard >>> import win32clipboard as wclip >>> wclip.OpenClipboard() >>> result = wclip.GetClipboardData(wclip.CF_BITMAP) Traceback (most recent call last): File "<stdin>", line 1, in <module> pywintypes.error: (6, 'GetClipboardData:GlobalLock', 'The handle is invalid.') If win32clipboard doesn't support the CF_BITMAP for GetClipboardData, it should provide a useful message indicating such, rather than a surprising message about an invalid handle. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-30 12:35 Message: Added support for CF_BITMAP and a simple test clipboard viewer. Checking in src/win32clipboardmodule.cpp; new revision: 1.27; previous revision: 1.26 Checking in Demos/win32clipboard_bitmapdemo.py; initial revision: 1.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3033529&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-30 00:57:36
|
Patches item #1305342, was opened at 2005-09-27 09:57 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1305342&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 Private: No Submitted By: Michael Dubner (dubnerm) Assigned to: Mark Hammond (mhammond) Summary: LocalService support Initial Comment: With this module you can create out-of-process COM server in NT Service. Usage: class MyCOMObject1: _reg_clsid_ = ... _reg_... class MyCOMService(localservice.LocalCOMService): _svc_com_servers_ = [MyCOMObject1, ...] if __name__=='__main__': localservice.ProcessCommandLine(MyCOMService) ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-30 10:57 Message: No word from submitter. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-07-12 22:41 Message: Logged In: YES user_id=14198 Just checking if this is still alive... ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-10-11 11:53 Message: Logged In: YES user_id=14198 Thanks Michael. A few comments: * Could you please change 'Granted for inclusion in pywin32 (https://sourceforge.net/projects/pywin32/).' to something like 'Released under the terms of the pywin32 license' or something - that makes it clear that people who are currently free to redistribute pywin32 components are also free to redistribute this. * Is there any reason we can't leverage the existing service command-line support? It seems a shame to clone so much code. I'd be willing to consider changing win32serviceutil so we can take advantage of customized command-line options etc. The 'optparse' module is a better choice than getopt these days. * Its not clear why 'serve' is needed, and there aren't any comments for it. * Why are InitHook() functions rather than just class members? Thanks, Mark ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2005-09-27 18:22 Message: Logged In: YES user_id=39274 Sorry - forgot to click on checkbox ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-09-27 11:59 Message: Logged In: YES user_id=14198 Did you mean to include an attachment? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1305342&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-30 00:56:40
|
Patches item #1806435, was opened at 2007-10-03 02:17 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1806435&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 Private: No Submitted By: Robert Langmeier (rlangmeier) Assigned to: Nobody/Anonymous (nobody) Summary: registring a win32com server with non admin privilges only Initial Comment: I produced this patch to be able to register and use a COM server with insufficient privileges. A little explanation: - As a non admin user, you cannot write HKEY_CLASSES_ROOT, but you can register a COM server into HKEY_CURRENT_USER - HKEY_CLASSES_ROOT is a consolidated view of HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER (see MSDN) - The client can always read the registry keys in HKEY_CLASSES_ROOT It would be great if it can be integrated in a future build. Some check has to be done for parts i'm not using. Registring and unregistring "Standard" servers is correct and functionning. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-30 10:56 Message: we can now register either way I believe. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2008-07-04 12:13 Message: Logged In: YES user_id=14198 Originator: NO FWIW, VS 2008 appears to use "regsvr32 /s /i:user dllname.dll" when you select the "register per user" option in their IDE UI (I can't recall the exact spelling of the UI option). It's undocumented best I can tell, but I stumbled across how IronPython checks for this, and it worked! The code a C++ DLL needs to support this in MSVS is below (from Tamarin): it makes sense that we do the same to support this functionality? STDAPI DllInstall(BOOL bInstall, LPCWSTR pszCmdLine) { HRESULT hr = E_FAIL; // MSVC will call "regsvr32 /i:user" if "per-user registration" is set as a // linker option - so handle that here (its also handle for anyone else to // be able to manually install just for themselves.) static const wchar_t szUserSwitch[] = L"user"; if (pszCmdLine != NULL) { if (_wcsnicmp(pszCmdLine, szUserSwitch, _countof(szUserSwitch)) == 0) { AtlSetPerUserRegistration(true); // But ATL still barfs if you try and register a COM category, so // just arrange to not do that. _AtlComModule.m_ppAutoObjMapFirst = _AtlComModule.m_ppAutoObjMapLast; } } if (bInstall) { hr = DllRegisterServer(); ... ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2008-05-05 21:00 Message: Logged In: YES user_id=14198 Originator: NO Note that _get_classe_hkey() can probably go - just checking if you can open the key with KEY_ALL_ACCESS should work. Note too that the CVS version of register.py takes a different approach - it attempts to elevate and retry. This means we would probably need to add a new cmdline option to specify which behaviour you desire. Finally, it would be great if you can send me a "diff" which compares the old and new files (use "diff -u") - otherwise it is very hard to determine what changes you made. Thanks ---------------------------------------------------------------------- Comment By: Robert Langmeier (rlangmeier) Date: 2007-10-12 07:00 Message: Logged In: YES user_id=75471 Originator: YES just corrected a bug in _get_classe_hkey and modified RegisterServer File Added: register-patch.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1806435&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-30 00:54:08
|
Patches item #2001993, was opened at 2008-06-25 05:40 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2001993&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Trent Mick (tmick) Assigned to: Nobody/Anonymous (nobody) Summary: patch to improve "find_platform_sdk_dir" in setup.py Initial Comment: The latest Platform SDK (the "Microsoft Windows Vista SDK") changes the directory and registry keys that identify where it is installed. This updates the method that finds that in "setup.py" to find it. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-30 10:54 Message: I think Trent did check this in. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2008-06-25 08:22 Message: Logged In: YES user_id=14198 Originator: NO The order is largely arbitrary so I'm happy for you to just go for it if you are confident it works. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2008-06-25 07:16 Message: Logged In: YES user_id=34892 Originator: YES I hadn't noticed the addition of "# 4. Vista's SDK" in an earlier change to setup.py. I guess that match this patch a change to *prefer* using that SDK if it is installed as well as older ones in the older "C:\Program Files\Microsoft Platform SDK" or "C:\Program Files\Microsoft SDK" ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2008-06-25 07:16 Message: Logged In: YES user_id=14198 Originator: NO Thanks Trent - please check it in! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2001993&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-30 00:52:32
|
Patches item #2630059, was opened at 2009-02-23 23:53 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2630059&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Michael Neuroth (mindia) Assigned to: Mark Hammond (mhammond) Summary: patch for genpy.py to improve support for constants class Initial Comment: With the build 213 I had problems with a COM class when using genpy.py. The COM class has no constants defined but the method Generator.do_generate() in the genpy.py file had problems to generate a valid python class. The following construct was generated: ... MajorVersion = 1 MinorVersion = 1 LibraryFlags = 8 LCID = 0x0 class constants: from win32com.client import DispatchBaseClass class IMyInterface(DispatchBaseClass): """IMyInterface Interface""" ... Unfortunately this code is not a valid python code. I appied the following patch to genpy.py which helped me to fix this problem. Maybe a similar patch could be included into the original source code? ======= Modifications in genpy.py ========== def do_generate(self): ... # Generate the constants and their support. if enumItems: iTotalCount = 0 # PATCH print >> stream, "class constants:" items = enumItems.values() items.sort() for oleitem in items: iTotalCount += oleitem.WriteEnumerationItems(stream) # PATCH self.progress.Tick() if iTotalCount==0: # PATCH print >> stream, "\tpass" # PATCH print >> stream ... class EnumerationItem(build.OleItem, WriteableItem): ... def WriteEnumerationItems(self, stream): enumName = self.doc[0] iItemCount = 0 # PATCH # Write in name alpha order names = list(self.mapVars.keys()) names.sort() for name in names: entry = self.mapVars[name] vdesc = entry.desc if vdesc[4] == pythoncom.VAR_CONST: val = vdesc[1] if sys.version_info <= (2,4) and (isinstance(val, int) or isinstance(val, long)): # in python 2.3, 0x80000000L == 2147483648 if val==2147483648: # == 0x80000000L - special case for 2.3... use = "0x80000000L" # 'L' for future warning elif val > 2147483648 or val < 0: # avoid a FutureWarning use = long(val) else: use = hex(val) else: use = repr(val) print >> stream, "\t%-30s=%-10s # from enum %s" % \ (build.MakePublicAttributeName(name, True), use, enumName) iItemCount += 1 # PATCH return iItemCount # PATCH ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-30 10:52 Message: Thanks! Checking in genpy.py; new revision: 1.68; previous revision: 1.67 ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-02-25 09:27 Message: Right - typedefs also appear there, which explains things. I certainly do want pywin32 to be robust against *real* problems - I just needed to understand this one well enough to convince myself it was real :) I'll apply your patch, thanks. ---------------------------------------------------------------------- Comment By: Michael Neuroth (mindia) Date: 2009-02-24 23:29 Message: Sorry, I missed a line of code: typedef [public , custom(F914481D-9C62-4B43-9340-E9B2E6252E5F, 1) ] unsigned long ULONG_PTR; ---------------------------------------------------------------------- Comment By: Michael Neuroth (mindia) Date: 2009-02-24 23:27 Message: The COM object is until now only used internally. I found out that the following definition in the IDL file caused the problems: [id(7), helpstring("method getNumberInfos")] HRESULT getNumberInfos([out, retval] SIZE_T* number); This statement produced in the type library (I used OLEView to display this information) this data: typedef [public , custom(F914481D-9C62-4B43-9340-E9B2E6252E5F, 1) ] When I replaced the SIZE_T type in the method the problematic data in the type library disappeared and genpy.py has no problems at all to generate a valid python file. I am not sure if the type SIZE_T is a valid COM type. The type SIZE_T is defined in the header file BaseTds.h as follows: typedef ULONG_PTR SIZE_T, *PSIZE_T; And the COM object could be created with MS Visual Studio 2008 without errors. Isn't it a good idea to make the genpy.py code robust against 'unclean' (but valid) input? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-02-24 09:47 Message: What COM object is this? I'm interested to know how we are getting enumeration items, but ending up with no constants. In other words, the correct fix may be elsewhere - to have enumItems only have real items with constants and the existing check for enumItems to continue doing its job. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2630059&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-30 00:43:14
|
Patches item #2731813, was opened at 2009-04-05 04:39 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2731813&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Florian Höch (fhoech) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to add win32api.GetICMProfile to pywin32 build 213 Initial Comment: This patch allows to get the ICM profile filename of a given device context via win32api.GetICMProfile(hdc) ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-30 10:43 Message: Sorry for the delay but this patch has a couple of minor issues: * Function pointers are declared but not used. It seems you can probably get away with avoiding them as MSDN says these functions are available in early windows versions. * The implementation should raise a win32api error if it fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2731813&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-30 00:37:51
|
Feature Requests item #2802102, was opened at 2009-06-06 09:43 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=2802102&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: 1 Private: No Submitted By: Vernon Cole (kf7xm) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot build pywin32 on Vista using VC++ Express Edition Initial Comment: I always try to use only free stuff -- especially if I have to buy things from Micro$oft -- so, just as an experiment, I attempted to build pywin32 (current CVS as of 2009-06-05) using the current free compiler on my Vista laptop. It worked much better than I expected, but setup.py finally crashed with: v v v v v Microsoft Windows [Version 6.0.6002] ... C:\pywin32>c:\python26\python.exe setup.py build Building pywin32 2.6.213.1 running build running build_py running build_ext Found version 0x600 in C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\SDK DDKVER.H building 'perfmondata' extension mc.exe -h win32\src\perfmon -r build\temp.win32-2.6\Release\win32\src\perfmon wi n32\src\perfmon\PyPerfMsgs.mc error: command 'mc.exe' failed: No such file or directory C:\pywin32> ^ ^ ^ ^ ^ Environment: Vista Home Basic with SP2 CPython 2.6.2 Microsoft Visual C++ 2008 Express Edition with SP1 - ENU Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729 Microsoft Windows SDK for Visual Studio 2008 Headers and Libraries Microsoft Windows SDK for Visual Studio 2008 SP1 Express Tools for .NET Framework - enu Microsoft Windows SDK for Visual Studio 2008 SP1 Express Tools for Win32 -- Vernon Cole ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-30 10:37 Message: Moving to feature requests - there is no patch attached - was that the intent? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=2802102&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-30 00:35:26
|
Patches item #2857646, was opened at 2009-09-13 04:18 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2857646&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Christopher Smith (smichr) Assigned to: Nobody/Anonymous (nobody) Summary: all trailing space stripped on enter Initial Comment: AutoIndent.py strips trailing space UNLESS the line happens to contain only space. This patch makes it strip that space, too. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-30 10:35 Message: Thanks! Checking in idle/AutoIndent.py; new revision: 1.10; previous revision: 1.9 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2857646&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-27 09:05:38
|
Patches item #3048829, was opened at 2010-08-19 20:02 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3048829&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Mark Hammond (mhammond) Summary: finally supports non-US keyboards (CallTips etc) Initial Comment: comfort for the whole world .. patch for keycodes.py in pywin/scintilla ---------------------------------------------------------------------- >Comment By: kxroberto (kxroberto) Date: 2010-08-27 11:05 Message: there is no new file attached so far ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-08-27 08:12 Message: Oops - I means "." character for attribute expansion ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-08-27 08:10 Message: Thanks for the patch. However, I think it was still incomplete in a few areas and I finally dug into this a little more (there is an over 5 year old bug open on this issue and I've attempted a fix more than once.) I'm attaching a patch that uses MapVirtualKey and VkKeyScan, and removes that horrible offset table and I think it works. Using a french keyboard layout I see the calltips and the ',' character working as expected. If you can, please have a go and see if it works OK for you. Note that it requires a new win32api to work, so if you don't build from sources, please send me your python version and email addy and I'll send you a newer version. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3048829&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-27 07:37:52
|
Patches item #2813056, was opened at 2009-06-27 08:58 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2813056&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: markt (metolone) Assigned to: Nobody/Anonymous (nobody) Summary: fix for interactive colorization problem Initial Comment: Steps to reproduce: 1. Open pythonwin.exe and make sure interactive window is visible. 2. In the interactive window, press CTRL-A, DEL to clear the window and hit Enter a few times. The first line will be a blue proportional font like the initial banner. 3. Open a python script that generates a few lines of output. 4. In the interactive window, press CTRL-A, DEL, then run run the script. The output will be the banner font. This patch corrects this problem. Hope you like it. It was generated from the 2.6 -213 release and works on win32 and win64 versions. I tested on 3.0 -213 release as well. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-27 17:37 Message: Thanks! Checking in CHANGES.txt; new revision: 1.61; previous revision: 1.60 Checking in pythonwin/pywin/framework/interact.py; new revision: 1.25; previous revision: 1.24 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2813056&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-27 07:33:02
|
Patches item #3002383, was opened at 2010-05-17 00:13 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3002383&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nikolay Igotti (olonho) Assigned to: Nobody/Anonymous (nobody) Summary: amd64 COM callbacks Initial Comment: Patch to generate COM wrappers on 64-bit windows. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-27 17:33 Message: Awesome, thanks! Checking in CHANGES.txt; new revision: 1.60; previous revision: 1.59 Checking in com/win32com/universal.py; new revision: 1.15; previous revision: 1.14 Checking in com/win32com/src/univgw.cpp; new revision: 1.14; previous revision: 1.13 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3002383&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-27 06:54:03
|
Patches item #2896067, was opened at 2009-11-12 04:25 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2896067&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Sridhar Ratnakumar (nearfar) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for a successful "setup.py --prefix" Initial Comment: Since APy build scripts run "setup.py install --prefix=<path to image dir>", we should use distutils' self.prefix (instead of sys.prefix - that points to the Python build directory) when finding previously installed file. Index: pywin32/setup.py =================================================================== --- pywin32/setup.py.orig 2009-11-10 17:00:30.000000000 -0800 +++ pywin32/setup.py 2009-11-10 17:00:49.000000000 -0800 @@ -1283,7 +1283,7 @@ if not self.dry_run and not self.root: # We must run the script we just installed into Scripts, as it # may have had 2to3 run over it. - filename = os.path.join(sys.prefix, "Scripts", "pywin32_postinstall.py") + filename = os.path.join(self.prefix, "Scripts", "pywin32_postinstall.py") if not os.path.isfile(filename): raise RuntimeError("Can't find '%s'" % (filename,)) print "Executing post install script..." ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-27 16:54 Message: Thanks! Checking in setup.py; new revision: 1.111; previous revision: 1.110 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2896067&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-27 06:50:59
|
Feature Requests item #1527583, was opened at 2006-07-24 17:11 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1527583&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 Private: No Submitted By: david arnold (dja) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for WSAEnumNetworkEvents Initial Comment: WSAEnumNetworkEvents is used to determine the state of a socket after it has signaled an Event to indicate that its state has changed. Its useful for integrating sockets with other objects (handles, events, etc) in a main loop. Currently, WSAEventSelect is supported, as is WSAAsyncSelect (which is used to direct state change notifications to a Window), but not WSAEnumNetworkEvents. It'd be great if this could be added ... ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-27 16:50 Message: Just checked in - thanks to zseil! - will be in build 215 ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2010-06-30 00:26 Message: See patch #3022832: https://sourceforge.net/tracker/?func=detail&aid=3022832&group_id=78018&atid=551956 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1527583&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-27 06:49:35
|
Patches item #3022832, was opened at 2010-06-29 23:55 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3022832&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: Accepted Priority: 5 Private: No Submitted By: Ziga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: add win32File.WSAEnumNetworkEvents Initial Comment: WSAEventSelect is not very useful without the accompanying WSAEnumNetworkEvents, which reports the exact network events that caused the event associated with a socket to become signaled. This patch adds it. The added function reports network events as a dict, which deviates slightly from the winapi interface, but is more convenient. The patch includes some tests that show the intended usage of this function. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-27 16:49 Message: Awesome - thanks very much. I had to change a few places in the tests for what seemed to be simple timing issues, but the code itself looks great, so I checked it in with the modified tests - please let me know if you think I screwed anything up. Checking in CHANGES.txt; new revision: 1.59; previous revision: 1.58 Checking in win32/src/win32file.i; new revision: 1.110; previous revision: 1.109 Checking in win32/test/test_win32file.py; new revision: 1.34; previous revision: 1.33 ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2010-06-30 00:28 Message: This would also close feature request #1527583: https://sourceforge.net/tracker/?func=detail&aid=1527583&group_id=78018&atid=551957 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3022832&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-27 06:12:06
|
Patches item #3048829, was opened at 2010-08-20 04:02 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3048829&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Mark Hammond (mhammond) Summary: finally supports non-US keyboards (CallTips etc) Initial Comment: comfort for the whole world .. patch for keycodes.py in pywin/scintilla ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-27 16:12 Message: Oops - I means "." character for attribute expansion ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-08-27 16:10 Message: Thanks for the patch. However, I think it was still incomplete in a few areas and I finally dug into this a little more (there is an over 5 year old bug open on this issue and I've attempted a fix more than once.) I'm attaching a patch that uses MapVirtualKey and VkKeyScan, and removes that horrible offset table and I think it works. Using a french keyboard layout I see the calltips and the ',' character working as expected. If you can, please have a go and see if it works OK for you. Note that it requires a new win32api to work, so if you don't build from sources, please send me your python version and email addy and I'll send you a newer version. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3048829&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-27 06:10:33
|
Patches item #3048829, was opened at 2010-08-20 04:02 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3048829&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kxroberto (kxroberto) >Assigned to: Mark Hammond (mhammond) Summary: finally supports non-US keyboards (CallTips etc) Initial Comment: comfort for the whole world .. patch for keycodes.py in pywin/scintilla ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-27 16:10 Message: Thanks for the patch. However, I think it was still incomplete in a few areas and I finally dug into this a little more (there is an over 5 year old bug open on this issue and I've attempted a fix more than once.) I'm attaching a patch that uses MapVirtualKey and VkKeyScan, and removes that horrible offset table and I think it works. Using a french keyboard layout I see the calltips and the ',' character working as expected. If you can, please have a go and see if it works OK for you. Note that it requires a new win32api to work, so if you don't build from sources, please send me your python version and email addy and I'll send you a newer version. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3048829&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-26 09:48:33
|
Patches item #3048851, was opened at 2010-08-19 20:15 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3048851&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: ctrl-enter-debug-into-interactive-statement.patch Initial Comment: quickly debug into things from the interactive. Ctrl+Enter = Enter with control ... ---------------------------------------------------------------------- >Comment By: kxroberto (kxroberto) Date: 2010-08-26 11:48 Message: would be also fine, main thing its available. But in the interactive I'm/will rarely using any of Ctrl-Shift, Ctrl-Enter - don't know a real use case. As it is not in the "Keyboard Bindings" doc, perhaps nobody else knows. (in Editor the use of Shift-Enter is to go back to the 1st columon - as I'am aware only now; I use Backspace as a habit) In Interactive personally I use Staterment-Debugger / Ctrl+Enter since years very often, maybe similar often as the plain Enter, as I'm often trying selected funktions out ad-hoc in debugger immediately when there are problems. So I may add this shorter binding personally in the .cfg. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-08-26 03:50 Message: I'm a little concerned ctrl+enter may already be used by people in place of shift-enter, and that starting the debugger on that key combination may lead to unexpected surprised. How would you feel about ctrl+shift+enter? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3048851&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-26 09:31:23
|
Patches item #3048869, was opened at 2010-08-19 20:53 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3048869&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: F1 auto keyword help; Interact with edit lines Initial Comment: F1 keyword help F1: Python Help Ctrl+F1: PythonWin Alt+F1: MSDN Numpy & wx quick debugging and trying things out (Ctrl-Enter Debugger can be used also after that:) Ctrl-K : interact with marked editor lines in Interactive (in __main__) Ctrl-E : exectued marked editor lines in Interactive (in __main__) (works also while in debugger;) ---------------------------------------------------------------------- >Comment By: kxroberto (kxroberto) Date: 2010-08-26 11:31 Message: well, keyword help code perhaps could go permanently to help.py or the editor code. because probably there remain mainly only 2 kind of actions: keyword -> helpfile, keyword -> URL-templatestring "http:/....xy=%s". the only special handling, keyword modification "wx%s" could be also enabled by a predefined scheme. For the rest a (short) .cfg handler could still use the functions from pywin.framework.help. for (optional) help files a keyword help key could be set together with the help file (.chm or ULR) in registry, valueName/value like default="http://social.msdn.microsoft.com/Search/en-US/?Query=%s" keyword_help_key=Alt+F1 WX-C-Help.. keyword_help_key=F12 keyword_help_keyword="wx%s" ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-08-25 09:59 Message: Thanks! But I think I'd prefer to see most of the help functionality in pywin/framework/help.py which already has support for the help menus. If we have support for the keyboard for these new help files, the menu should probably get them too (which the short-cut keys included) - but that might make things ugly given many people may not have wx or numpy installed. I wonder how hard it would be to refactor some of that and only show menu items if the help file is installed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3048869&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-26 09:07:04
|
Patches item #3048854, was opened at 2010-08-19 20:22 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3048854&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: mdi_pychecker_update.patch Initial Comment: few things didn't work smooth ---------------------------------------------------------------------- >Comment By: kxroberto (kxroberto) Date: 2010-08-26 11:07 Message: the first part "--only" is just a pychecker default option to test/report errors only of code in the explicitely checked file(s) - reasonable for a pychecker run from IDE, and generally. (most python/3rd party *-imported modules (import * from xyz) otherwise cause a lot of less relevant warnings, as only few people use pychecker/pylint. ) yes, the second part is needless if the other patch was accepted ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-08-25 09:52 Message: I just changed scriptutils.JumpToDocument to return None on error and your recent patch changed it to return the view object on success - so I think the second part of this patch is no longer needed. What is the first part for? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3048854&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-26 02:00:57
|
Patches item #3048850, was opened at 2010-08-20 04:10 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3048850&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: runs PYTHONSTARTUP (as any comfortabl interactive should do) Initial Comment: -> framwork/interact.py ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-26 12:00 Message: Thanks! Applied with an exception handler. Checking in CHANGES.txt; new revision: 1.57; previous revision: 1.56 Checking in pythonwin/pywin/framework/interact.py; new revision: 1.24; previous revision: 1.23 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3048850&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-08-26 01:50:17
|
Patches item #3048851, was opened at 2010-08-20 04:15 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3048851&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: ctrl-enter-debug-into-interactive-statement.patch Initial Comment: quickly debug into things from the interactive. Ctrl+Enter = Enter with control ... ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-08-26 11:50 Message: I'm a little concerned ctrl+enter may already be used by people in place of shift-enter, and that starting the debugger on that key combination may lead to unexpected surprised. How would you feel about ctrl+shift+enter? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3048851&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
