Re: Using Python with COM to communicate with proprietary Windows software
On Fri, 09 Sep 2005 08:36:00 +0200, Thomas Heller [EMAIL PROTECTED] wrote: Sounds like a perfect job for comtypes, which is a COM library implemented in pure Python, based on ctypes. comtypes should make it easy to access custom (non-dispatch derived) com interfaces, or the vtable based part of dual interfaces - it would be good however, if you have a type library for the interfaces. http://sourceforge.net/projects/comtypes/ No docs yet, but there are tests included which should get you started. (I have released and announced this 3 weeks ago, but haven't got a single feedback. So it seems the need to access custom interfaces is very low.) Thommas After some testing today, it does seem to do exactly what I wanted -- I can now access the custom but IDispatch-like COM interface that I couldn't access with win32com (or with Java + jawin). It might be possible in other ways, but using comtypes was definitely the most painfree way (everything, including the return values from the methods, worked as expected). Thank you very much. Of course, this does not complete my task -- although I can now use my interface to send messages and commands to the big log tool, I still need to implement a COM server and pass a pointer to its interface through one of the messages to the com server to be able to receive data: BridgeInterface.StartLogging(filename) --- works fine, didn't work before BridgeInterface.Advise(ptr) --- Now, I need to create a new interface for receiving the data sent from the log application, so that I can (at first) print it This _shouldn't_ be too difficult -- I know which methods must be implemented (basically just some kind of event handling to deal with randomly arriving log points, should be implemented as onMsg() on my COM server side, and some other similar methods), but I don't really know how. I have tried doing simple COM servers using win32com, but is it equally possible to implement such a simple thing in comtypes? I didn't find any server side examples in comtypes, but perhaps there is a way? -- Joakim Persson M.Sc student, CS/E @ LTH -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python with COM to communicate with proprietary Windows software
On Fri, 09 Sep 2005 08:36:00 +0200, Thomas Heller [EMAIL PROTECTED] wrote: Joakim Persson [EMAIL PROTECTED] writes: I have a rather bloated C++ client prototype which works, so I should have all the code needed to invoke the interface, but this client is of course rather bloated in itself and not suitable for my experimental programming approach. Am I right in believing that the COM interface I am trying to use is of what is called a custom type, that I cannot access using Python + win32com? Sounds like a perfect job for comtypes, which is a COM library implemented in pure Python, based on ctypes. comtypes should make it easy to access custom (non-dispatch derived) com interfaces, or the vtable based part of dual interfaces - it would be good however, if you have a type library for the interfaces. http://sourceforge.net/projects/comtypes/ No docs yet, but there are tests included which should get you started. (I have released and announced this 3 weeks ago, but haven't got a single feedback. So it seems the need to access custom interfaces is very low.) Thommas Looks good, I think I downloaded ctypes but didn't put in the effort to wrap the custom COM interface. I have the type library and full documentation of the interface, so IMO it _should_ be possible to make a 100% Python application for testing this particular interface, which would definitely speed up prototyping, which is the entire goal of my work. I will give it a spin tomorrow, and I'll get back on the NG once I have tested it. Many thanks! It seems most Python uses for COM rely on simple automation of COM interfaces of the IDispatch type, but I need something more (full client-server communication and threading, for instance). Hopefully your module will at least let me get one step further... My remaining two options, seeing as I would really like to at least put the data processing and presentation part in Python, are linking Python with C++ for the COM part and building (Data + Presentation) in Python, or making a complete standalone C++ part for the COM part and then _another_ client-server solution using e.g. named pipes/sockets. -- Joakim Persson M.Sc student, CS/E @ LTH -- http://mail.python.org/mailman/listinfo/python-list
Using Python with COM to communicate with proprietary Windows software
Hello all. I am involved in a project where we have a desire to improve our software testing tools, and I'm in charge of looking for solutions regarding the logging of our software (originating from embedded devices). Currently, we are using a heavyweight, proprietary log tool developed by another part of the company. This tool contains all standard logging functionality, but we also need to insert debug log points in the software of the embedded device, and we cannot get new releases of this big log tool very often (typically, these debug log points might be very temporarily inserted into the software during the development phase). Therefore, we have added a requirement to the log tool where we made them implement a COM server in the log tool, so that we can access arbitrary log points in the embedded device. My thoughts then, as someone who wants to bring in more interpreted, lightweight languages (and SW development processes) into the organization, was to use Python to easily add log parsing and log presentation in different ways. This means that I must come up with a way to interface Python with this log tool. After some investigations, I have run inte problems -- my inital approach was to use Python + win32com to communicate with the COM interface. Unfortunately, it seems as if win32com, even if I makepy the log tool executable (which gives me the full range of available functions of the interface, just as expected), cannot be used, since the interface is not a simple IDispatch interface. Also, I discovered that the Python client must also implement a COM server to receive the log information as it is generated by the embedded device, passed into the log tool and then sent by the log tool COM server. I have a rather bloated C++ client prototype which works, so I should have all the code needed to invoke the interface, but this client is of course rather bloated in itself and not suitable for my experimental programming approach. Am I right in believing that the COM interface I am trying to use is of what is called a custom type, that I cannot access using Python + win32com? I can use Python + win32com just fine when accessing most normal COM servers (typical example: MS Office programs implementing IDispatch interfaces), but I cannot access the proprietary interface -- I get interface not supported-type messages (I can query the CoClass for IUnknown and IDispatch interfaces, but not using the known IID for the custom interface). So, I'm trying to sum up my options. I have looked at Boost to try to merge C++ and Python code, take care of the COM server/client creation and messaging by the C++ part, and then take care of the data processing/presentation part in Python, like so: ++ |PRES| -- Python and friends (wxPython could be interesting) ++ ++ |DATA| -- Pure python ++ ++ |COM | -- C++ ++ ... all linked together into, eventually, one Python executable (linking in the C++ through a DLL which is then imported by Python). I haven't fully explored how to do this, but it seems as if Boost is usable using MSVC++ (the organizations standard IDE) -- has anyone tried something similar? My final idea is to give up on one single program for this, and use a C++ intermediate program to communicate with the log tool and then let it forward its data through sockets or named pipes, which Python seems to deal with more easily. I have tried using Java + jawin as well just for a quick exploratory spike, and ran into the same problems (interface not supported etc). The jawin documentation talks a bit about wrapping the custom interface into java objects, but this is rather obscure and undocumented, and untangling it would take quite some time -- so I figured that somebody could have done something similar in the past. Does anyone have any hints on how to go forward? The whole point with my project is to demonstrate the usefulness of rapid prototyping using Python (this has already been successful for smaller test tools, test scripts and smaller intermediary programs), but I don't want something like COM client/server obscurity getting in the way... Thanks in advance, -- Joakim Persson M.Sc student, CS/E @ LTH -- http://mail.python.org/mailman/listinfo/python-list