From timr at probo.com Fri Oct 1 00:04:04 2010 From: timr at probo.com (Tim Roberts) Date: Thu, 30 Sep 2010 15:04:04 -0700 Subject: [python-win32] win32api: How to send WM_SIZING to a Window In-Reply-To: <4CA5035A.2060805@gmx.net> References: <4CA4CC97.60700@gmx.net> <4CA4D378.1030102@probo.com> <4CA4F70B.9000902@gmx.net> <4CA4FD54.8080502@probo.com> <4CA5035A.2060805@gmx.net> Message-ID: <4CA50954.70603@probo.com> Andreas Holtz wrote: > The COM implementation is "suboptimal". There are a lot of features you can not access via COM. > Don't ask me why. Due to this suboptimal behaviour, I need this stupid hack. > > The question is now, what is a correct WM_SIZING-message? > With a string for the rect, a RECT-object, two words or something else? > It can't be possible that I am the first person sending a WM_SIZING-message to a window in python? You need to send a pointer to a list of four 32-bit integers. If it were me, I'd use the struct module to convert the coordinates to a string, and send the string. import struct rect = struct.pack('4I', 0, 0, 100, 100) win32api.SendMessage(hndl, win32con.WM_SIZING, win32con.WMSZ_BOTTOM, rect ) However, there are issues here. You are supposed to send the screen coordinates of the point that is being dragged. In this case, that would be a point along the bottom edge of the window. Further, to clear this "sizing in progress" mode, you need to send a WM_SIZE, where you'll need to send the size of the window. So, there may be more to this than you think. It should be fun to experiment, however. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From rays at blue-cove.com Fri Oct 1 00:40:45 2010 From: rays at blue-cove.com (RJ) Date: Thu, 30 Sep 2010 15:40:45 -0700 Subject: [python-win32] Python DDE and multiple DDE servers? Message-ID: <6.2.3.4.2.20100930154039.049f5ef8@rjs.org> I need to run both a Python DDE server and Python DDE client on the same machine (separate programs). Is there a reason why when I Create() the client: server.Create("PyVibeSurvey") I get: dde.error: The server could not be created for the client program? When the same client connects to the legacy DDE application (C++) it is OK. The client can also Create() if no other server is running. The servers have different names, of course. I had installed pywin32-214.win32-py2.6.exe Best, Ray S -------------- next part -------------- An HTML attachment was scrubbed... URL: From python at bdurham.com Fri Oct 1 01:06:58 2010 From: python at bdurham.com (python at bdurham.com) Date: Thu, 30 Sep 2010 19:06:58 -0400 Subject: [python-win32] Simple Windows progressbar dialog (like messagebox) via Win32 API? In-Reply-To: <4CA4D500.2080505@probo.com> References: <1285862956.22785.1397713153@webmail.messagingengine.com> <4CA4D500.2080505@probo.com> Message-ID: <1285888018.26295.1397770951@webmail.messagingengine.com> Tim, > If you look in site-packages\pythonwin\pywin\Demos, you'll find "progressbar.py". This is a Python wrapper around the MFC CProgressCtrl class. You might be able to adapt that to do what you need, although I'm not sure MFC is any lighter weight than Tkinter. I'm already using the Python Win32 extensions, so the progressbar.py example might be a good fit for me. I tested it from the command line on Windows 7 and was surprised that the progressbar control looked like it was from Windows 95. Any suggestions on how to have the progressbar get rendered with Themes support? Or is this related to the use of manifest files? Thanks for your help, Malcolm From python at bdurham.com Fri Oct 1 01:10:05 2010 From: python at bdurham.com (python at bdurham.com) Date: Thu, 30 Sep 2010 19:10:05 -0400 Subject: [python-win32] Simple Windows progressbar dialog (like messagebox) via Win32 API? In-Reply-To: References: Message-ID: <1285888205.26761.1397771343@webmail.messagingengine.com> Tony, >Try Easy Dialogs > http://www.averdevelopment.com/python/EasyDialogs.html > > It has a progress bar. Easy Dialogs just wraps the native OS calls, and makes them sensible & cross platform. > > Using a progress bar is only a few lines of code. Thanks for this recommendation. This looks like a great solution that's very light weight. I just tried this library on my Windows 7 system and was surprised to see an old-fashioned (Windows 95 like) progressbar. Do you have any ideas on how I might activate Theme support with this library so the progressbar gets displayed using a Windows 7 style look? Thanks for your help, Malcolm From timr at probo.com Fri Oct 1 01:50:23 2010 From: timr at probo.com (Tim Roberts) Date: Thu, 30 Sep 2010 16:50:23 -0700 Subject: [python-win32] Simple Windows progressbar dialog (like messagebox) via Win32 API? In-Reply-To: <1285888018.26295.1397770951@webmail.messagingengine.com> References: <1285862956.22785.1397713153@webmail.messagingengine.com> <4CA4D500.2080505@probo.com> <1285888018.26295.1397770951@webmail.messagingengine.com> Message-ID: <4CA5223F.1000801@probo.com> python at bdurham.com wrote: > > I'm already using the Python Win32 extensions, so the progressbar.py > example might be a good fit for me. > > I tested it from the command line on Windows 7 and was surprised that > the progressbar control looked like it was from Windows 95. > > Any suggestions on how to have the progressbar get rendered with Themes > support? Or is this related to the use of manifest files? Are you building your own exe with py2exe? If so, then yes, you need a manifest that declares version 6.0 of the common controls DLL. Check in site-packages\py2exe\samples\advanced\setup.py for an example of how this is done. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From cappy2112 at gmail.com Fri Oct 1 02:06:27 2010 From: cappy2112 at gmail.com (Tony Cappellini) Date: Thu, 30 Sep 2010 17:06:27 -0700 Subject: [python-win32] Simple Windows progressbar dialog (like messagebox) via Win32 API? In-Reply-To: <1285888205.26761.1397771343@webmail.messagingengine.com> References: <1285888205.26761.1397771343@webmail.messagingengine.com> Message-ID: > I just tried this library on my Windows 7 system and was surprised to > see an old-fashioned (Windows 95 like) progressbar. Do you have any > ideas on how I might activate Theme support with this library so the > progressbar gets displayed using a Windows 7 style look? I don't think this problem is particular to EasyDialogs. I think you need what is known as a manifest. It's another contrived piece-of-crap from Microsoft. There should be sufficient info on this list or the wxPython list for it, if you google. (python gui manifest, or similar terms) Also check the py2exe list. I can't explain it well enough to help you. From rjs100 at rjs.org Fri Oct 1 00:40:27 2010 From: rjs100 at rjs.org (RJS) Date: Thu, 30 Sep 2010 15:40:27 -0700 Subject: [python-win32] Python DDE and multiple DDE servers? Message-ID: <6.2.3.4.2.20100930153836.049f8e60@rjs.org> I need to run both a Python DDE server and Python DDE client on the same machine (separate programs). Is there a reason why when I Create() the client: server.Create("PyVibeSurvey") I get: dde.error: The server could not be created for the client program? When the same client connects to the legacy DDE application (C++) it is OK. The client can also Create() if no other server is running. The servers have different names, of course. I had installed pywin32-214.win32-py2.6.exe Best, Ray S -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdriscoll at co.marshall.ia.us Fri Oct 1 16:08:50 2010 From: mdriscoll at co.marshall.ia.us (Mike Driscoll) Date: Fri, 01 Oct 2010 09:08:50 -0500 Subject: [python-win32] Simple Windows progressbar dialog (like messagebox) via Win32 API? In-Reply-To: <1285862956.22785.1397713153@webmail.messagingengine.com> References: <1285862956.22785.1397713153@webmail.messagingengine.com> Message-ID: <4CA5EB72.2080900@co.marshall.ia.us> On 1:59 PM, python at bdurham.com wrote: > I know there is a simple interface to the Windows messagebox interface. > Is there an equivalent type of simple dialog box for showing a > progressbar or progressbar-like information? > Use case: I have a collection of Python command line utilties that can > take up to several minutes to run. These are utilities may be called > from other applications. Our users have asked whether these utilities > can display a progressbar while they are running. > Our utilities are very lean right now and easy to distribute and > support. We would like to avoid having to use Tkinter or large GUI > frameworks like wxPython and pyQt if at all possible. > Thank you, > Malcolm Stupid question, but since you're using command line utilities, why not just use a command line progress bar? This fellow wrote one that might work: http://coreygoldberg.blogspot.com/2010/01/python-command-line-progress-bar-with.html - Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From federico at panizzolo.it Fri Oct 1 16:23:51 2010 From: federico at panizzolo.it (Federico Fanton) Date: Fri, 01 Oct 2010 16:23:51 +0200 Subject: [python-win32] Invalid number of parameters on makepy-generated method Message-ID: <4CA5EEF7.6010506@panizzolo.it> Hi everyone! I'm trying to automate an operation with Alibre Design (http://www.alibre.com) via COM. It is mostly working, except for a call to a method that accepts a single optional boolean parameter. When I try to call this method, I get an "Invalid number of parameters" exception. Here's my code: ---------------- import win32com.client import pywintypes try: # Check if Alibre is already running h = win32com.client.GetObject(Class="AlibreX.AutomationHook") except pywintypes.com_error: h = win32com.client.Dispatch("AlibreX.AutomationHook") h.Initialize("", "", "", False, 0) root = h.Root # Open a file and get its mass f = root.OpenFile(path_to_file) d = win32com.client.CastTo(f, "IADDesignSession") mass = d.PhysicalProperties(2).Mass f.Close() ---------------- The exception is triggered from the last call.. makepy generates it in this way: ---------------- def Close(self, saveSession=False): """Closes the session and saves the modified session and sub-sessions, if any, to their original folder locations, if the saveSession flag is set to true. Use SaveNew or SaveAs if this session is being saved for the first time""" return self._oleobj_.InvokeTypes(7, LCID, 1, (24, 0), ((11, 49),),saveSession ) ---------------- This matches the documentation of Alibre's API, and what I get when I try to inspect the corresponding DLL using Reflector. Any idea on what I could try? Thanks for your time! (Python 2.6.2, pywin32-214, windows XP) From federico at panizzolo.it Fri Oct 1 16:36:17 2010 From: federico at panizzolo.it (Federico Fanton) Date: Fri, 01 Oct 2010 16:36:17 +0200 Subject: [python-win32] Invalid number of parameters on makepy-generated method Message-ID: <4CA5F1E1.5000103@panizzolo.it> Hi everyone! I'm trying to automate an operation with Alibre Design (http://www.alibre.com) via COM. It is mostly working, except for a call to a method that accepts a single optional boolean parameter. When I try to call this method, I get an "Invalid number of parameters" exception. Here's my code: ---------------- import win32com.client import pywintypes try: # Check if Alibre is already running h = win32com.client.GetObject(Class="AlibreX.AutomationHook") except pywintypes.com_error: h = win32com.client.Dispatch("AlibreX.AutomationHook") h.Initialize("", "", "", False, 0) root = h.Root # Open a file and get its mass f = root.OpenFile(path_to_file) d = win32com.client.CastTo(f, "IADDesignSession") mass = d.PhysicalProperties(2).Mass f.Close() ---------------- The exception is triggered from the last call.. makepy generates it in this way: ---------------- def Close(self, saveSession=False): """Closes the session and saves the modified session and sub-sessions, if any, to their original folder locations, if the saveSession flag is set to true. Use SaveNew or SaveAs if this session is being saved for the first time""" return self._oleobj_.InvokeTypes(7, LCID, 1, (24, 0), ((11, 49),),saveSession ) ---------------- This matches the documentation of Alibre's API, and what I get when I try to inspect the corresponding DLL using Reflector. Any idea on what I could try? Thanks for your time! (Python 2.6.2, pywin32-214, windows XP) From timr at probo.com Fri Oct 1 22:19:50 2010 From: timr at probo.com (Tim Roberts) Date: Fri, 1 Oct 2010 13:19:50 -0700 Subject: [python-win32] Invalid number of parameters on makepy-generated method In-Reply-To: <4CA5F1E1.5000103@panizzolo.it> References: <4CA5F1E1.5000103@panizzolo.it> Message-ID: <4CA64266.7030108@probo.com> Federico Fanton wrote: > Hi everyone! > I'm trying to automate an operation with Alibre Design > (http://www.alibre.com) via COM. > > It is mostly working, except for a call to a method that accepts a > single optional boolean parameter. When I try to call this method, I get > an "Invalid number of parameters" exception. Is the exception coming from the InvokeTypes call? > Here's my code: > ... > The exception is triggered from the last call.. makepy generates it in > this way: > > ---------------- > > def Close(self, saveSession=False): > """Closes the session and saves the modified session and > sub-sessions, if any, to their original folder locations, if the > saveSession flag is set to true. Use SaveNew or SaveAs if this session > is being saved for the first time""" > return self._oleobj_.InvokeTypes(7, LCID, 1, (24, 0), ((11, > 49),),saveSession ) Curious. 1 means it is a method, (24,0) means that it returns nothing, and ((11,49)) means that it takes an optional Boolean with a default value. That should work just as you wrote it. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From pbeisel at gmail.com Sun Oct 3 00:56:55 2010 From: pbeisel at gmail.com (pbx) Date: Sat, 2 Oct 2010 15:56:55 -0700 (PDT) Subject: [python-win32] Question on parsing Reparse Points In-Reply-To: References: <2DEFEB25B65B1D4C962D79E3CCBAFC7F06E881BA@mpkexc01.eidos.com> Message-ID: <29868667.post@talk.nabble.com> hello, there seems to be something wrong with this, target always seems to be prepended with some data like ?\\? before the expected string (e.g. C:\Users\...) starts. the printname_len is accurate in that is represents the raw (byte) length of the string excluding this starting ?\\? is there an offset bug here? thanks. phil Roger Upole wrote: > > The only way I know of is to call win32file.DeviceIoControl > with FSCTL_GET_REPARSE_POINT, and unpack the > buffer yourself. > > Roger > > > import win32con, winioctlcon, winnt, win32file > import struct > > def get_reparse_target(fname): > h = win32file.CreateFile(fname, 0, > > win32con.FILE_SHARE_READ|win32con.FILE_SHARE_WRITE|win32con.FILE_SHARE_DELETE, > None, > win32con.OPEN_EXISTING, > > win32file.FILE_FLAG_OVERLAPPED|win32file.FILE_FLAG_OPEN_REPARSE_POINT|win32file.FILE_FLAG_BACKUP_SEMANTICS, > 0) > > > output_buf=win32file.AllocateReadBuffer(winnt.MAXIMUM_REPARSE_DATA_BUFFER_SIZE) > buf=win32file.DeviceIoControl(h, > winioctlcon.FSCTL_GET_REPARSE_POINT,None, > OutBuffer=output_buf, Overlapped=None) > fixed_fmt='LHHHHHH' > fixed_len=struct.calcsize(fixed_fmt) > tag, datalen, reserved, target_offset, target_len, printname_offset, > printname_len = \ > struct.unpack(fixed_fmt, buf[:fixed_len]) > > ## variable size target data follows the fixed portion of the buffer > name_buf=buf[fixed_len:] > > target_buf=name_buf[target_offset:target_offset+target_len] > target=target_buf.decode('utf-16-le') > return target > > > _______________________________________________ > python-win32 mailing list > python-win32 at python.org > http://mail.python.org/mailman/listinfo/python-win32 > > -- View this message in context: http://old.nabble.com/Question-on-parsing-Reparse-Points-tp22610814p29868667.html Sent from the Python - python-win32 mailing list archive at Nabble.com. From federico at panizzolo.it Mon Oct 4 09:29:43 2010 From: federico at panizzolo.it (Federico Fanton) Date: Mon, 04 Oct 2010 09:29:43 +0200 Subject: [python-win32] Invalid number of parameters on makepy-generated method In-Reply-To: <4CA64266.7030108@probo.com> References: <4CA5F1E1.5000103@panizzolo.it> <4CA64266.7030108@probo.com> Message-ID: <4CA98267.7060309@panizzolo.it> Tim Roberts wrote: >> It is mostly working, except for a call to a method that accepts a >> single optional boolean parameter. When I try to call this method, I get >> an "Invalid number of parameters" exception. > > Is the exception coming from the InvokeTypes call? Exactly.. I have a new bit of information though: I noticed that the problem arises ONLY when the controlled application (Alibre) is already running, while if it's not, there's no exception... Could it be that the "Invalid number of parameters" is thrown by something *after* the InvokeTypes? That is, could it be an error of the API itself? Or would I get the exception elsewhere? >def Close(self, saveSession=False): > """Closes the session and saves the modified session and > sub-sessions, if any, to their original folder locations, if the > saveSession flag is set to true. Use SaveNew or SaveAs if this session > is being saved for the first time""" > return self._oleobj_.InvokeTypes(7, LCID, 1, (24, 0), ((11, > 49),),saveSession ) If I call the Close() method passing pythoncom.Missing, there's no error even when Alibre is already open... Is Missing a way to explicitly tell "I'm not passing you this parameter, use the default value"? Many thanks for your attention! From rupole at hotmail.com Mon Oct 4 13:23:54 2010 From: rupole at hotmail.com (Roger Upole) Date: Mon, 4 Oct 2010 07:23:54 -0400 Subject: [python-win32] Question on parsing Reparse Points References: <2DEFEB25B65B1D4C962D79E3CCBAFC7F06E881BA@mpkexc01.eidos.com> <29868667.post@talk.nabble.com> Message-ID: pbx wrote: > > hello, there seems to be something wrong with this, > target always seems to be prepended with some data like ?\\? before the > expected string (e.g. C:\Users\...) starts. The '\??\' prefix is normal. That's the designator for a raw path, and is required when creating a reparse point. > the printname_len is accurate in that is represents the raw (byte) length > of > the string excluding this starting ?\\? > is there an offset bug here? Note the printname_offset extracted from the struct. Roger From rupole at hotmail.com Mon Oct 4 14:04:06 2010 From: rupole at hotmail.com (Roger Upole) Date: Mon, 4 Oct 2010 08:04:06 -0400 Subject: [python-win32] Python DDE and multiple DDE servers? References: <6.2.3.4.2.20100930154039.049f5ef8@rjs.org> Message-ID: RJ wrote: >I need to run both a Python DDE server and Python DDE client on the > same machine (separate programs). Is there a reason why when I > Create() the client: > server.Create("PyVibeSurvey") > I get: > dde.error: The server could not be created > for the client program? > When the same client connects to the legacy DDE application (C++) it is > OK. > The client can also Create() if no other server is running. > The servers have different names, of course. > I had installed pywin32-214.win32-py2.6.exe > > Best, > Ray S Currently, the dde module only supports a single server. If you're running your script from Pythonwin, one server has already been created, but you can use the /nodde switch to disable Pythonwin's builtin dde server. In the past, the dde module supported multple servers, but that has since been disabled. It was done through some low-level hacks to create new C functions on the fly, which set off DEP and crashed in a 64-bit build. There are also some conceptual difficulties in how the dde module operates, mainly that you must initiate your own server in order to establish a conversation as a client. It will take a major overhaul of the module to fix these issues. However, I think DDE is actually considered deprecated by Microsoft so it's unlikely that anyone will go to the trouble. Roger From skippy.hammond at gmail.com Wed Oct 6 08:46:45 2010 From: skippy.hammond at gmail.com (Mark Hammond) Date: Wed, 06 Oct 2010 17:46:45 +1100 Subject: [python-win32] Invalid number of parameters on makepy-generated method In-Reply-To: <4CA98267.7060309@panizzolo.it> References: <4CA5F1E1.5000103@panizzolo.it> <4CA64266.7030108@probo.com> <4CA98267.7060309@panizzolo.it> Message-ID: <4CAC1B55.5010803@gmail.com> On 4/10/2010 6:29 PM, Federico Fanton wrote: > Tim Roberts wrote: > >>> It is mostly working, except for a call to a method that accepts a >>> single optional boolean parameter. When I try to call this method, I get >>> an "Invalid number of parameters" exception. >> >> Is the exception coming from the InvokeTypes call? > > Exactly.. > I have a new bit of information though: I noticed that the problem > arises ONLY when the controlled application (Alibre) is already running, > while if it's not, there's no exception... Could it be that the "Invalid > number of parameters" is thrown by something *after* the InvokeTypes? > That is, could it be an error of the API itself? Or would I get the > exception elsewhere? Assuming the exception is a COMException, then yeah, it is the COM object itself which is throwing the error - ie, it isn't Python complaining about the missing param. > >def Close(self, saveSession=False): > > """Closes the session and saves the modified session and > > sub-sessions, if any, to their original folder locations, if the > > saveSession flag is set to true. Use SaveNew or SaveAs if this session > > is being saved for the first time""" > > return self._oleobj_.InvokeTypes(7, LCID, 1, (24, 0), ((11, > > 49),),saveSession ) > > If I call the Close() method passing pythoncom.Missing, there's no error > even when Alibre is already open... Is Missing a way to explicitly tell > "I'm not passing you this parameter, use the default value"? Exactly - when 'Missing' is used, the win32com bridge doesn't pass anything for the arg (ie, the "number of params" Python indicates it has passed doesn't include that param). When it is called as generated by makepy though, the parameter is always passed, but using the default value supplied by the type-library if one isn't specified by the Python code. This just sounds like a bug in the COM object. Cheers, Mark From federico at panizzolo.it Wed Oct 6 10:01:11 2010 From: federico at panizzolo.it (Federico Fanton) Date: Wed, 06 Oct 2010 10:01:11 +0200 Subject: [python-win32] Invalid number of parameters on makepy-generated method In-Reply-To: <4CAC1B55.5010803@gmail.com> References: <4CA5F1E1.5000103@panizzolo.it> <4CA64266.7030108@probo.com> <4CA98267.7060309@panizzolo.it> <4CAC1B55.5010803@gmail.com> Message-ID: <4CAC2CC7.70605@panizzolo.it> Mark Hammond wrote: ["Invalid number of parameters"] >>> Is the exception coming from the InvokeTypes call? >> >> Exactly.. >> I have a new bit of information though: I noticed that the problem >> arises ONLY when the controlled application (Alibre) is already running, >> while if it's not, there's no exception... Could it be that the "Invalid >> number of parameters" is thrown by something *after* the InvokeTypes? >> That is, could it be an error of the API itself? Or would I get the >> exception elsewhere? > > Assuming the exception is a COMException, then yeah, it is the COM > object itself which is throwing the error - ie, it isn't Python > complaining about the missing param. It's a pywintypes.com_error.. I'm assuming that's equivalente to a COMException then. >> If I call the Close() method passing pythoncom.Missing, there's no error >> even when Alibre is already open... Is Missing a way to explicitly tell >> "I'm not passing you this parameter, use the default value"? > > Exactly - when 'Missing' is used, the win32com bridge doesn't pass > anything for the arg (ie, the "number of params" Python indicates it has > passed doesn't include that param). When it is called as generated by > makepy though, the parameter is always passed, but using the default > value supplied by the type-library if one isn't specified by the Python > code. > > This just sounds like a bug in the COM object. I see.. Many thanks for your assistance :) From vinay.khemka at tcs.com Wed Oct 6 13:55:58 2010 From: vinay.khemka at tcs.com (Vinay Khemka) Date: Wed, 6 Oct 2010 17:25:58 +0530 Subject: [python-win32] Windows Services to run an Application (.exe) developed in python Message-ID: Hi all, I am trying hard to make the Application run as a windows services but i am unable to crack it. Actually my services get registered in Windows service console but when i start my service , it basically executes the Application(.exe) created in python and it gets stuck in the code where i have written app = wx.App() app.MainLoop(). Actually on starting the services it is unable to create the Main GUI event Loop. I am new to this , so may be i would be wrong in understanding the things but the services get stuck in app.MainLoop() Pls. help me out , i have already spent 2 weeks to crack it but i am unable to do it. Regards, Vinay Kumar Khemka Mailto: vinay.khemka at tcs.com =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From skippy.hammond at gmail.com Thu Oct 7 02:41:25 2010 From: skippy.hammond at gmail.com (Mark Hammond) Date: Thu, 07 Oct 2010 11:41:25 +1100 Subject: [python-win32] Windows Services to run an Application (.exe) developed in python In-Reply-To: References: Message-ID: <4CAD1735.1050005@gmail.com> On 6/10/2010 10:55 PM, Vinay Khemka wrote: > > Hi all, > > I am trying hard to make the Application run as a windows services but i > am unable to crack it. > Actually my services get registered in Windows service console but when > i start my service , it basically > executes the Application(.exe) created in python Created how in python? Using py2exe and it gets stuck in > the code where i have written app = wx.App() > app.MainLoop(). > Actually on starting the services it is unable to create the Main GUI > event Loop. What do you mean "stuck" and what is the symptom of it being unable to create the main GUI event loop? If the symptom is that no GUI is displayed, that would be expected - services generally can't create a UI. The typical solution then is to create 2 executables - the GUI-less service and an app run normally with a GUI and which communicates with the service. In short, your problem seems that you are trying to use wx in a service. Mark From timr at probo.com Thu Oct 7 20:05:36 2010 From: timr at probo.com (Tim Roberts) Date: Thu, 7 Oct 2010 11:05:36 -0700 Subject: [python-win32] Windows Services to run an Application (.exe) developed in python In-Reply-To: References: Message-ID: <4CAE0BF0.2060201@probo.com> Vinay Khemka wrote: > > I am trying hard to make the Application run as a windows services but > i am unable to crack it. > Actually my services get registered in Windows service console but > when i start my service , it basically > executes the Application(.exe) created in python and it gets stuck in > the code where i have written app = wx.App() > app.MainLoop(). > Actually on starting the services it is unable to create the Main GUI > event Loop. Mark is exactly right. Windows services cannot have user interfaces. They run in a special environment that is not connected to the desktop. Usually, you make something a service because it needs to run even when no one is logged in (which means before a desktop is even created, which is why the "no UI" restriction exists). Why does your app need to be a service? -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From kxroberto at googlemail.com Tue Oct 12 08:36:15 2010 From: kxroberto at googlemail.com (Robert) Date: Tue, 12 Oct 2010 08:36:15 +0200 Subject: [python-win32] os.stat() : files without "date modified" : OSError: [errno 22] Invalid Argument Message-ID: on a users machine there are files which show no time stamp in "date modified" in Windows Explorer. Right on such files os.stat() crashes with "OSError: [errno 22] Invalid Argument". how can such files exist? and how to create such files programmatically for a test? what is the underlying cause for the crash? Best, Robert From timr at probo.com Tue Oct 12 19:30:44 2010 From: timr at probo.com (Tim Roberts) Date: Tue, 12 Oct 2010 10:30:44 -0700 Subject: [python-win32] os.stat() : files without "date modified" : OSError: [errno 22] Invalid Argument In-Reply-To: References: Message-ID: <4CB49B44.4000900@probo.com> Robert wrote: > on a users machine there are files which show no time stamp in > "date modified" in Windows Explorer. > Right on such files os.stat() crashes with "OSError: [errno 22] > Invalid Argument". > > how can such files exist? and how to create such files > programmatically for a test? > what is the underlying cause for the crash? Can you give us a specific example? Some Windows viruses install a file system filter to render some files inaccessible, and it's possible to set file permissions so that you don't have the right to look at that kind of information. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From mail at timgolden.me.uk Tue Oct 12 19:37:56 2010 From: mail at timgolden.me.uk (Tim Golden) Date: Tue, 12 Oct 2010 18:37:56 +0100 Subject: [python-win32] os.stat() : files without "date modified" : OSError: [errno 22] Invalid Argument In-Reply-To: <4CB49B44.4000900@probo.com> References: <4CB49B44.4000900@probo.com> Message-ID: <4CB49CF4.8060802@timgolden.me.uk> On 12/10/2010 6:30 PM, Tim Roberts wrote: > Robert wrote: >> on a users machine there are files which show no time stamp in >> "date modified" in Windows Explorer. >> Right on such files os.stat() crashes with "OSError: [errno 22] >> Invalid Argument". >> >> how can such files exist? and how to create such files >> programmatically for a test? >> what is the underlying cause for the crash? > > Can you give us a specific example? Some Windows viruses install a file > system filter to render some files inaccessible, and it's possible to > set file permissions so that you don't have the right to look at that > kind of information. Didn't think of that; I assumed that the underlying FILETIME was sufficiently corrupt as to preclude a valid date/time being generated from it. Explorer fails gracefully and displays a blank; the API call fails and is reported as an exception by Python. I was going to try to generate such a "corrupt" number but haven't had a chance yet. TJG From siddhartha.veedaluru at gmail.com Wed Oct 13 15:09:37 2010 From: siddhartha.veedaluru at gmail.com (siddhartha veedaluru) Date: Wed, 13 Oct 2010 18:39:37 +0530 Subject: [python-win32] odbc giving None when the data in a row has string length more that 216 characters Message-ID: Hi, odbc retrieving value "None" when the data in a row has string length more that 216 characters. The Column AdditionalUpdates is of datatype ntext. the value in it has a string length more than 216, which when retrieved gives None. -------------------------------------------------------------------------------------------------------------------------------------- conString = "DRIVER={SQL Server};SERVER=VIGIL\MSQLINST;UID=sa;PWD=mkdbd;DATABASE=Common" try: con = odbc.odbc(conString) except: mesg = "Unable to establish connection to Common Database" print mesg cur = con.cursor() #Get Additional Installed Updates from CSDB PatchInfo table additionalUpdates = list() query = "select AdditionalPatches from UpdateInfo clientid = '%s' " % str(5)) print query try: cur.execute(query) except: mesg = "Error:Unable to execute %s query" % (query) print mesg rows = cur.fetchall() for row in rows: upds = row[0] print upds if upds != "None": updsLets = string.split(upds,',') for upd in updsLets: if not upd in additionalUpdates: additionalUpdates.append(upd) con.close() ----------------------------------------------------------------------------------------------------------------- Can some help on this? Thanks Siddhartha -------------- next part -------------- An HTML attachment was scrubbed... URL: From janssen at parc.com Thu Oct 14 22:59:37 2010 From: janssen at parc.com (Bill Janssen) Date: Thu, 14 Oct 2010 13:59:37 PDT Subject: [python-win32] granting SeServiceLogonRight on a network account with pywin32? Message-ID: <31080.1287089977@parc.com> I've got an MSI installer for installing my UpLib server. I use the following bit of code in a custom action to grant the user the right to "log on as a service", so that the service can run under their user-id: import win32api, win32security username = win32api.GetUserNameEx(win32api.NameSamCompatible) domain, username = username.split("\\") policy_handle = win32security.LsaOpenPolicy(domain, win32security.POLICY_ALL_ACCESS) sid_obj, domain, tmp = win32security.LookupAccountName(domain, username) win32security.LsaAddAccountRights( policy_handle, sid_obj, ('SeServiceLogonRight',) ) win32security.LsaClose( policy_handle ) This seems to work fine if the user is running the installer from a local machine account, but fails if they are running under their domain network account: Traceback (most recent call last): File "c:\docume~1\foobar\locals~1\temp\tmpgmqdnh\win32\install-script.py", line 410, in policy_handle = win32security.LsaOpenPolicy(domain, win32security.POLICY_ALL_ACCESS) pywintypes.error: (1722, 'LsaOpenPolicy', 'The RPC server is unavailable.') I've tried this on a couple of machines, and it's the same on each. Now, if that user opens up admin tools, then local security, then user rights, he can give himself this right. So it's not a privilege problem; I'm just not doing it right in Python. So, how should I be doing it? Bill From timr at probo.com Thu Oct 14 23:07:51 2010 From: timr at probo.com (Tim Roberts) Date: Thu, 14 Oct 2010 14:07:51 -0700 Subject: [python-win32] granting SeServiceLogonRight on a network account with pywin32? In-Reply-To: <31080.1287089977@parc.com> References: <31080.1287089977@parc.com> Message-ID: <4CB77127.20701@probo.com> Bill Janssen wrote: > I've got an MSI installer for installing my UpLib server. I use the > following bit of code in a custom action to grant the user the right to > "log on as a service", so that the service can run under their user-id: > > import win32api, win32security > > username = win32api.GetUserNameEx(win32api.NameSamCompatible) > domain, username = username.split("\\") > policy_handle = win32security.LsaOpenPolicy(domain, win32security.POLICY_ALL_ACCESS) > sid_obj, domain, tmp = win32security.LookupAccountName(domain, username) > win32security.LsaAddAccountRights( policy_handle, sid_obj, ('SeServiceLogonRight',) ) > win32security.LsaClose( policy_handle ) > > This seems to work fine if the user is running the installer from a > local machine account, but fails if they are running under their domain > network account: > > Traceback (most recent call last): > File "c:\docume~1\foobar\locals~1\temp\tmpgmqdnh\win32\install-script.py", line 410, in > policy_handle = win32security.LsaOpenPolicy(domain, win32security.POLICY_ALL_ACCESS) > pywintypes.error: (1722, 'LsaOpenPolicy', 'The RPC server is unavailable.') > > I've tried this on a couple of machines, and it's the same on each. > > Now, if that user opens up admin tools, then local security, then user > rights, he can give himself this right. So it's not a privilege problem; > I'm just not doing it right in Python. Notice that the failure here is in LsaOpenPolicy, not in LsaAddAccountRight. Your code as you have it is trying to modify the DOMAIN policy to add the service logon right. I THINK what you really want is to add the service logon right ON the local machine FOR this domain account. You don't want to modify the domain. To do that, I think you want to specify None as the first parameter to LsaOpenPolicy. However, I admit that NT security is a twisty maze of little passages, all different, so it's quite possible this is just a wrong turn. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From janssen at parc.com Thu Oct 14 23:22:53 2010 From: janssen at parc.com (Bill Janssen) Date: Thu, 14 Oct 2010 14:22:53 PDT Subject: [python-win32] granting SeServiceLogonRight on a network account with pywin32? In-Reply-To: <4CB77127.20701@probo.com> References: <31080.1287089977@parc.com> <4CB77127.20701@probo.com> Message-ID: <32206.1287091373@parc.com> Tim Roberts wrote: > Bill Janssen wrote: > > I've got an MSI installer for installing my UpLib server. I use the > > following bit of code in a custom action to grant the user the right to > > "log on as a service", so that the service can run under their user-id: > > > > import win32api, win32security > > > > username = win32api.GetUserNameEx(win32api.NameSamCompatible) > > domain, username = username.split("\\") > > policy_handle = win32security.LsaOpenPolicy(domain, win32security.POLICY_ALL_ACCESS) > > sid_obj, domain, tmp = win32security.LookupAccountName(domain, username) > > win32security.LsaAddAccountRights( policy_handle, sid_obj, ('SeServiceLogonRight',) ) > > win32security.LsaClose( policy_handle ) > > > > This seems to work fine if the user is running the installer from a > > local machine account, but fails if they are running under their domain > > network account: > > > > Traceback (most recent call last): > > File "c:\docume~1\foobar\locals~1\temp\tmpgmqdnh\win32\install-script.py", line 410, in > > policy_handle = win32security.LsaOpenPolicy(domain, win32security.POLICY_ALL_ACCESS) > > pywintypes.error: (1722, 'LsaOpenPolicy', 'The RPC server is unavailable.') > > > > I've tried this on a couple of machines, and it's the same on each. > > > > Now, if that user opens up admin tools, then local security, then user > > rights, he can give himself this right. So it's not a privilege problem; > > I'm just not doing it right in Python. > > Notice that the failure here is in LsaOpenPolicy, not in > LsaAddAccountRight. Your code as you have it is trying to modify the > DOMAIN policy to add the service logon right. I THINK what you really > want is to add the service logon right ON the local machine FOR this > domain account. You don't want to modify the domain. To do that, I > think you want to specify None as the first parameter to LsaOpenPolicy. > > However, I admit that NT security is a twisty maze of little passages, > all different, so it's quite possible this is just a wrong turn. Thanks, Tim. That seems reasonable to me; I'll give it a shot. Bill From timr at probo.com Thu Oct 14 23:26:22 2010 From: timr at probo.com (Tim Roberts) Date: Thu, 14 Oct 2010 14:26:22 -0700 Subject: [python-win32] granting SeServiceLogonRight on a network account with pywin32? In-Reply-To: <4CB77127.20701@probo.com> References: <31080.1287089977@parc.com> <4CB77127.20701@probo.com> Message-ID: <4CB7757E.2070405@probo.com> Tim Roberts wrote: > > However, I admit that NT security is a twisty maze of little passages, > all different, so it's quite possible this is just a wrong turn. And I wonder how many of you are old enough to get the reference in that sentence... -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From ewei at Fekete.com Thu Oct 14 18:40:57 2010 From: ewei at Fekete.com (Eileen Wei) Date: Thu, 14 Oct 2010 10:40:57 -0600 Subject: [python-win32] Problem using win32com.client.Dispatch on Win7 64bit Message-ID: <5E94BFD292E6664094E77128C4C459B504491D6923@eros2.Fekete.com> Hi everyone, I am new to this group. I am not sure how to do search on the archives so if my question is duplicate please forgive me :) I have Python 2.7.amd64 and pywin32-214.win-amd64-py2.7 installed on my Win7 64bit machine. I am trying to use a COM object (the source of the COM is in C++ and MFC) in my python script. I registered the dll and tried to create a object and here is what I got: >>> import win32com.client >>> security = win32com.client.Dispatch("SWDBSecurityCOM.SWDBSecurity") Traceback (most recent call last): File "", line 1, in File "C:\Python27\lib\site-packages\win32com\client\__init__.py", line 95, in Dispatch dispatch, userName = dynamic._GetGoodDispatchAndUserName(dispatch,userName,c lsctx) File "C:\Python27\lib\site-packages\win32com\client\dynamic.py", line 104, in _GetGoodDispatchAndUserName return (_GetGoodDispatch(IDispatch, clsctx), userName) File "C:\Python27\lib\site-packages\win32com\client\dynamic.py", line 84, in _ GetGoodDispatch IDispatch = pythoncom.CoCreateInstance(IDispatch, None, clsctx, pythoncom.II D_IDispatch) pywintypes.com_error: (-2147221164, 'Class not registered', None, None) >>> Note that I was able to successfully creating the object in my WinXP and Win7 32bit machine. So I am thinking the problem must be related to 64bit somehow. How can I fix this? Thanks, Eileen -------------- next part -------------- An HTML attachment was scrubbed... URL: From skippy.hammond at gmail.com Fri Oct 15 01:09:50 2010 From: skippy.hammond at gmail.com (Mark Hammond) Date: Fri, 15 Oct 2010 10:09:50 +1100 Subject: [python-win32] Problem using win32com.client.Dispatch on Win7 64bit In-Reply-To: <5E94BFD292E6664094E77128C4C459B504491D6923@eros2.Fekete.com> References: <5E94BFD292E6664094E77128C4C459B504491D6923@eros2.Fekete.com> Message-ID: <4CB78DBE.40906@gmail.com> On 15/10/2010 3:40 AM, Eileen Wei wrote: > Hi everyone, > > I am new to this group. I am not sure how to do search on the archives > so if my question is duplicate please forgive me J > > I have Python 2.7.amd64 and pywin32-214.win-amd64-py2.7 installed on my > Win7 64bit machine. > > I am trying to use a COM object (the source of the COM is in C++ and > MFC) in my python script. I registered the dll and tried to create a > object and here is what I got: ... > Note that I was able to successfully creating the object in my WinXP and > Win7 32bit machine. So I am thinking the problem must be related to > 64bit somehow. How can I fix this? 64bit processes can't use 32bit COM objects (at least not in-proc - not sure about external) and I guess your COM object is 32 bit. The easiest answer is probably just to install the 32bit Python and 32bit pywin32 extensions - you can either leave or remove the 64bit version - they can co-exist happily... Cheers, Mark From davea at ieee.org Fri Oct 15 02:40:00 2010 From: davea at ieee.org (Dave Angel) Date: Thu, 14 Oct 2010 20:40:00 -0400 Subject: [python-win32] granting SeServiceLogonRight on a network account with pywin32? In-Reply-To: <4CB7757E.2070405@probo.com> References: <31080.1287089977@parc.com> <4CB77127.20701@probo.com> <4CB7757E.2070405@probo.com> Message-ID: <4CB7A2E0.3090602@ieee.org> On 2:59 PM, Tim Roberts wrote: > Tim Roberts wrote: >> However, I admit that NT security is a twisty maze of little passages, >> all different, so it's quite possible this is just a wrong turn. > And I wonder how many of you are old enough to get the reference in that > sentence... > But the adventure is in Fortran, not in Python. Be sure to pick up the bird when you see him, or the snake... DaveA From janssen at parc.com Fri Oct 15 06:55:25 2010 From: janssen at parc.com (Bill Janssen) Date: Thu, 14 Oct 2010 21:55:25 PDT Subject: [python-win32] granting SeServiceLogonRight on a network account with pywin32? In-Reply-To: <4CB77127.20701@probo.com> References: <31080.1287089977@parc.com> <4CB77127.20701@probo.com> Message-ID: <95504.1287118525@parc.com> Tim Roberts wrote: > Bill Janssen wrote: > > I've got an MSI installer for installing my UpLib server. I use the > > following bit of code in a custom action to grant the user the right to > > "log on as a service", so that the service can run under their user-id: > > > > import win32api, win32security > > > > username = win32api.GetUserNameEx(win32api.NameSamCompatible) > > domain, username = username.split("\\") > > policy_handle = win32security.LsaOpenPolicy(domain, win32security.POLICY_ALL_ACCESS) > > sid_obj, domain, tmp = win32security.LookupAccountName(domain, username) > > win32security.LsaAddAccountRights( policy_handle, sid_obj, ('SeServiceLogonRight',) ) > > win32security.LsaClose( policy_handle ) > > > > This seems to work fine if the user is running the installer from a > > local machine account, but fails if they are running under their domain > > network account: > > > > Traceback (most recent call last): > > File "c:\docume~1\foobar\locals~1\temp\tmpgmqdnh\win32\install-script.py", line 410, in > > policy_handle = win32security.LsaOpenPolicy(domain, win32security.POLICY_ALL_ACCESS) > > pywintypes.error: (1722, 'LsaOpenPolicy', 'The RPC server is unavailable.') > > > > I've tried this on a couple of machines, and it's the same on each. > > > > Now, if that user opens up admin tools, then local security, then user > > rights, he can give himself this right. So it's not a privilege problem; > > I'm just not doing it right in Python. > > Notice that the failure here is in LsaOpenPolicy, not in > LsaAddAccountRight. Your code as you have it is trying to modify the > DOMAIN policy to add the service logon right. I THINK what you really > want is to add the service logon right ON the local machine FOR this > domain account. You don't want to modify the domain. To do that, I > think you want to specify None as the first parameter to LsaOpenPolicy. > > However, I admit that NT security is a twisty maze of little passages, > all different, so it's quite possible this is just a wrong turn. Got it to work. I was just being too complicated for my own good. Here's the working code: try: import win32api, win32security username = win32api.GetUserNameEx(win32api.NameSamCompatible) print 'granting "logon as a service" rights to ' + username policy_handle = win32security.LsaOpenPolicy(None, win32security.POLICY_ALL_ACCESS) sid_obj, domain, tmp = win32security.LookupAccountName(None, username) win32security.LsaAddAccountRights( policy_handle, sid_obj, ('SeServiceLogonRight',) ) win32security.LsaClose( policy_handle ) except: print 'Exception granting user the SeServiceLogonRight:' print ''.join(traceback.format_exception(*sys.exc_info())) Thanks for the help. Bill From mdriscoll at co.marshall.ia.us Fri Oct 15 16:04:07 2010 From: mdriscoll at co.marshall.ia.us (Mike Driscoll) Date: Fri, 15 Oct 2010 09:04:07 -0500 Subject: [python-win32] granting SeServiceLogonRight on a network account with pywin32? In-Reply-To: <4CB7757E.2070405@probo.com> References: <31080.1287089977@parc.com> <4CB77127.20701@probo.com> <4CB7757E.2070405@probo.com> Message-ID: <4CB85F57.20905@co.marshall.ia.us> On 1:59 PM, Tim Roberts wrote: > Tim Roberts wrote: >> However, I admit that NT security is a twisty maze of little passages, >> all different, so it's quite possible this is just a wrong turn. > And I wonder how many of you are old enough to get the reference in that > sentence... > I'm pretty sure I played that adventure on an old DEC workstation in high school... -- Mike Driscoll Applications Specialist MCIS - Technology Center 1 E. Main St. Marshalltown, IA 50158 mdriscoll at co.marshall.ia.us 641-844-2802 From aahz at pythoncraft.com Fri Oct 15 17:32:24 2010 From: aahz at pythoncraft.com (Aahz) Date: Fri, 15 Oct 2010 08:32:24 -0700 Subject: [python-win32] granting SeServiceLogonRight on a network account with pywin32? In-Reply-To: <4CB7757E.2070405@probo.com> References: <31080.1287089977@parc.com> <4CB77127.20701@probo.com> <4CB7757E.2070405@probo.com> Message-ID: <20101015153223.GB8323@panix.com> On Thu, Oct 14, 2010, Tim Roberts wrote: > Tim Roberts wrote: >> >> However, I admit that NT security is a twisty maze of little passages, >> all different, so it's quite possible this is just a wrong turn. > > And I wonder how many of you are old enough to get the reference in that > sentence... It's a colossal mistake. -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ "If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." --Red Adair From aahz at pythoncraft.com Fri Oct 15 17:40:17 2010 From: aahz at pythoncraft.com (Aahz) Date: Fri, 15 Oct 2010 08:40:17 -0700 Subject: [python-win32] Avoid bare except In-Reply-To: <95504.1287118525@parc.com> References: <31080.1287089977@parc.com> <4CB77127.20701@probo.com> <95504.1287118525@parc.com> Message-ID: <20101015154017.GC8323@panix.com> On Thu, Oct 14, 2010, Bill Janssen wrote: > > try: > import win32api, win32security > > username = win32api.GetUserNameEx(win32api.NameSamCompatible) > print 'granting "logon as a service" rights to ' + username > policy_handle = win32security.LsaOpenPolicy(None, win32security.POLICY_ALL_ACCESS) > sid_obj, domain, tmp = win32security.LookupAccountName(None, username) > win32security.LsaAddAccountRights( policy_handle, sid_obj, ('SeServiceLogonRight',) ) > win32security.LsaClose( policy_handle ) > except: > print 'Exception granting user the SeServiceLogonRight:' > print ''.join(traceback.format_exception(*sys.exc_info())) Bill, I know you know this and are just being sloppy in a test script, but I figure we probably have some Python newcomers on this list: Do *NOT* use bare except: clauses. At the very least, that means you won't properly handle KeyboardInterrupt. Always try to catch the specific exceptions you're expecting. For more info, see http://docs.python.org/howto/doanddont.html It also would have been easier to just use traceback.format_exc() unless you're stuck with Python less than 2.4. -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ "If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." --Red Adair From janssen at parc.com Fri Oct 15 18:47:23 2010 From: janssen at parc.com (Bill Janssen) Date: Fri, 15 Oct 2010 09:47:23 PDT Subject: [python-win32] Avoid bare except In-Reply-To: <20101015154017.GC8323@panix.com> References: <31080.1287089977@parc.com> <4CB77127.20701@probo.com> <95504.1287118525@parc.com> <20101015154017.GC8323@panix.com> Message-ID: <96018.1287161243@parc.com> Aahz wrote: > On Thu, Oct 14, 2010, Bill Janssen wrote: > > > > try: > > import win32api, win32security > > > > username = win32api.GetUserNameEx(win32api.NameSamCompatible) > > print 'granting "logon as a service" rights to ' + username > > policy_handle = win32security.LsaOpenPolicy(None, win32security.POLICY_ALL_ACCESS) > > sid_obj, domain, tmp = win32security.LookupAccountName(None, username) > > win32security.LsaAddAccountRights( policy_handle, sid_obj, ('SeServiceLogonRight',) ) > > win32security.LsaClose( policy_handle ) > > except: > > print 'Exception granting user the SeServiceLogonRight:' > > print ''.join(traceback.format_exception(*sys.exc_info())) > > Bill, I know you know this and are just being sloppy in a test script, > but I figure we probably have some Python newcomers on this list: > > Do *NOT* use bare except: clauses. At the very least, that means you > won't properly handle KeyboardInterrupt. Always try to catch the > specific exceptions you're expecting. For more info, see > > http://docs.python.org/howto/doanddont.html Indeed. Catching all exceptions is usually a bad idea, unless you're trying to get some idea of what to expect, in which case you almost always want to print out the actual exception. > It also would have been easier to just use traceback.format_exc() unless > you're stuck with Python less than 2.4. Actually, that one I didn't know. I was on 2.3.5 for too long, I guess. Good tip, thanks! Bill From janssen at parc.com Sat Oct 16 00:11:25 2010 From: janssen at parc.com (Bill Janssen) Date: Fri, 15 Oct 2010 15:11:25 PDT Subject: [python-win32] crash on Windows Server 2008 Message-ID: <97213.1287180685@parc.com> I'm trying to run a Python service on Windows Server 2008. It does start up, but then faults out, leaving this message in the event viewer: Log Name: Application Source: Application Error Date: 10/15/2010 2:59:41 PM Event ID: 1000 Task Category: (100) Level: Error Keywords: Classic User: N/A Computer: *** Description: Faulting application PythonService.exe, version 2.6.214.0, time stamp 0x4a5012a6, faulting module ntdll.dll, version 6.0.6002.18005, time stamp 0x49e03821, exception code 0xc0000005, fault offset 0x00067580, process id 0x10cc, application start time 0x01cb6cb4448dcbf4. I'm using Python 2.6.6, with PyWin32 2.6.214. Any ideas as to what's happening? Works fine on WS 2003, so I'm guessing it's related to the platform :-). Bill From timr at probo.com Sat Oct 16 01:32:41 2010 From: timr at probo.com (Tim Roberts) Date: Fri, 15 Oct 2010 16:32:41 -0700 Subject: [python-win32] crash on Windows Server 2008 In-Reply-To: <97213.1287180685@parc.com> References: <97213.1287180685@parc.com> Message-ID: <4CB8E499.20509@probo.com> Bill Janssen wrote: > I'm trying to run a Python service on Windows Server 2008. It does > start up, but then faults out, leaving this message in the event viewer: > > Log Name: Application > Source: Application Error > Date: 10/15/2010 2:59:41 PM > Event ID: 1000 > Task Category: (100) > Level: Error > Keywords: Classic > User: N/A > Computer: *** > Description: > Faulting application PythonService.exe, version 2.6.214.0, time stamp > 0x4a5012a6, faulting module ntdll.dll, version 6.0.6002.18005, time > stamp 0x49e03821, exception code 0xc0000005, fault offset 0x00067580, > process id 0x10cc, application start time 0x01cb6cb4448dcbf4. > > I'm using Python 2.6.6, with PyWin32 2.6.214. > > Any ideas as to what's happening? Works fine on WS 2003, so I'm guessing > it's related to the platform :-). There's not enough information here to tell anything. That address within ntdll.dll is the "unhandled exception" handler C0000005 is the catchall error code for addressing faults caught by the processor, like invalid addresses or access violations. So, there's probably some kind of a wild pointer issue, but we can't tell any more. You'll need to run it with a debugger, or add a printf trace log. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From janssen at parc.com Sat Oct 16 01:55:09 2010 From: janssen at parc.com (Bill Janssen) Date: Fri, 15 Oct 2010 16:55:09 PDT Subject: [python-win32] crash on Windows Server 2008 In-Reply-To: <4CB8E499.20509@probo.com> References: <97213.1287180685@parc.com> <4CB8E499.20509@probo.com> Message-ID: <99370.1287186909@parc.com> Tim Roberts wrote: > Bill Janssen wrote: > > I'm trying to run a Python service on Windows Server 2008. It does > > start up, but then faults out, leaving this message in the event viewer: > > > > Log Name: Application > > Source: Application Error > > Date: 10/15/2010 2:59:41 PM > > Event ID: 1000 > > Task Category: (100) > > Level: Error > > Keywords: Classic > > User: N/A > > Computer: *** > > Description: > > Faulting application PythonService.exe, version 2.6.214.0, time stamp > > 0x4a5012a6, faulting module ntdll.dll, version 6.0.6002.18005, time > > stamp 0x49e03821, exception code 0xc0000005, fault offset 0x00067580, > > process id 0x10cc, application start time 0x01cb6cb4448dcbf4. > > > > I'm using Python 2.6.6, with PyWin32 2.6.214. > > > > Any ideas as to what's happening? Works fine on WS 2003, so I'm guessing > > it's related to the platform :-). > > There's not enough information here to tell anything. That address > within ntdll.dll is the "unhandled exception" handler C0000005 is the > catchall error code for addressing faults caught by the processor, like > invalid addresses or access violations. So, there's probably some kind > of a wild pointer issue, but we can't tell any more. You'll need to run > it with a debugger, or add a printf trace log. Thanks. Just wanted to check that this wasn't some well-known issue. Bill From mhammond at skippinet.com.au Sat Oct 16 01:45:19 2010 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 16 Oct 2010 10:45:19 +1100 Subject: [python-win32] Problem using win32com.client.Dispatch on Win7 64bit In-Reply-To: <5E94BFD292E6664094E77128C4C459B504491D6B71@eros2.Fekete.com> References: <5E94BFD292E6664094E77128C4C459B504491D6923@eros2.Fekete.com> <4CB78DBE.40906@gmail.com> <5E94BFD292E6664094E77128C4C459B504491D6B71@eros2.Fekete.com> Message-ID: <4CB8E78F.50703@skippinet.com.au> On 16/10/2010 6:23 AM, Eileen Wei wrote: > Thanks Mark, that solved the problem. But I am wondering since 32bit > Python and pywin32 work on 64bit machine, why do we need the 64bit > version? - I have always thought that you need to install 64bit > version on 64bit machines... In practice, it is rare you need the 64bit version - only if you need access to >3/4 GB of memory, need to use existing 64bit COM objects, etc. Cheers, Mark > > -----Original Message----- From: Mark Hammond > [mailto:skippy.hammond at gmail.com] Sent: October-14-10 5:10 PM To: > Eileen Wei Cc: python-win32 at python.org Subject: Re: [python-win32] > Problem using win32com.client.Dispatch on Win7 64bit > > On 15/10/2010 3:40 AM, Eileen Wei wrote: >> Hi everyone, >> >> I am new to this group. I am not sure how to do search on the >> archives so if my question is duplicate please forgive me J >> >> I have Python 2.7.amd64 and pywin32-214.win-amd64-py2.7 installed >> on my Win7 64bit machine. >> >> I am trying to use a COM object (the source of the COM is in C++ >> and MFC) in my python script. I registered the dll and tried to >> create a object and here is what I got: > ... >> Note that I was able to successfully creating the object in my >> WinXP and Win7 32bit machine. So I am thinking the problem must be >> related to 64bit somehow. How can I fix this? > > 64bit processes can't use 32bit COM objects (at least not in-proc - > not sure about external) and I guess your COM object is 32 bit. > > The easiest answer is probably just to install the 32bit Python and > 32bit pywin32 extensions - you can either leave or remove the 64bit > version - they can co-exist happily... > > Cheers, > > Mark From planders at gmail.com Sat Oct 16 03:49:58 2010 From: planders at gmail.com (Preston Landers) Date: Fri, 15 Oct 2010 20:49:58 -0500 Subject: [python-win32] Problem using win32com.client.Dispatch on Win7 64bit In-Reply-To: <4CB8E78F.50703@skippinet.com.au> References: <5E94BFD292E6664094E77128C4C459B504491D6923@eros2.Fekete.com> <4CB78DBE.40906@gmail.com> <5E94BFD292E6664094E77128C4C459B504491D6B71@eros2.Fekete.com> <4CB8E78F.50703@skippinet.com.au> Message-ID: The main use I've found for 64 bit Python is for running the Python ISAPI stuff under the IIS web server on 64 bit Windows. I guess technically that falls under using 64 bit COM objects. That and it helps when you need to open >4 GB files and use >2GB memory in a process. regards, -Preston On Fri, Oct 15, 2010 at 6:45 PM, Mark Hammond wrote: > On 16/10/2010 6:23 AM, Eileen Wei wrote: > >> Thanks Mark, that solved the problem. But I am wondering since 32bit >> Python and pywin32 work on 64bit machine, why do we need the 64bit >> version? - I have always thought that you need to install 64bit >> version on 64bit machines... >> > > In practice, it is rare you need the 64bit version - only if you need > access to >3/4 GB of memory, need to use existing 64bit COM objects, etc. > > Cheers, > > Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewei at Fekete.com Fri Oct 15 21:23:53 2010 From: ewei at Fekete.com (Eileen Wei) Date: Fri, 15 Oct 2010 13:23:53 -0600 Subject: [python-win32] Problem using win32com.client.Dispatch on Win7 64bit In-Reply-To: <4CB78DBE.40906@gmail.com> References: <5E94BFD292E6664094E77128C4C459B504491D6923@eros2.Fekete.com> <4CB78DBE.40906@gmail.com> Message-ID: <5E94BFD292E6664094E77128C4C459B504491D6B71@eros2.Fekete.com> Thanks Mark, that solved the problem. But I am wondering since 32bit Python and pywin32 work on 64bit machine, why do we need the 64bit version? - I have always thought that you need to install 64bit version on 64bit machines... -----Original Message----- From: Mark Hammond [mailto:skippy.hammond at gmail.com] Sent: October-14-10 5:10 PM To: Eileen Wei Cc: python-win32 at python.org Subject: Re: [python-win32] Problem using win32com.client.Dispatch on Win7 64bit On 15/10/2010 3:40 AM, Eileen Wei wrote: > Hi everyone, > > I am new to this group. I am not sure how to do search on the archives > so if my question is duplicate please forgive me J > > I have Python 2.7.amd64 and pywin32-214.win-amd64-py2.7 installed on my > Win7 64bit machine. > > I am trying to use a COM object (the source of the COM is in C++ and > MFC) in my python script. I registered the dll and tried to create a > object and here is what I got: ... > Note that I was able to successfully creating the object in my WinXP and > Win7 32bit machine. So I am thinking the problem must be related to > 64bit somehow. How can I fix this? 64bit processes can't use 32bit COM objects (at least not in-proc - not sure about external) and I guess your COM object is 32 bit. The easiest answer is probably just to install the 32bit Python and 32bit pywin32 extensions - you can either leave or remove the 64bit version - they can co-exist happily... Cheers, Mark From greg.ewing at canterbury.ac.nz Sun Oct 17 10:31:00 2010 From: greg.ewing at canterbury.ac.nz (Gregory Ewing) Date: Sun, 17 Oct 2010 21:31:00 +1300 Subject: [python-win32] ANN: PyGUI 2.3 Message-ID: <4CBAB444.9080701@canterbury.ac.nz> PyGUI 2.3 is available: http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ This version works on Snow Leopard with PyObjC 2.3. What is PyGUI? -------------- PyGUI is a cross-platform GUI toolkit designed to be lightweight and have a highly Pythonic API. -- Gregory Ewing greg.ewing at canterbury.ac.nz http://www.cosc.canterbury.ac.nz/greg.ewing/ This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. From ewei at Fekete.com Mon Oct 18 16:56:17 2010 From: ewei at Fekete.com (Eileen Wei) Date: Mon, 18 Oct 2010 08:56:17 -0600 Subject: [python-win32] A question about COM in general Message-ID: <5E94BFD292E6664094E77128C4C459B504491D6BED@eros2.Fekete.com> Hi, I am a software tester and I am exploring ways to exposing APIs of Windows applications that's developed in C++ and MFC to Python for testing purpose. I just learned about COM last week and I am wondering if it's the best way to do it? I have also heard about other options like SWIG (Simplified Wrapper and Interface Generator) and Boost Python. I am aware that the question might be a little off topic, but I am thinking users in this mail group might have done similar exploration and probably can give me some advice in terms of ease of use, maturity of the technology etc. Any feedbacks will be greatly appreciated! Thanks, Eileen -------------- next part -------------- An HTML attachment was scrubbed... URL: From timr at probo.com Tue Oct 19 18:41:32 2010 From: timr at probo.com (Tim Roberts) Date: Tue, 19 Oct 2010 09:41:32 -0700 Subject: [python-win32] A question about COM in general In-Reply-To: <5E94BFD292E6664094E77128C4C459B504491D6BED@eros2.Fekete.com> References: <5E94BFD292E6664094E77128C4C459B504491D6BED@eros2.Fekete.com> Message-ID: <4CBDCA3C.5050204@probo.com> Eileen Wei wrote: > > > > > I am a software tester and I am exploring ways to exposing APIs of > Windows applications that?s developed in C++ and MFC to Python for > testing purpose. I just learned about COM last week and I am wondering > if it?s the best way to do it? I have also heard about other options > like SWIG (Simplified Wrapper and Interface Generator) and Boost Python. > > > > I am aware that the question might be a little off topic, but I am > thinking users in this mail group might have done similar exploration > and probably can give me some advice in terms of ease of use, maturity > of the technology etc. > It's an interesting question. Note that what follows are my personal opinions, not the "collected knowledge of the ages". The biggest part of the answer is dependent on what your application expects. If an application expects to be controlled programmatically, then it has to take explicit steps to allow itself to be controlled. You can't remotely control an arbitrary application unless it was designed to be controlled. COM is one of the more common ways to allow this kind of control. That, for example, is how the Office applications are controlled. If your application already exposes a COM interface, and that's the way programmers are expected to talk to it, then that's a perfectly sensible way to go. Python's COM support is pretty good, and it's easy to experiment. If your application has an API that is implemented in a DLL, and that DLL is not COM, then it is probably not worth the trouble to add COM to it. Instead, you can use the "ctypes" module that is now built-in to Python. "ctypes" is a "foreign function library", which means that it allows Python programs to talk to libraries that were not designed for Python. You can call virtually any arbitrary DLL function from Python with ctypes. If the data types are complicated, the code is a little bit convoluted, but it is usually straightforward and easy to read. For me, SWIG only seemed to made sense for interfaces that I intended to publish. SWIG is quite powerful, but it has (in my opinion) a very steep learning curve. You can do anything, but there are sharp edges. I have only experimented a little bit with Boost.Python. It does seem to be very cool, but you have to decide what your model is going to be. Boost.Python lets you build Python extension modules easily. If you want your application interface to look like a Python extension module, then it might make good sense. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From roberto.c.aguilar at gmail.com Tue Oct 19 19:39:57 2010 From: roberto.c.aguilar at gmail.com (Roberto Aguilar) Date: Tue, 19 Oct 2010 10:39:57 -0700 Subject: [python-win32] A question about COM in general In-Reply-To: <4CBDCA3C.5050204@probo.com> References: <5E94BFD292E6664094E77128C4C459B504491D6BED@eros2.Fekete.com> <4CBDCA3C.5050204@probo.com> Message-ID: On Oct 19, 2010, at 9:41 AM, Tim Roberts wrote: > Eileen Wei wrote: >> I am a software tester and I am exploring ways to exposing APIs of >> Windows applications that?s developed in C++ and MFC to Python for >> testing purpose. I just learned about COM last week and I am wondering >> if it?s the best way to do it? I have also heard about other options >> like SWIG (Simplified Wrapper and Interface Generator) and Boost Python. >> >> I am aware that the question might be a little off topic, but I am >> thinking users in this mail group might have done similar exploration >> and probably can give me some advice in terms of ease of use, maturity >> of the technology etc. > [...] > For me, SWIG only seemed to made sense for interfaces that I intended to > publish. SWIG is quite powerful, but it has (in my opinion) a very > steep learning curve. You can do anything, but there are sharp edges. > > I have only experimented a little bit with Boost.Python. It does seem > to be very cool, but you have to decide what your model is going to be. > Boost.Python lets you build Python extension modules easily. If you > want your application interface to look like a Python extension module, > then it might make good sense. Though not on Windows I've had good success with PyCXX [1]. It's a library used to wrap a python interface around C++ code. It's not automagical like SWIG, but it handles the tedium associated with reference counting and error checking. If you're looking for a code-free way to access your C++ code, I think ctypes, as Time suggests is the way to go. -Roberto. [1] http://cxx.sourceforge.net/ From kxroberto at googlemail.com Tue Oct 19 20:07:14 2010 From: kxroberto at googlemail.com (Robert) Date: Tue, 19 Oct 2010 20:07:14 +0200 Subject: [python-win32] PyGUI blobedit creashes with pywin32-214 but not 212 - traceback - related problems Message-ID: A) What could be the cause for this exception of PyGUI with pywin32-build214 - but not with build 212 :? Traceback (most recent call last): File "blobedit.py", line 131, in BlobApp().run() File "C:\Python26\lib\site-packages\GUI\GenericGApplications.py", line 122, in run self.process_args(sys.argv[1:]) File "C:\Python26\lib\site-packages\GUI\Generic\GApplications.py", line 251, in process_args self.open_app() File "blobedit.py", line 32, in open_app self.new_cmd() File "C:\Python26\lib\site-packages\GUI\Generic\GApplications.py", line 219, in new_cmd self.make_window(doc) File "blobedit.py", line 40, in make_window cursor = self.blob_cursor) File "C:\Python26\lib\site-packages\GUI\Win32\ScrollableViews.py", line 32, in __init__ GScrollableView.__init__(self, _win = win) win32ui.error: The object has been destroyed. class ScrollableView(GScrollableView): _line_scroll_amount = default_line_scroll_amount def __init__(self, **kwds): kwds.setdefault('extent', default_extent) win = ui.CreateView(win_dummy_doc) win.CreateWindow(win_none, 0, win_style, (0, 0, 100, 100)) GScrollableView.__init__(self, _win = win) self.set(**kwds) def get_hscrolling(self): ( both from commandline and inside PythonwinIDE ) =========== Maybe it has also to do with the following serious bugs (which can be worked around - but smelling): B) a oneliner with just "import wx" crashes hard with F5 in Pythonwin IDE build 214/py2.6 - but not in build 212 (ntdll.dll) AppName: pythonwin.exe AppVer: 2.6.214.0 ModName: ntdll.dll ModVer: 5.1.2600.3520 Offset: 00044872 Code: 0xc015000f Address: 0x7c954872 (wxpython 2.8.11.0 (msw-unicode)) Only after this patch below (passing the SendMessage by a direct python call) it works again. (But with importing this oneliner file with Ctrl-I the IDE still crashes the same.) --- scintilla/bindings.py Sun Jan 04 15:01:18 2009 +++ scintilla/bindings.py Tue Oct 19 18:53:49 2010 @@ -33,7 +33,11 @@ def __init__(self, cmd): self.cmd = cmd def __call__(self, *args): - win32ui.GetMainFrame().SendMessage(win32con.WM_COMMAND, self.cmd) + # F5-run on simple "import wx" (wx2.8.11.0 (msw-unicode)) crashed in ntdll.dll: + ##win32ui.GetMainFrame().SendMessage(win32con.WM_COMMAND, self.cmd) + win32ui.GetMainFrame().OnCommand(self.cmd, 0) + #note: Ctrl-I/import still crashes because of WM_COMMAND in the line + C) all standalone win32ui GUI apps here crash hard with py2.3/pywin32-build214 at the very end/exit when they are executed from commandline "python somewin32uiapp.py". not with 212 and before. (they may crash as well as .pyw / win-apps - or even PythonWin.exe may crash at the end but nobody sees without a shell win) It seems, rude C-level leaks went into win32ui during 212 -> 214 - maybe because of the rework for py3k. Or is it all about one leak? 214 ui is hardly usable anywhere with various python versions - most practical use cases in and around win32ui become questionable. Yet there was no update for long time. I wonder that there are not many pywin32 bug reports in that direction. I only found : bug #2846720 (similar to C) ) and #2908939 perhaps. (->comments by M. Hammond, but no solution found) #3013558 Any ideas? Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: x.py Type: text/x-python Size: 10 bytes Desc: not available URL: From kc106_2005-win32 at yahoo.com Wed Oct 20 07:46:29 2010 From: kc106_2005-win32 at yahoo.com (kc106_2005-win32 at yahoo.com) Date: Tue, 19 Oct 2010 22:46:29 -0700 (PDT) Subject: [python-win32] Drag and Drop from Outlook Message-ID: <457235.81295.qm@web51405.mail.re2.yahoo.com> In an old message, there was some discussions about how to do D&D from Outlook to a wxPython app. I'm trying to do that. I can parse a .msg file. That's not a problem. The problem is retriving info from Outlook. Getting hint from http://www.pcreview.co.uk/forums/thread-1854594.php, this is what I am doing: class DropTarget(wx.PyDropTarget): def __init__(self): wx.PyDropTarget.__init__(self) self.do = wx.DataObjectComposite() self.textdo = wx.TextDataObject() self.filedo = wx.FileDataObject() self.targetdo = wx.PyDataObjectSimple(format = wx.DataFormat(0xc00e)) self.do.Add(self.textdo) self.do.Add(self.filedo) self.do.Add(self.targetdo) self.SetDataObject(self.do) def OnData(self, x, y, drag_result): if self.GetData(): df = self.do.GetReceivedFormat().GetType() if df in [wx.DF_UNICODETEXT, wx.DF_TEXT]: win32clipboard.OpenClipboard(0) data=win32clipboard.GetClipboardData(CF_HDROP) win32clipboard.CloseClipboard() tfile = win32api.DragQueryFile(drag_result) ... Unfortunately, the above code doesn't work. CF_HDROP is not a format GetClipboardData recognizes, and DragQueryFile returns None. Anybody know what the proper way of retrieving the dropped Outlook info? > Re: [python-win32] Drag and Drop from Outlook > >Mark Hammond >Tue, 13 Mar 2007 05:28:50 -0800 > > >> I am trying to make my application accepting drag and drop emails >>>from Outlook. I was told on the wxPython mailing list to try to use >>>win32com, but actually I have no idea which clipboard data format an >>>Outlook email has. I have tried to set up a custom drop target for >>>that: >>> >>>class MyDropTarget(wx.PyDropTarget): >>> def __init__(self): >>> wx.PyDropTarget.__init__(self) >>> >>> self.data = wx.CustomDataObject("Outlook Express Messages") >>> self.SetDataObject(self.data) >>> >>>But my app doesn't recongnize it with the identifier "Outlook Express >>>Messages". >> ... again as I told you on the wxpython ml I think it is not that >easy. You >have to use Extended Mapi to do that. At least Dmitry >Streblechenko, the >developer of OutlookSpy(really nice tool which uses a lot of mapi >functions) confirms that. See: >http://www.pcreview.co.uk/forums/thread-1854594.php > There also appears to be some confusion re 'Outlook' and 'Outlook Express', which are quite different beasts. If it really is 'Outlook Express', then I'm afraid neither win32com nor the OutlookSpy reference above are going to be any help. I'm not aware of any Python tools that will help with Outlook express (or indeed any free tools at all!) FWIW, the win32clipboard module should let you get the clipboard data as a binary blob (and win32com.mapi does wrap extended mapi), but I'm not sure that will help you either. Good luck, Mark -- John Henry From daryl.white at honeywell.com Thu Oct 21 00:04:54 2010 From: daryl.white at honeywell.com (White, Daryl (EPC COE)) Date: Wed, 20 Oct 2010 15:04:54 -0700 Subject: [python-win32] Behavior difference between Python using PyWin32 and PERL using OLE Message-ID: I'm using the ClearCase Automation Library and I'm getting different behaviors between Python (via the PyWin32 library) and PERL (via the OLE library). In the examples below, I'm trying to get a list of views and purposely ensuring that I am not in a directory associated with a view. So, starting in new command window and in the same non-view directory, when I execute the PERL example from IBM , I get a list of views (command is "perl C:\Python31\view.pl"). When I execute the Python script from the same directory and with command of "C:\Python31\python C:\Python31\comtest.py", I get the following exception: Traceback (most recent call last): File "C:\Python31\comtest.py", line 13, in allViews = ccApp.Views("False", "local") File "C:\Python31\lib\site-packages\win32com\client\__init__.py", line 463, in __getattr__ return self._ApplyTypes_(*args) File "C:\Python31\lib\site-packages\win32com\client\__init__.py", line 456, in _ApplyTypes_ self._oleobj_.InvokeTypes(dispid, 0, wFlags, retType, argTypes, *args), pywintypes.com_error: (-2147352567, 'Exception occurred.', (0, 'ClearCase.Application.1', 'No view is set, and current working directory is not in a view.\r\n', None, 0, -2147 467259), None) So, is there a difference/limitation using the COM interface via Python windows extensions and the OLE interface in PERL? =============================================================== use Win32::OLE; $DEBUG = 1; print "Instantiating CAL CC\n" if $DEBUG; my $cal_cc = Win32::OLE->new('ClearCase.Application') or die "Could not create the ClearCase Application object\n"; $cclsview = $cal_cc->Views("False","local"); $Views_Entries = $cclsview->Count; print "nbViews $Views_Entries\n"; $Views_Index = 1; while ($Views_Index <= $Views_Entries) { print "Processing View entry $CS_Index\n" if $DEBUG; $View = $cclsview->Item($Views_Index); $ViewName = $View->TagName; $ViewIsSnapshot = $View->IsSnapShot; print "View $ViewName $ViewIsSnapshot\n"; $Views_Index++; } And use the following Python (ver 3.1, using Python extensions version 214) script, import win32com.client import sys ccApp = win32com.client.Dispatch("ClearCase.Application") allViews = ccApp.Views("False", "local") vob = ccApp.VOB("\MYVOB") print ("TagName = ", vob.TagName) print ("IsMounted = ", vob.IsMounted) view = ccApp.View print ("Tag = ", view.TagName) list = view.ConfigSpec -------------- next part -------------- An HTML attachment was scrubbed... URL: From skippy.hammond at gmail.com Thu Oct 21 01:27:06 2010 From: skippy.hammond at gmail.com (Mark Hammond) Date: Thu, 21 Oct 2010 10:27:06 +1100 Subject: [python-win32] Drag and Drop from Outlook In-Reply-To: <457235.81295.qm@web51405.mail.re2.yahoo.com> References: <457235.81295.qm@web51405.mail.re2.yahoo.com> Message-ID: <4CBF7ACA.6070805@gmail.com> On 20/10/2010 4:46 PM, kc106_2005-win32 at yahoo.com wrote: > Unfortunately, the above code doesn't work. CF_HDROP is not a format > GetClipboardData recognizes, and DragQueryFile returns None. Anybody know what > the proper way of retrieving the dropped Outlook info? I'm not sure what you mean by CF_HDROP not being recognized - it works for me. Using Windows Explorer, select a file and "copy" it to the clipboard. Then run the following script: import win32clipboard, win32con win32clipboard.OpenClipboard() try: got = win32clipboard.GetClipboardData(win32con.CF_HDROP) print got finally: win32clipboard.CloseClipboard() You should get back a tuple listing the filenames on the clipboard. I'm not sure what outlook does here, but you may also like to copy the outlook object to the clipboard and run the win32com/demos/dump_clipboard.py script to see what can be found. HTH, Mark From rupole at hotmail.com Thu Oct 21 03:02:49 2010 From: rupole at hotmail.com (Roger Upole) Date: Wed, 20 Oct 2010 21:02:49 -0400 Subject: [python-win32] PyGUI blobedit creashes with pywin32-214 but not 212 - traceback - related problems References: Message-ID: "Robert" wrote in message news:i9kmoi$clm$1 at dough.gmane.org... > A) > > What could be the cause for this exception of PyGUI with > pywin32-build214 - but not with build 212 :? > > Traceback (most recent call last): > File "blobedit.py", line 131, in > BlobApp().run() > File "C:\Python26\lib\site-packages\GUI\GenericGApplications.py", line > 122, in run > self.process_args(sys.argv[1:]) > File "C:\Python26\lib\site-packages\GUI\Generic\GApplications.py", line > 251, in process_args > self.open_app() > File "blobedit.py", line 32, in open_app > self.new_cmd() > File "C:\Python26\lib\site-packages\GUI\Generic\GApplications.py", line > 219, in new_cmd > self.make_window(doc) > File "blobedit.py", line 40, in make_window > cursor = self.blob_cursor) > File "C:\Python26\lib\site-packages\GUI\Win32\ScrollableViews.py", line > 32, in __init__ > GScrollableView.__init__(self, _win = win) > win32ui.error: The object has been destroyed. > > > > > class ScrollableView(GScrollableView): > > _line_scroll_amount = default_line_scroll_amount > > def __init__(self, **kwds): > kwds.setdefault('extent', default_extent) > win = ui.CreateView(win_dummy_doc) > win.CreateWindow(win_none, 0, win_style, (0, 0, 100, 100)) > GScrollableView.__init__(self, _win = win) > self.set(**kwds) > > def get_hscrolling(self): > > > > ( both from commandline and inside PythonwinIDE ) > The problem stems from these 2 lines in ScrollableViews.py: rev = ui.CreateRichEditView() win_dummy_doc = rev.GetDocument() The win32ui framework really should not allow a view to be created without a valid document. In win32view.cpp, there's a C++ class that allows some protected members of an MFC class to be set which makes this possible. Essentially this is a hack on top of a hack, and I'm not sure why it ever worked. A while back I thought I had a solution to allow it to work again, but it only caused unpredictable results and crashes further down the road. The PyGUI framework can probably create a valid MFC document to use as a dummy with a little work. Something like: dt=win32ui.CreateDocTemplate(win32ui.IDR_PYTHONTYPE) win_dummy_doc=dt.DoCreateDoc() may do the trick. Also, the win32ui framework needs to disallow the current behaviour altogether. I think it was originally allowed because it was attempting to instantiate MFC objects in the wrong order. > B) a oneliner with just "import wx" crashes hard with F5 in Pythonwin IDE > build 214/py2.6 - but not in build 212 (ntdll.dll) > > AppName: pythonwin.exe AppVer: 2.6.214.0 ModName: ntdll.dll > ModVer: 5.1.2600.3520 Offset: 00044872 > Code: 0xc015000f > Address: 0x7c954872 > (wxpython 2.8.11.0 (msw-unicode)) > > Only after this patch below (passing the SendMessage by a direct python > call) it works again. (But with importing this oneliner file with Ctrl-I > the IDE still > crashes the same.) > > --- scintilla/bindings.py Sun Jan 04 15:01:18 2009 > +++ scintilla/bindings.py Tue Oct 19 18:53:49 2010 > @@ -33,7 +33,11 @@ > def __init__(self, cmd): > self.cmd = cmd > def __call__(self, *args): > - win32ui.GetMainFrame().SendMessage(win32con.WM_COMMAND, self.cmd) > + # F5-run on simple "import wx" (wx2.8.11.0 (msw-unicode)) crashed in > ntdll.dll: > + ##win32ui.GetMainFrame().SendMessage(win32con.WM_COMMAND, self.cmd) > + win32ui.GetMainFrame().OnCommand(self.cmd, 0) > + #note: Ctrl-I/import still crashes because of WM_COMMAND in the line > + Trying to run one GUI framework inside of another is a sure recipe for disaster. Both will be trying to process messages, with race conditions and memory conflicts galore. The short answer is "don't do that". > C) all standalone win32ui GUI apps here crash hard with > py2.3/pywin32-build214 at the very end/exit when they are executed from > commandline "python > somewin32uiapp.py". not with 212 and before. (they may crash as well as > .pyw / win-apps - or even PythonWin.exe may crash at the end but nobody > sees without a > shell win) > Can you post a small script that exhibits this ? Roger From greg.ewing at canterbury.ac.nz Thu Oct 21 04:31:05 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 21 Oct 2010 15:31:05 +1300 Subject: [python-win32] PyGUI blobedit creashes with pywin32-214 but not 212 - traceback - related problems In-Reply-To: References: Message-ID: <4CBFA5E9.7090100@canterbury.ac.nz> On 21/10/10 14:02, Roger Upole wrote: > The problem stems from these 2 lines in ScrollableViews.py: > > rev = ui.CreateRichEditView() > win_dummy_doc = rev.GetDocument() > > The win32ui framework really should not allow a view to be created > without a valid document. Actually, the problem is that it *won't* allow a view to be created without a document, even though it should. If I remember correctly, at the MFC level, the constructor for the view object I'm using doesn't even take a Document as an argument -- you set it later if you want one. Win32ui goes out of its way to accept one at construction time. This wouldn't be such a serious problem, except that win32ui doesn't seem to provide any way of creating a Document without a resource -- hence the above kludge. > The PyGUI framework can probably create a valid MFC document to use > as a dummy with a little work. > Something like: > dt=win32ui.CreateDocTemplate(win32ui.IDR_PYTHONTYPE) > win_dummy_doc=dt.DoCreateDoc() That may work if you run the program using the pythonwin executable, which contains the referenced resource. But I want pygui programs to be runnable using the standard Python interpreter, which means I can't rely on resources at all. There are two ways that pywin32 could be modified to fix this problem: 1) Allow a View to be created without a Document (preferable). 2) Provide a way of creating a Document without requiring a resource (e.g. from a string template). -- Greg From rupole at hotmail.com Thu Oct 21 08:26:58 2010 From: rupole at hotmail.com (Roger Upole) Date: Thu, 21 Oct 2010 02:26:58 -0400 Subject: [python-win32] PyGUI blobedit creashes with pywin32-214 but not 212 - traceback - related problems References: <4CBFA5E9.7090100@canterbury.ac.nz> Message-ID: "Greg Ewing" wrote in message news:4CBFA5E9.7090100 at canterbury.ac.nz... > On 21/10/10 14:02, Roger Upole wrote: > >> The problem stems from these 2 lines in ScrollableViews.py: >> >> rev = ui.CreateRichEditView() >> win_dummy_doc = rev.GetDocument() >> >> The win32ui framework really should not allow a view to be created >> without a valid document. > > Actually, the problem is that it *won't* allow a view to be > created without a document, even though it should. If I remember > correctly, at the MFC level, the constructor for the view object > I'm using doesn't even take a Document as an argument -- you set > it later if you want one. Win32ui goes out of its way to accept > one at construction time. > > This wouldn't be such a serious problem, except that win32ui > doesn't seem to provide any way of creating a Document without > a resource -- hence the above kludge. You instantiate the MFC view object without a document, but in order to actually create a window and do anything useful with it, it needs a valid document. For some reason, the win32ui framework chooses to accept a document when the view is initially created instead of when its window is created. (That's where MFC accepts the associated document object.) I have yet to be able to determine where the dummy document is actually coming from in build 212. When I try to run it in a debug build, so many asserts are triggered that it would take forever to step thru it. >> The PyGUI framework can probably create a valid MFC document to use >> as a dummy with a little work. >> Something like: >> dt=win32ui.CreateDocTemplate(win32ui.IDR_PYTHONTYPE) >> win_dummy_doc=dt.DoCreateDoc() > > That may work if you run the program using the pythonwin > executable, which contains the referenced resource. But I want > pygui programs to be runnable using the standard Python > interpreter, which means I can't rely on resources at all. The resource is actually in win32ui.pyd, rather than in Pythonwin itself. I've just verified that this method works from plain python.exe. The scrollable view test runs with this change. Roger From kxroberto at googlemail.com Thu Oct 21 14:47:16 2010 From: kxroberto at googlemail.com (Robert) Date: Thu, 21 Oct 2010 14:47:16 +0200 Subject: [python-win32] and PyGUI notes - Re: PyGUI blobedit creashes with pywin32-214 but not 212 - traceback - related problems In-Reply-To: References: <4CBFA5E9.7090100@canterbury.ac.nz> Message-ID: Roger Upole wrote: > > "Greg Ewing" wrote in message > news:4CBFA5E9.7090100 at canterbury.ac.nz... >> On 21/10/10 14:02, Roger Upole wrote: >> >>> The problem stems from these 2 lines in ScrollableViews.py: >>> >>> rev = ui.CreateRichEditView() >>> win_dummy_doc = rev.GetDocument() >>> >>> The win32ui framework really should not allow a view to be created >>> without a valid document. >> >> Actually, the problem is that it *won't* allow a view to be >> created without a document, even though it should. If I remember >> correctly, at the MFC level, the constructor for the view object >> I'm using doesn't even take a Document as an argument -- you set >> it later if you want one. Win32ui goes out of its way to accept >> one at construction time. >> >> This wouldn't be such a serious problem, except that win32ui >> doesn't seem to provide any way of creating a Document without >> a resource -- hence the above kludge. > > You instantiate the MFC view object without a document, but in order > to actually create a window and do anything useful with it, it needs > a valid document. For some reason, the win32ui framework > chooses to accept a document when the view is initially created > instead of when its window is created. (That's where MFC > accepts the associated document object.) > > I have yet to be able to determine where the dummy document is > actually coming from in build 212. When I try to run it in a > debug build, so many asserts are triggered that it would take > forever to step thru it. > >>> The PyGUI framework can probably create a valid MFC document to use >>> as a dummy with a little work. >>> Something like: >>> dt=win32ui.CreateDocTemplate(win32ui.IDR_PYTHONTYPE) >>> win_dummy_doc=dt.DoCreateDoc() >> >> That may work if you run the program using the pythonwin >> executable, which contains the referenced resource. But I want >> pygui programs to be runnable using the standard Python >> interpreter, which means I can't rely on resources at all. > > The resource is actually in win32ui.pyd, rather than in Pythonwin > itself. I've just verified that this method works from plain python.exe. > The scrollable view test runs with this change. > I should have written yesterday as I already found/worked on the doctemp problem yesterday, just I didn't completely solve (or better "workaround"), so I shifted .. (py2.6.5 / pywin32-214) A) in ScrollableViews.py globals: ##win_dummy_doc = ui.CreateRichEditView().GetDocument() doctemp = ui.CreateDocTemplate(ui.IDR_PYTHONTYPE) win_dummy_doc = doctemp.DoCreateDoc() #print "ScrollableViews: Created dummy doc" This lets start the blobedit.py / my test app. but at the exit hard crash. TestScrollableViews.py / 12-scroll.py crashes hard even at start (runtime to terminate in unusual...) B) in ScrollableViews.py globals: ##win_dummy_doc = ui.CreateRichEditView().GetDocument() #print "ScrollableViews: Created dummy doc" doctemp = ui.CreateDocTemplate(ui.IDR_PYTHONTYPE) import pywin.mfc.object doctemp = pywin.mfc.object.CmdTarget(doctemp) # otherwise we crash at exit win_dummy_doc = doctemp.DoCreateDoc() blobedit.py & 12-scroll.py now start, work and exit correct from commandline. (well the 12-scroll.py displays/user-interacts mostly buggy but thats not the problem here) However when I make multiple starts / close of the app-window in IDE/one process, or when in an app the total number of ScrollView's counts down to zero and then up again, then still a hard crash (somehow the doc is too smart and gets corrupt at zero count) C) the attached .patch : blobedit.py & 12-scroll.py now start, work and exit, and multi-boot, views count to zero and up again .. correct from commandline, python.exe & pythonw.exe & frozone with py2exe. D) But 39-text_editor.py with CRichEdit's (nothing to do with scrollview) and may test app with (scrollview +) richedits still crashes hard at exit when run with pythonw.exe (but not with python.exe !). I tried feeding in no-None RichEditDoc(templates) similar to scrollview .patch in dozends of ways, plus terminating, .close()ing docs/doctemps in various ways, but it didn't solve. I failed terribly. Maybe for such and similar reasons many apps crash at exit with 214. The (damn) Document/Template stuff in win32ui somehow seems to have become more instable in 214 (213?). danging pointers or so. (I often use ScrollViews, SplitterViews, RichEdits, etc. in win32ui apps - not wanting to use the damn MFC doc/view mechansim (pure Python is much better for this), just to exploit the Window features ... before in infinite time I rewrite the behavior of the MFC-goodies in pure win32gui ;-) ) Robert PS: PyGUI notes PyGUI is/seems a nice plan. rather direct on platform libs ( theorically - still damn MFC on Win ;-) ). If combined with a slim Mingw/msvcrt.dll complied Python ... But perhaps long time and debugging to get real world usability (Win). One could use the (bugfixed) existing behaviour, plus __getattr__ on the ._win Component member etc for first and hope for platform independent behavior later (some 90%+x auto-translate code). As of now the frame windows open somehow randomly in background or foreground or somewhere (questionable win32 parent window management?), many tests like above show ill display behavior, no default Win-Keys like Alt-F4, Alt--Menu Keys etc ... few controls. image Resources rarely found / hardly freezable. py2exe and cxfreeze don't find the PyGUI autoloader stuff, one has to collect&pull some 80+ paths by extra function. will try and go into it a little more. Further notes so far: currently no pythonic speedy late import is done for expensive stuff throughout the library to exploit the dynamic binding (like e.g. done in above .patch in GetDummyDoc). A simple app pre-imports almost the whole mess, 80+ GUI mods plus pywin fully 1:1, even win32com.shell things before you see anything (and rarely use all these things), problems for freezer excludes. (the __init__.py autoloader thus doesn't save a lot) like a fully statically linked C program/library (e.g. wx). 1s and more boot time on laptops on 2nd load, though it shall be a very thin direct library. Principally (=more) disturbs me (original sin) that the method/function names throughout the lib are in abc_def style - exactly the same as variables and properties. Not even Java'ish "abcDef" for Functions. So upon autocompletion and rather new to the lib one is very very disturbed: xy.changed .. its a function! ;-) By experience there is no trouble mistaking classes for functions (one doesn't even need a C in front of CDocument or so) , but much trouble: confusing functions, vars and properties. No one should write a new GUI-lib which does not use AbcDef for method names. The menus seem to be a litte too automatic, but have to go into it further, if things can be avoided, menu icons etc things can principally be extended ... The string style constants/events etc. ... may disapear without trace if a letter is typed wrong (difficult for auto-completers, pychecker, ...). Didn't come to the new auto layout features (like wx / glade) so far .. which would be a key thing. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: .patch URL: From kxroberto at googlemail.com Thu Oct 21 14:51:44 2010 From: kxroberto at googlemail.com (Robert) Date: Thu, 21 Oct 2010 14:51:44 +0200 Subject: [python-win32] PyGUI blobedit creashes with pywin32-214 but not 212 - traceback - related problems In-Reply-To: References: Message-ID: Roger Upole wrote: > > "Robert" wrote in message > news:i9kmoi$clm$1 at dough.gmane.org... > >> B) a oneliner with just "import wx" crashes hard with F5 in Pythonwin IDE >> build 214/py2.6 - but not in build 212 (ntdll.dll) >> >> AppName: pythonwin.exe AppVer: 2.6.214.0 ModName: ntdll.dll >> ModVer: 5.1.2600.3520 Offset: 00044872 >> Code: 0xc015000f >> Address: 0x7c954872 >> (wxpython 2.8.11.0 (msw-unicode)) >> >> Only after this patch below (passing the SendMessage by a direct python >> call) it works again. (But with importing this oneliner file with Ctrl-I >> the IDE still >> crashes the same.) >> >> --- scintilla/bindings.py Sun Jan 04 15:01:18 2009 >> +++ scintilla/bindings.py Tue Oct 19 18:53:49 2010 >> @@ -33,7 +33,11 @@ >> def __init__(self, cmd): >> self.cmd = cmd >> def __call__(self, *args): >> - win32ui.GetMainFrame().SendMessage(win32con.WM_COMMAND, self.cmd) >> + # F5-run on simple "import wx" (wx2.8.11.0 (msw-unicode)) crashed in >> ntdll.dll: >> + ##win32ui.GetMainFrame().SendMessage(win32con.WM_COMMAND, self.cmd) >> + win32ui.GetMainFrame().OnCommand(self.cmd, 0) >> + #note: Ctrl-I/import still crashes because of WM_COMMAND in the line >> + > > Trying to run one GUI framework inside of another is a sure recipe for > disaster. Both will be trying to process messages, with race conditions > and memory conflicts galore. The short answer is "don't do that". > I'm doing this since adam and eve with wx, win32ui and similar. When there was/is a little problem I first try flatten it. e.g. join the OnIdle or message translation. 2 or 3 things. Have seen people which edit code, save, start the GUI app , bug, exit , edit, start/test again .. With dynamic Python I edit code while it runs, objects/windows live; fumble, try, autocomplete on the living objects, sys.exepthook postmortem pywin debugger, set self=current_winthing_i_focus_on_for_a_while in the interactive , better autocompletion, Ctrl+Enter debug etc ... Even little reload code, exchange classes at runtime on big apps with big status ... reboot after 30x or so. Pythonwin is good therefor because of the joint thread. Its a feature not ... I think there is simply something not as good as it was in build 212. It may indicate/connect with deeper problems - like mentioned. And the problem is just about "import wx" at F5/Ctrl-I time. reproducible. no GUI start at all so far. the crash is not when doing "import wx" first in interactive, and then use F5 on a wx script... something with command handler status, GIL/reenter or so. Would be happy about any idea. Best Robert From timr at probo.com Thu Oct 21 19:17:12 2010 From: timr at probo.com (Tim Roberts) Date: Thu, 21 Oct 2010 10:17:12 -0700 Subject: [python-win32] Behavior difference between Python using PyWin32 and PERL using OLE In-Reply-To: References: Message-ID: <4CC07598.9090105@probo.com> White, Daryl (EPC COE) wrote: > > I?m using the ClearCase Automation Library and I?m getting different > behaviors between Python (via the PyWin32 library) and PERL (via the > OLE library). In the examples below, I?m trying to get a list of views > and purposely ensuring that I am not in a directory associated with a > view. So, starting in new command window and in the same non-view > directory, when I execute the PERL example from IBM , I get a list of > views (command is ?perl C:\Python31\view.pl?). When I execute the > Python script from the same directory and with command of > ?C:\Python31\python C:\Python31\comtest.py?, I get the following > exception: > > > > Traceback (most recent call last): > > File "C:\Python31\comtest.py", line 13, in > > allViews = ccApp.Views("False", "local") > > File "C:\Python31\lib\site-packages\win32com\client\__init__.py", > line 463, in __getattr__ > > return self._ApplyTypes_(*args) > > File "C:\Python31\lib\site-packages\win32com\client\__init__.py", > line 456, in _ApplyTypes_ > > self._oleobj_.InvokeTypes(dispid, 0, wFlags, retType, argTypes, > *args), > > pywintypes.com_error: (-2147352567, 'Exception occurred.', (0, > 'ClearCase.Application.1', 'No view is set, and current working > directory is not in a view.\r\n', None, 0, -2147467259), None) > > > > So, is there a difference/limitation using the COM interface via > Python windows extensions and the OLE interface in PERL? > The "Views" property is supposed to take a boolean, not a string. Shouldn't that be False instead of "False"? -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From greg.ewing at canterbury.ac.nz Fri Oct 22 01:38:56 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 22 Oct 2010 12:38:56 +1300 Subject: [python-win32] PyGUI blobedit creashes with pywin32-214 but not 212 - traceback - related problems In-Reply-To: References: <4CBFA5E9.7090100@canterbury.ac.nz> Message-ID: <4CC0CF10.10009@canterbury.ac.nz> Roger Upole wrote: > The resource is actually in win32ui.pyd, rather than in Pythonwin > itself. I've just verified that this method works from plain python.exe. That's great news! I thought I had already tried something very much like what you suggested, but maybe I hadn't hit upon the right resource ID. (It would help if the available resources were actually *documented* somewhere...) Looks like we may have a solution, thanks. -- Greg From greg.ewing at canterbury.ac.nz Fri Oct 22 01:25:34 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 22 Oct 2010 12:25:34 +1300 Subject: [python-win32] PyGUI blobedit creashes with pywin32-214 but not 212 - traceback - related problems In-Reply-To: References: <4CBFA5E9.7090100@canterbury.ac.nz> Message-ID: <4CC0CBEE.3090503@canterbury.ac.nz> Roger Upole wrote: > You instantiate the MFC view object without a document, but in order > to actually create a window and do anything useful with it, it needs > a valid document. Are you absolutely sure about that? At the MFC level, I can't see anything to stop you from instantiating a CView and calling its Create method without ever mentioning a CDocument. The RichEditView kludge ends up creating a PyDocument object wrapping a null pointer, and MFC seemed to be happy with whatever pywin32 build 212 and earlier did with that. -- Greg From rupole at hotmail.com Fri Oct 22 04:18:07 2010 From: rupole at hotmail.com (Roger Upole) Date: Thu, 21 Oct 2010 22:18:07 -0400 Subject: [python-win32] PyGUI blobedit creashes with pywin32-214 but not 212 - traceback - related problems References: <4CBFA5E9.7090100@canterbury.ac.nz> <4CC0CBEE.3090503@canterbury.ac.nz> Message-ID: Greg Ewing wrote: > Roger Upole wrote: > >> You instantiate the MFC view object without a document, but in order >> to actually create a window and do anything useful with it, it needs >> a valid document. > > Are you absolutely sure about that? > > At the MFC level, I can't see anything to stop you from > instantiating a CView and calling its Create method without > ever mentioning a CDocument. > > The RichEditView kludge ends up creating a PyDocument object > wrapping a null pointer, and MFC seemed to be happy with > whatever pywin32 build 212 and earlier did with that. > Not exactly happy, no. In debug mode it triggers any number of asserts. In a release build without the asserts, it becomes possible to trigger crashes by calling any methods on the view that need access to the associated document. Roger From greg.ewing at canterbury.ac.nz Fri Oct 22 04:33:08 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 22 Oct 2010 15:33:08 +1300 Subject: [python-win32] and PyGUI notes - Re: PyGUI blobedit creashes with pywin32-214 but not 212 - traceback - related problems In-Reply-To: References: <4CBFA5E9.7090100@canterbury.ac.nz> Message-ID: <4CC0F7E4.20904@canterbury.ac.nz> On 22/10/10 01:47, Robert wrote: > But perhaps long time and debugging to get real world usability (Win). > One could use the (bugfixed) existing behaviour, plus __getattr__ on the > ._win Component member etc for first and hope for platform independent > behavior later (some 90%+x auto-translate code). I don't understand what you're talking about here. > py2exe and cxfreeze don't find the PyGUI autoloader stuff, one has to > collect&pull some 80+ paths by extra function. Yes, that's a bit of a problem. For apps intended to be py2exe'd, it might be better to explicitly import things from the relevant submodules, e.g. 'from GUI.Windows import Window' rather than from 'GUI import Window'. That way, py2exe will be able to find the modules that you use, together with the ones they depend on. > will try and go into it a little more. > > Further notes so far: currently no pythonic speedy late import is done > for expensive stuff throughout the library to exploit the dynamic > binding (like e.g. done in above .patch in GetDummyDoc). I'm not sure if that helps much. If you're using ScrollableViews in your application at all, you're going to need a dummy doc template at some point, so you might as well get the overhead out of the way early on. This might be a difference in philosophy -- it annoys me when an application pauses randomly during its operation to load stuff up, so I tend to design things so that everything that is almost certain to be used is imported at startup. If you have an application that only rarely uses ScrollableViews, you can deal with that by delaying your import of the ScrollableView class until you need it. > A simple app > pre-imports almost the whole mess, 80+ GUI mods plus pywin fully 1:1, I'm not sure if there's much that can be done about that. There's quite a lot of infrastructure shared by all component classes, and the intertwinedness of the generic and platform-specific code requires splitting it into quite a lot of modules. Maybe the code could be pre-processed to fold things together into larger modules for installation, although I'm not sure how much that would help -- the total amount of code loaded would be the same. > (the __init__.py autoloader thus doesn't save a lot) The purpose of the autoloader isn't so much to delay importing as to avoid importing things that won't be used at all. Currently the amount of optional stuff is a relatively small proportion of the whole, but that will change as more features are added. > No one should write a new > GUI-lib which does not use AbcDef for method names. We have another philosophical difference, then, because I believe that no-one should write a Python library that doesn't follow PEP 8 conventions, unless it's exposing a pre-existing API. > The menus seem to be a litte too automatic, Yes, I know, and I'm thinking about ways to make it easier to customise them. > The string style constants/events etc. ... may disapear without trace if > a letter is typed wrong I acknowledge that more could be done to validate these. > (difficult for auto-completers, pychecker, ...). Yeah... I just like them better than named constants, somehow. I think it's because they're automatically context-sensitive, so it avoids the need to give them unique prefixes. I don't use auto-completion, so that aspect of it didn't occur to me. Perhaps I could compromise by providing named constants for them as an alternative. > Didn't come to the new auto layout features (like wx / glade) so far .. PyGUI does have auto layout features, it's just that they don't work quite the same way as they do in wx or gtk. There's an assumption that you will be laying things out once when you create the window, and after that it's just a matter of moving and resizing things sensibly when the user changes the window size. I'm thinking about ways to make more dynamic layouts possible, but there are some tricky aspects to it, such as the possibility of infinite loops occurring if layout changes can propagate both up and down the hierarchy. -- Greg From nathon.py at gmail.com Fri Oct 22 15:10:08 2010 From: nathon.py at gmail.com (nathon py) Date: Fri, 22 Oct 2010 21:10:08 +0800 Subject: [python-win32] BringWindowToTop doesn't work,anyone have try it? Message-ID: # Let's say a window with title 'D:\\labBufferSpace' exists. # Code below does not work in DOS, or just double it. # But it works well in PythonWin. # I do not want to run it in PythonWin every time. # I take it as a bug, and reported it to sourceforge.net, did I do that wrong? ######################################################## import win32ui,win32con,pythoncom,win32gui,win32process,win32api pwin = win32gui.FindWindow(0,'D:\\labBufferSpace') win32gui.BringWindowToTop(pwin) -------------- next part -------------- An HTML attachment was scrubbed... URL: From timr at probo.com Fri Oct 22 18:57:50 2010 From: timr at probo.com (Tim Roberts) Date: Fri, 22 Oct 2010 09:57:50 -0700 Subject: [python-win32] BringWindowToTop doesn't work, anyone have try it? In-Reply-To: References: Message-ID: <4CC1C28E.4070104@probo.com> nathon py wrote: > # Let's say a window with title 'D:\\labBufferSpace' exists. > # Code below does not work in DOS, or just double it. > # But it works well in PythonWin. > # I do not want to run it in PythonWin every time. > # I take it as a bug, and reported it to sourceforge.net > , did I do that wrong? > ######################################################## > import win32ui,win32con,pythoncom,win32gui,win32process,win32api > pwin = win32gui.FindWindow(0,'D:\\labBufferSpace') > win32gui.BringWindowToTop(pwin) If it is a bug, it is a bug in the Win32 API. This same code also does not work in a console app written in C. Use SetForegroundWindow instead of BringWindowToTop. That works. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From kc106_2005-win32 at yahoo.com Thu Oct 21 07:27:31 2010 From: kc106_2005-win32 at yahoo.com (kc106_2005-win32 at yahoo.com) Date: Wed, 20 Oct 2010 22:27:31 -0700 (PDT) Subject: [python-win32] Drag and Drop from Outlook Message-ID: <449391.21654.qm@web51403.mail.re2.yahoo.com> Thanks for the reply, Mark. I did a "copy" from Outlook, and then run dump_clipboard. Here's what comes up: Dumping all clipboard formats... Clipboard format 49161 -> got 4 bytes via HGLOBAL -> got 4 bytes via IStream Clipboard format 49955 -> got 168 bytes via HGLOBAL -> got 168 bytes via IStream Clipboard format 49778 -> got 336 bytes via HGLOBAL -> got 336 bytes via IStream Clipboard format 49374 -> got 668 bytes via HGLOBAL -> got 668 bytes via IStream Clipboard format 49373 Traceback (most recent call last): File "C:\Python25\Lib\site-packages\win32com\demos\dump_clipboard.py", line 61 , in DumpClipboard() File "C:\Python25\Lib\site-packages\win32com\demos\dump_clipboard.py", line 32 , in DumpClipboard medium = do.GetData(fetc_query) pywintypes.com_error: (-2147024882, 'Not enough storage is available to complete this operation.', None, None) Now, if I drag a message from Outlook and drop it onto a wxpython application and then run dump_clipboard.py. Here's what I got: Dumping all clipboard formats... Clipboard format 49161 -> got 4 bytes via HGLOBAL -> got 4 bytes via IStream Clipboard format 49655 -> got 36 bytes via HGLOBAL -> got 36 bytes via IStream Clipboard format 49379 -> got 269 bytes via HGLOBAL -> got 269 bytes via IStream Clipboard format 49729 -> got 490 bytes via HGLOBAL -> got 490 bytes via IStream Clipboard format 49730 -> got 8 bytes via HGLOBAL -> got 8 bytes via IStream Clipboard format CF_UNICODETEXT -> got 36 bytes via HGLOBAL -> got 36 bytes via IStream Clipboard format CF_TEXT -> got 18 bytes via HGLOBAL -> got 18 bytes via IStream Clipboard format 49731 -> got 146 bytes via HGLOBAL -> got 146 bytes via IStream Clipboard format 49171 -> got 312 bytes via HGLOBAL -> got 312 bytes via IStream Clipboard format CF_LOCALE -> got 4 bytes via HGLOBAL -> got 4 bytes via IStream Clipboard format CF_OEMTEXT -> got 18 bytes via HGLOBAL -> got 18 bytes via IStream Does that give you any hints? Mark Hammond wrote: On 20/10/2010 4:46 PM, kc106_2005-win32 at yahoo.com wrote: > >Unfortunately, the above code doesn't work. CF_HDROP is not a format >>GetClipboardData recognizes, and DragQueryFile returns None. Anybody know what > >>the proper way of retrieving the dropped Outlook info? >> I'm not sure what you mean by CF_HDROP not being recognized - it works for me. Using Windows Explorer, select a file and "copy" it to the clipboard. Then run the following script: import win32clipboard, win32con win32clipboard.OpenClipboard() try: got = win32clipboard.GetClipboardData(win32con.CF_HDROP) print got finally: win32clipboard.CloseClipboard() You should get back a tuple listing the filenames on the clipboard. I'm not sure what outlook does here, but you may also like to copy the outlook object to the clipboard and run the win32com/demos/dump_clipboard.py script to see what can be found. HTH, Mark -- John Henry From skippy.hammond at gmail.com Sat Oct 23 01:47:12 2010 From: skippy.hammond at gmail.com (Mark Hammond) Date: Sat, 23 Oct 2010 10:47:12 +1100 Subject: [python-win32] Drag and Drop from Outlook In-Reply-To: <449391.21654.qm@web51403.mail.re2.yahoo.com> References: <449391.21654.qm@web51403.mail.re2.yahoo.com> Message-ID: <4CC22280.5080703@gmail.com> On 21/10/2010 4:27 PM, kc106_2005-win32 at yahoo.com wrote: > Thanks for the reply, Mark. > > I did a "copy" from Outlook, and then run dump_clipboard. Here's what comes up: > ... > Traceback (most recent call last): > File "C:\Python25\Lib\site-packages\win32com\demos\dump_clipboard.py", line 61 > , in > DumpClipboard() > File "C:\Python25\Lib\site-packages\win32com\demos\dump_clipboard.py", line 32 > , in DumpClipboard > medium = do.GetData(fetc_query) > pywintypes.com_error: (-2147024882, 'Not enough storage is available to complete > this operation.', None, None) Bugger :) Try modifying the script so that the COM error in line 32 is ignored and re-running it. > Now, if I drag a message from Outlook and drop it onto a wxpython application > and then run dump_clipboard.py. Here's what I got: > > Dumping all clipboard formats... > Clipboard format 49161 > -> got 4 bytes via HGLOBAL > -> got 4 bytes via IStream > Clipboard format 49655 > -> got 36 bytes via HGLOBAL > -> got 36 bytes via IStream > Clipboard format 49379 > -> got 269 bytes via HGLOBAL > -> got 269 bytes via IStream > Clipboard format 49729 > -> got 490 bytes via HGLOBAL > -> got 490 bytes via IStream > Clipboard format 49730 > -> got 8 bytes via HGLOBAL > -> got 8 bytes via IStream > Clipboard format CF_UNICODETEXT > -> got 36 bytes via HGLOBAL > -> got 36 bytes via IStream > Clipboard format CF_TEXT > -> got 18 bytes via HGLOBAL > -> got 18 bytes via IStream > Clipboard format 49731 > -> got 146 bytes via HGLOBAL > -> got 146 bytes via IStream > Clipboard format 49171 > -> got 312 bytes via HGLOBAL > -> got 312 bytes via IStream > Clipboard format CF_LOCALE > -> got 4 bytes via HGLOBAL > -> got 4 bytes via IStream > Clipboard format CF_OEMTEXT > -> got 18 bytes via HGLOBAL > -> got 18 bytes via IStream That is strange - it looks very much like simple text in the clipboard. Cheers, Mark From nathon.py at gmail.com Sat Oct 23 02:44:28 2010 From: nathon.py at gmail.com (nathon py) Date: Sat, 23 Oct 2010 08:44:28 +0800 Subject: [python-win32] BringWindowToTop doesn't work, anyone have try it? In-Reply-To: <4CC1C28E.4070104@probo.com> References: <4CC1C28E.4070104@probo.com> Message-ID: guys, thanks a lot, i will try and share the result 2010/10/23 Tim Roberts > nathon py wrote: > > # Let's say a window with title 'D:\\labBufferSpace' exists. > > # Code below does not work in DOS, or just double it. > > # But it works well in PythonWin. > > # I do not want to run it in PythonWin every time. > > # I take it as a bug, and reported it to sourceforge.net > > , did I do that wrong? > > ######################################################## > > import win32ui,win32con,pythoncom,win32gui,win32process,win32api > > pwin = win32gui.FindWindow(0,'D:\\labBufferSpace') > > win32gui.BringWindowToTop(pwin) > > If it is a bug, it is a bug in the Win32 API. This same code also does > not work in a console app written in C. > > Use SetForegroundWindow instead of BringWindowToTop. That works. > > -- > Tim Roberts, timr at probo.com > Providenza & Boekelheide, Inc. > > _______________________________________________ > python-win32 mailing list > python-win32 at python.org > http://mail.python.org/mailman/listinfo/python-win32 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathon.py at gmail.com Sat Oct 23 08:38:27 2010 From: nathon.py at gmail.com (nathon py) Date: Sat, 23 Oct 2010 14:38:27 +0800 Subject: [python-win32] BringWindowToTop doesn't work, anyone have try it? In-Reply-To: References: <4CC1C28E.4070104@probo.com> Message-ID: The most important thing is I'am sorry for saying that's a bug. 2010/10/23 nathon py > The bug has been closed, you can check here > > http://sourceforge.net/tracker/?func=detail&atid=551954&aid=3077881&group_id=78018 > with an answer 'This is just a "feature" of Windows' by mhammond > . > > @Tim, I try the way you mentioned, it really works. I've tried > ShowWindow(),EnableWindow(),etc, before. It never woks. > @Preston, I read the tutorial you gave, it's very helpful. > I use the command line as following : > start pythonwin /app XXX.py > It works and producing a window, if i go deep into the pythonWin, it's not > a problem. > > thanks a lot for your advises > > > Why I want to activate a window? > Because I want to simulate some mouse clicking and keyboard typing in some > application, doing this automatically please me. > To activate a window is necessary. > > Why in script? > To double click it or run it in command line is a easy way I prefer. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathon.py at gmail.com Sat Oct 23 08:33:44 2010 From: nathon.py at gmail.com (nathon py) Date: Sat, 23 Oct 2010 14:33:44 +0800 Subject: [python-win32] BringWindowToTop doesn't work, anyone have try it? In-Reply-To: <4CC1C28E.4070104@probo.com> References: <4CC1C28E.4070104@probo.com> Message-ID: The bug has been closed, you can check here http://sourceforge.net/tracker/?func=detail&atid=551954&aid=3077881&group_id=78018 with an answer 'This is just a "feature" of Windows' by mhammond . @Tim, I try the way you mentioned, it really works. I've tried ShowWindow(),EnableWindow(),etc, before. It never woks. @Preston, I read the tutorial you gave, it's very helpful. I use the command line as following : start pythonwin /app XXX.py It works and producing a window, if i go deep into the pythonWin, it's not a problem. thanks a lot for your advises Why I want to activate a window? Because I want to simulate some mouse clicking and keyboard typing in some application, doing this automatically please me. To activate a window is necessary. Why in script? To double click it or run it in command line is a easy way I prefer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stevej at photonengr.com Wed Oct 27 18:50:35 2010 From: stevej at photonengr.com (Steve Johnston) Date: Wed, 27 Oct 2010 09:50:35 -0700 Subject: [python-win32] PythonWin COM Client Problem Accessing Methods in C++ MFC COM Server Message-ID: <6CDEC0C4827A4C21896CF86296C8ED17@photon.local> First, a little background to help explain the problem. I have a C++ MFC application configured as an Automation COM server. It has a dual interface defined in a type library embedded as a resource in the executable. The dual interface has been been implemented according to the Microsoft help article "TN065: Dual-Interface Support for OLE Automation Servers". The application also has dispinterface which implements only a small subset of the properties and methods contained in the dual interface. The BASIC scripts in Excel can successfully invoke methods in the dual interface as long as I "Dim myobject As mydualinterface" instead of "Dim myobject As Object". OK, now here is the problem. Python seems to be able to invoke the properties and methods in the dispinterface, but is completely unable to invoke anything in the dual interface. I have run MakePy and it seems to generate the proper py file. PythonWin definitely "understands" the type library and all of its methods and properties. As I type a method name in the editor, the entire list of methods in the dual interface pops up in the help list. Also, the type library defines a number of structures that I can successfully access and use as Python records. Here is an example from the PythonWin Interactive Window. PythonWin 2.6.1 (r261:67517, Dec 4 2008, 16:51:00) [MSC v.1500 32 bit (Intel)] on win32. Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for further copyright information. >>> import win32com.client >>> app = win32com.client.Dispatch("FRED.Application") #### Success! >>> app.Visible = True #### Success because "Visible" is a property in the dispinterface. >>> y = app.Acos(0.5) #### Interactive editor lists this method in the popup window as I type, but Invoke fails during execution! Traceback (most recent call last): File "", line 1, in File "C:\Python26\lib\site-packages\win32com\gen_py\D604334A-6198-4BEC-9AE9-6038B 7352C9Ax0x2x24\IDualFREDApp.py", line 33, in Acos return self._oleobj_.InvokeTypes(20, LCID, 1, (5, 0), ((5, 1),),x com_error: (-2147352573, 'Member not found.', None, None) >>> I see the same error if I attempt to Invoke any method in the dual interface. Is there anyone who can offer some insight into the problem? Any thoughts would be greatly appreciated! Regards, SCJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From skippy.hammond at gmail.com Thu Oct 28 05:16:01 2010 From: skippy.hammond at gmail.com (Mark Hammond) Date: Thu, 28 Oct 2010 14:16:01 +1100 Subject: [python-win32] PythonWin COM Client Problem Accessing Methods in C++ MFC COM Server In-Reply-To: <6CDEC0C4827A4C21896CF86296C8ED17@photon.local> References: <6CDEC0C4827A4C21896CF86296C8ED17@photon.local> Message-ID: <4CC8EAF1.9090808@gmail.com> On 28/10/2010 3:50 AM, Steve Johnston wrote: > First, a little background to help explain the problem. I have a C++ MFC > application configured as an Automation COM server. It has a dual > interface defined in a type library embedded as a resource in the > executable. The dual interface has been been implemented according to > the Microsoft help article "TN065: Dual-Interface Support for OLE > Automation Servers". The application also has dispinterface which > implements only a small subset of the properties and methods contained > in the dual interface. I don't quite understand the above - a "dual interface" is one that exposes both vtable and IDispatch implementations of an object - so I'm not sure what the additional 'dispinterface' is all about - that "dual interface" should have everything needed. > "C:\Python26\lib\site-packages\win32com\gen_py\D604334A-6198-4BEC-9AE9-6038B7352C9Ax0x2x24\IDualFREDApp.py", > line 33, in Acos > return self._oleobj_.InvokeTypes(20, LCID, 1, (5, 0), ((5, 1),),x > com_error: (-2147352573, 'Member not found.', None, None) > >>> So it looks like win32com is seeing the dual interface OK (and only supports using the IDispatch implementation of it.) It is attempting to make the IDispatch call with the member ID specified in the typelib, but the object is rejecting the call. It sounds like your object is responding to a QI for IDispatch and returning the secondary 'dispinterface' object - if it just returned the IDispatch implementation for the dual interface things would probably work. Mark From mhammond at skippinet.com.au Fri Oct 29 00:17:04 2010 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 29 Oct 2010 09:17:04 +1100 Subject: [python-win32] PythonWin COM Client Problem Accessing Methods in C++ MFC COM Server In-Reply-To: <740E5E6CAA984D62B9F5E75D04974FC2@photon.local> References: <6CDEC0C4827A4C21896CF86296C8ED17@photon.local> <4CC8EAF1.9090808@gmail.com> <740E5E6CAA984D62B9F5E75D04974FC2@photon.local> Message-ID: <4CC9F660.9080202@skippinet.com.au> On 29/10/2010 7:28 AM, Steve Johnston wrote: > Hello Mark, > > Thank you for responding to my query! I hope you don't mind that I am > replying directly to your email. I'm not sure what the proper protocol is. It is best if replies stay on list for the benefit of others. > Your response makes sense, but I'm not sure why my application is not > returning the "...IDispatch implementation for the dual interface...". > Unfortunately, I'm not a COM expert. I looked in the source code, and there > is a function, > > BOOL CFREDApp::GetDispatchIID( IID* pIID ) > { > *pIID = IID_IDualFREDApp; > return TRUE; > } > > which returns the IID of the dual interface. But I don't know if invoking a > method from the Python client ultimately calls this function to get the IID, > and ultimately, the dual interface. The name looks misleading, but it will be returning the IID of the vtable interface - IID_IDispatch is a fixed value. > > Here is another short experiment from the Python Interactive window: > > > PythonWin 2.6.1 (r261:67517, Dec 4 2008, 16:51:00) [MSC v.1500 32 bit > (Intel)] on win32. > Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for > further copyright information. >>>> import win32com.client >>>> app = win32com.client.Dispatch("FRED.Application") >>>> app > >>>> appdual = > app._oleobj_.QueryInterface("{7267D11E-5C4A-4C83-8766-19EBF0F87E85}") > Traceback (most recent call last): > File "", line 1, in > TypeError: There is no interface object registered that supports this IID That is expected - IID_IDualFREDApp is a custom IID which win32com knows nothing about. win32com will so a QI for IID_IDispatch. > The IID in the QueryInterface call is the IID of the dual interface. I also > looked in my registry and there are several entries with that IID that look > reasonable. I can only assume that the interface is properly registered > since Visual Basic can successfully invoke methods from it. VB is capable of dynamically using vtable interfaces which have a typelibrary (which yours does). You need to track the code for when IID_IDispatch is queried for. Note I'm taking off on 2 weeks holiday tomorrow and may not be able to reply while away... Cheers, Mark From whatyoulookin at yahoo.com Fri Oct 29 07:15:40 2010 From: whatyoulookin at yahoo.com (Alec Bennett) Date: Thu, 28 Oct 2010 22:15:40 -0700 (PDT) Subject: [python-win32] How to block ctrl-alt-delete on Windows 7? Message-ID: <471276.27941.qm@web112609.mail.gq1.yahoo.com> I'm working on a kiosk application, and am trying to prevent people from breaking out of our interface with Windows shortcut keys. Using pyHook I've managed to block the Windows keys, control keys and alt keys, but ctrl-alt-delete still works. This thread suggests that the combination is allowed to pass because of a guideline in the Windows SDK, and that it may be possible to modify the pyHook C extension: http://sourceforge.net/apps/mediawiki/pyhook/index.php?title=PyHook_Tutorial Any tips on doing that? Or some other way to block these keys? From python at bdurham.com Fri Oct 29 09:02:36 2010 From: python at bdurham.com (python at bdurham.com) Date: Fri, 29 Oct 2010 03:02:36 -0400 Subject: [python-win32] Using Win32 API to get around Tkinter limitations? Message-ID: <1288335756.16999.1402546803@webmail.messagingengine.com> Wondering if there are ways to use the Win32 API to get around the following Tkinter limitations? 1. Inability to set custom mouse cursors via *.cur/*.ani files. 2. Determine the height or width of window properties such as titlebar, left/right and bottom window frame edges? Thank you, Malcolm -------------- next part -------------- An HTML attachment was scrubbed... URL: From mvilas at gmail.com Fri Oct 29 10:52:12 2010 From: mvilas at gmail.com (Mario Vilas) Date: Fri, 29 Oct 2010 10:52:12 +0200 Subject: [python-win32] How to block ctrl-alt-delete on Windows 7? In-Reply-To: <471276.27941.qm@web112609.mail.gq1.yahoo.com> References: <471276.27941.qm@web112609.mail.gq1.yahoo.com> Message-ID: In legacy versions of Windows (95, 98, ME) life was easier... http://support.microsoft.com/kb/161133 In XP you can use GINA to do it (don't know about 2K): http://msdn.microsoft.com/en-us/library/aa375457(v=VS.85).aspx I couldn't find a solution for Vista and 7 though... maybe you could hook the winlogon process, which is the one that receives the notification, but that's risky at best. On Fri, Oct 29, 2010 at 7:15 AM, Alec Bennett wrote: > I'm working on a kiosk application, and am trying to prevent people from > breaking out of our interface with Windows shortcut keys. > > Using pyHook I've managed to block the Windows keys, control keys and alt > keys, but ctrl-alt-delete still works. > > This thread suggests that the combination is allowed to pass because of a > guideline in the Windows SDK, and that it may be possible to modify the > pyHook C extension: > > > http://sourceforge.net/apps/mediawiki/pyhook/index.php?title=PyHook_Tutorial > > Any tips on doing that? > > Or some other way to block these keys? > > > > _______________________________________________ > python-win32 mailing list > python-win32 at python.org > http://mail.python.org/mailman/listinfo/python-win32 > -- HONEY: I want to? put some powder on my nose. GEORGE: Martha, won?t you show her where we keep the euphemism? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at timgolden.me.uk Fri Oct 29 10:54:53 2010 From: mail at timgolden.me.uk (Tim Golden) Date: Fri, 29 Oct 2010 09:54:53 +0100 Subject: [python-win32] How to block ctrl-alt-delete on Windows 7? In-Reply-To: <471276.27941.qm@web112609.mail.gq1.yahoo.com> References: <471276.27941.qm@web112609.mail.gq1.yahoo.com> Message-ID: <4CCA8BDD.1040709@timgolden.me.uk> On 29/10/2010 06:15, Alec Bennett wrote: > I'm working on a kiosk application, and am trying to prevent people from breaking out of our interface with Windows shortcut keys. > > Using pyHook I've managed to block the Windows keys, control keys and alt keys, but ctrl-alt-delete still works. > > This thread suggests that the combination is allowed to pass because of a guideline in the Windows SDK, and that it may be possible to modify the pyHook C extension: > > http://sourceforge.net/apps/mediawiki/pyhook/index.php?title=PyHook_Tutorial > > Any tips on doing that? I *think* you may be able to do something with session events: http://timgolden.me.uk/python/win32_how_do_i/track-session-events.html (Probably worth a look, anyhow) TJG From stef.mientki at gmail.com Fri Oct 29 10:59:44 2010 From: stef.mientki at gmail.com (Stef Mientki) Date: Fri, 29 Oct 2010 10:59:44 +0200 Subject: [python-win32] How to block ctrl-alt-delete on Windows 7? In-Reply-To: <4CCA8BDD.1040709@timgolden.me.uk> References: <471276.27941.qm@web112609.mail.gq1.yahoo.com> <4CCA8BDD.1040709@timgolden.me.uk> Message-ID: In delphi I use http://www.kassl.de/winlock/index.shtml You might be able to use the executable that's included. cheers, Stef -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.brunel at pragmadev.com Fri Oct 29 11:49:19 2010 From: eric.brunel at pragmadev.com (Eric Brunel) Date: Fri, 29 Oct 2010 11:49:19 +0200 Subject: [python-win32] Using Win32 API to get around Tkinter limitations? In-Reply-To: <1288335756.16999.1402546803@webmail.messagingengine.com> References: <1288335756.16999.1402546803@webmail.messagingengine.com> Message-ID: <37EF40FF-7A4F-4C3E-B995-B4FB32FB1262@pragmadev.com> On 29 oct. 10, at 09:02, python at bdurham.com wrote: > Wondering if there are ways to use the Win32 API to get around the > following Tkinter limitations? > > 1. Inability to set custom mouse cursors via *.cur/*.ani files. This is supposed to work with Tkinter, as specified in the tcl/tk manual page here: http://www.tcl.tk/man/tcl8.5/TkLib/GetCursor.htm#M9 Doing a widget.configure(cursor='@\path\to\cursor_file.cur') or widget.configure(cursor='@\path\to\cursor_file.ani') is supposed to work. Did you try it? HTH - Eric - -------------- next part -------------- An HTML attachment was scrubbed... URL: From python at bdurham.com Fri Oct 29 17:22:59 2010 From: python at bdurham.com (python at bdurham.com) Date: Fri, 29 Oct 2010 11:22:59 -0400 Subject: [python-win32] Using Win32 API to get around Tkinter limitations? In-Reply-To: <37EF40FF-7A4F-4C3E-B995-B4FB32FB1262@pragmadev.com> References: <1288335756.16999.1402546803@webmail.messagingengine.com> <37EF40FF-7A4F-4C3E-B995-B4FB32FB1262@pragmadev.com> Message-ID: <1288365779.6214.1402609877@webmail.messagingengine.com> Eric, The short answer (for people searching the archives) is that the cursor='@\path\to\cursor_file.cur' technique DOES work exactly as advertised ... when used in a script run outside of IDLE (I know, I know ... never test Tkinter code in IDLE!). > Did you try it? Yes. Running Python 2.7 (32-bit) on Windows 7 (64-bit), from within IDLE, I received the following traceback: Traceback (most recent call last): File "", line 1, in widget.config( cursor='@help.cur' ) File "C:\Python27\lib\lib-tk\Tkinter.py", line 1202, in configure return self._configure('configure', cnf, kw) File "C:\Python27\lib\lib-tk\Tkinter.py", line 1193, in _configure self.tk.call(_flatten((self._w, cmd)) + self._options(cnf)) TclError: bad cursor spec "@help.cur" Thanks for your feedback! Malcolm -------------- next part -------------- An HTML attachment was scrubbed... URL: From python at bdurham.com Fri Oct 29 17:41:39 2010 From: python at bdurham.com (python at bdurham.com) Date: Fri, 29 Oct 2010 11:41:39 -0400 Subject: [python-win32] [Tkinter-discuss] Using Win32 API to get around Tkinter limitations? In-Reply-To: References: <1288335756.16999.1402546803@webmail.messagingengine.com> Message-ID: <1288366899.10712.1402614193@webmail.messagingengine.com> Hi Igor, > Why not use conventional tcl/tk functionality? It seems tcl/tk allows to use cur/ani files for custom cursor: > [1]http://wiki.tcl.tk/8674 Thanks for your response. You are correct, under Windows the cursor='@path/to/file.ext' technique works as expected. I had tried that, but from within IDLE (Python 2.7) this syntax raises an exception. Using this technique in scripts running from the command line (outside of IDLE) works well. Malcolm References 1. http://wiki.tcl.tk/8674 -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Fri Oct 29 23:58:30 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sat, 30 Oct 2010 10:58:30 +1300 Subject: [python-win32] How to block ctrl-alt-delete on Windows 7? In-Reply-To: References: <471276.27941.qm@web112609.mail.gq1.yahoo.com> Message-ID: <4CCB4386.7090204@canterbury.ac.nz> Does the kiosk application need all 3 of those keys? If not, you could remove one of them from the keyboard and glue something over the hole. -- Greg From igor.e.novikov at gmail.com Fri Oct 29 14:38:35 2010 From: igor.e.novikov at gmail.com (Igor Novikov) Date: Fri, 29 Oct 2010 15:38:35 +0300 Subject: [python-win32] [Tkinter-discuss] Using Win32 API to get around Tkinter limitations? In-Reply-To: <1288335756.16999.1402546803@webmail.messagingengine.com> References: <1288335756.16999.1402546803@webmail.messagingengine.com> Message-ID: On Fri, Oct 29, 2010 at 10:02 AM, wrote: > Wondering if there are ways to use the Win32 API to get around the > following Tkinter limitations? > If you are familiar with winapi you can try using pywin32 extension: http://sourceforge.net/projects/pywin32/ > > 1. Inability to set custom mouse cursors via *.cur/*.ani files. > Why not use conventional tcl/tk functionality? It seems tcl/tk allows to use cur/ani files for custom cursor: http://wiki.tcl.tk/8674 In *nix environment you can use the same images converted into xcursor resources: http://sk1project.org/viewpage.php?page_id=20 -- Regards, Igor Novikov sK1 Project http://sk1project.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.e.novikov at gmail.com Fri Oct 29 20:09:49 2010 From: igor.e.novikov at gmail.com (Igor Novikov) Date: Fri, 29 Oct 2010 21:09:49 +0300 Subject: [python-win32] [Tkinter-discuss] Using Win32 API to get around Tkinter limitations? In-Reply-To: <1288366899.10712.1402614193@webmail.messagingengine.com> References: <1288335756.16999.1402546803@webmail.messagingengine.com> <1288366899.10712.1402614193@webmail.messagingengine.com> Message-ID: On Fri, Oct 29, 2010 at 6:41 PM, wrote: > Hi Igor, > > > Why not use conventional tcl/tk functionality? It seems tcl/tk allows to > use cur/ani files for custom cursor: > > http://wiki.tcl.tk/8674 > > Thanks for your response. You are correct, under Windows the > cursor='@path/to/file.ext' technique works as expected. I had tried that, > but from within IDLE (Python 2.7) this syntax raises an exception. Using > this technique in scripts running from the command line (outside of IDLE) > works well. > > Malcolm > > You can try using direct tk command call: any_widget.tk.call('your','tk','command') Please note the command should be splitted on words. -- Regards, Igor Novikov sK1 Project http://sk1project.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewei at Fekete.com Fri Oct 29 23:02:12 2010 From: ewei at Fekete.com (Eileen Wei) Date: Fri, 29 Oct 2010 15:02:12 -0600 Subject: [python-win32] A question about COM in general Message-ID: <5E94BFD292E6664094E77128C4C459B5044925567D@eros2.Fekete.com> Hi Tim and Roberto, Thanks a lot for your reply. I somehow messed up with my account and didn't receive any email so I didn't see your replies until I checked the archive today, so sorry for the late reply. I wonder if ctype can be used on C++ code as well? By searching on line the answer I found seems to be that it can't, but I don't know if those are the "right" answers. If ctype can be used on C++ then it seems like the most straightforward way to go, is that correct? The applications I would like to test by exposing their APIs are not designed to be controlled programmatically, and even though some of them have very limited COM interface, most don't. And I think I probably need to expose a function from here and a function from there depending on what I need to drive my test. And I would like that there is a clear cut between the test code (the code added into the source code in order to expose the function to Python) and the product code, in another word, I would like my test code to be as least intrusive to the product code as possible. So if ctype cannot be used on C++, then between COM, SWIG and PyCXX, which would be a better choice? Also Tim you mentioned learning curve of SWIG, I wonder how is that compared to COM? Thanks, Eileen -------------- next part -------------- An HTML attachment was scrubbed... URL: From freesisyphuswang at gmail.com Sun Oct 31 21:15:36 2010 From: freesisyphuswang at gmail.com (^_^Sisyphus^_^) Date: Sun, 31 Oct 2010 21:15:36 +0100 Subject: [python-win32] WMI qualifier Message-ID: Hi everyone, I start to use WMI python binding recently. I want to know whether there is any way to retrieve the qualifier information of a WMI object? For example, in Win32_Process the OtherTransferCountData has a unit in bytes but PageFileUsageData has a unit in kilobytes: OtherTransferCountData type: uint64 Access type: Read-only Qualifiers: Units (Bytes) PageFileUsageData type: uint32 Access type: Read-only Qualifiers: Units (Kilobytes) How could I retrieve those string value from their qualifiers, such as: 'Bytes', 'Kilobytes'? Thanks, Ling -------------- next part -------------- An HTML attachment was scrubbed... URL: