This is the readme for win32com. Please check out the win32com documentation index
The win32com/test directory contains some interesting scripts (and a new readme.txt). Although these are used for testing, they do show a variety of COM techniques.
ActiveScripting inside IE has been disabled by default. This is
due to a privacy
concern discovered in the engine. If you wish to re-enable this
feature, you must execute:
z:\> win32comext\axscript\client\pyscript_rexec.py
Build for Python 2.2. Note that ActiveDebugging will not work in this release - you will not be able to debug Python programs using the Microsoft Debuggers inside ActiveScripting apps (such as IE, ASP)
Universal gateway has arrived! You can now implement arbitrary vtable based interfaces, as long as they are defined in a type-library (and even if not if you bonkers :-). You simply add one extra statement to your COM server nominating the typelibrary with the interface. Your PythonCOM server then can list the interfaces in that typelibrary by name in _com_interfaces_. Note that you must still have _public_methods_, but it need not specify named vtable interface methods - ie, in most cases this list will be empty. See win32com\servers\test_pycomtest.py for an example. (Note the intent is for the list of interfaces passed to universal.RegisterInterfaces() will be optional)
Bug fixes! We now have an option to honour the hidden attribute on objects. This currently defaults to off, so nothing should break.
Bug fixes. Structures can be created quite simply, using win32com.client.Record() - see its docstring for details.
See also the older changes.
This release contains full support for Python as an ActiveX Scripting Engine and Host. Check out the ActiveX Scripting Demos (which includes information on registering the engine)
There is also support for Python as an ActiveX Scripting Host.
Active Debugging seems to be fully functional.
Certain servers may hang at shutdown if all COM client objects not released - notably, MSOffice. Eg, if a Python program that is talking to excel raises an exception and exits, the Python program will be hung. There are no known leaks in win32com, but there is also no attempt at automatic object cleanup. All standard Python caveats about references apply! Note this is a "feature" of COM, and not a bug in win32com. You can use the function pythoncom._GetInterfaceCount() to determine how many COM objects are held by Python as your program terminates - this should return zero.
We now have complete support for COM structures. To take advantage of this, you need a late version of COM (Windows 2000, 98, Windows 95 with DCOM95 1.2, or Window NT 4.0 with Service Pack 4). You can receive structures from any COM object, and reference the structure's elements by name (eg,struct.int_val). Once you have a structure, you can pass it to any other function, but currently there is no simple way to create Record objects in Python. Records work with or without makepy support for an object.
We support demand-building of makepy files. When a makepy file is built in this way, instead of a single file being generated in the gencache, a Python package is created. In the package __init__ file is all the information you would normally find in a makepy file, except for the classes! As an object is needed at runtime, makepy is run again to generate only the specific class requested, into a separate file in the package. This has significant advantages when loading huge type libraries - you get all the benefits of makepy, but don't have to suffer the huge delay running makepy. Indeed, there are some type libraries that are too large to run makepy at all - this solves that problem.
This new demand-building feature is not enabled by default - you must runmakepy -d, or specify the new bForDemand parameter to the gencachefunctions. It is expected that in the future the existing code will be dropped in favour of this package mechanism (although we will always retain the option to generate the entire package at the start, as makepydoes now)
makepy generated code should be even faster now - many of the run-time type conversions that the previous version performed have been optimized away (makepy already knows the return type of many functions - there was no need for it to check these types at runtime)
We now have events working pretty well. NOTE: This is still experimental – all feedback appreciated. See the docstring for win32com.client.DispatchWithEvents and win32com\test\testMSOfficeEvents.py for more details and samples.
Active Debugging support improved again.
All Arrays of VARIANT's of type VT_UI1 are now converted to a buffer object rather than the previous list of integers. In addition, a buffer object can be passed to COM and an array of type VT_UI1 will be created. This type is often used when passing raw binary data, and this change is far more efficient for large data sets. For example, if you have a string or array.array object holding binary data, you can use the buffer() built-in on the object to create a buffer object that will force the new behaviour.Note: This may break some code that uses arrays of this type, but after much soul-searching it was decided this new behaviour is worth the pain.
A bug that caused the Active Scripting implementation to die has been fixed. (Specifically, the implementation of to IActiveScript::AddTypeLib() was buggy)
Active Scripting bug when using IE5 fixed (it has a method called "print" which messed us up)
Error handling when setting erroneous properties on COM objects fixed. There were cases where errors would not be reported.
Threading bug that was exposed when using MTS has been fixed. Minor (but regular) memory leak plugged. Can now run for (nearly :-) ever under MTS with huge thread numbers.
makepy has better support for objects that expose multiple IDispatch interfaces, Also sorts the list of type-libraries correctly, and hides libraries marked as hidden.
COM now supports byref date arguments.
Better support for DCOM via win32com.client.DispathEx(progId, machineName=None,
…). Small DCOM demo in win32com\test\testDCOM.py.
Registration of COM servers has been made a little simpler, and the QuickStart has been changed to reflect this. Classes no longer need _reg_class_spec_ or _reg_desc_ attributes - the registration process now provides sensible defaults. Also note that if _reg_class_spec_ is not specified, the PythonPath will also be modified when your server is loaded - this prevents the common problem of not having your COM server on the PythonPath. Note that if _reg_class_spec_ is specified, the original behaviour remains - you must ensure the path is correct yourself.
Type information has been upgraded. The Pythoncom core is now capable of creating COM Type Libraries. All left remaining is some Python programming, so expect this soon.
Robin Becker has dramatically increased the speed of COM accessing certain objects (notably MSOffice) when not using makepy.
Active Debugging should now be nearly capable of debugging
stand-alone Python scripts.
Note that to use this feature you will need an Active Scripting debugger
installed. Visual Interdev version 6 is one such debugger, or a free debugger
can be found at http://msdn.microsoft.com/scripting
To debug Python scripts, use the following commands:
from win32com.axscript import debugger
debugger.Break()
This currently has some problems – most notable is that modules imported after debugging has commenced does not work. It also occasionally crashes :-( So maybe using it isn't such a good idea after all :-)
Active Debugging support has been improved greatly, and some bugs in Active Scripting have been resolved. Python scripts are fully debugging from MSIE, WSH, etc (havent tested ASP :-( Please let me know of any problems.)
Couple of minor interfaces added. win32com.shell.shell has been filled out some more.
pythoncom.CoUninitialize() is no longer called automatically at shutdown. This seems to fix more problems than it causes, but if your COM program is hanging at shutdown, try adding an explicit call to this method just before you exit.
Regressed back to the default COM threading model being "Apartment", as defaulting to "Free Threading" seems to break so many clients. sys.coinit_flags still allows you to dictate the behaviour before pythoncom is imported for the first time.
makepy generated files now have much better support for default values for arguments. Also attempted to remove some hacks related to "interface" descriptions in IDL file. Nothing should break, and my (now comprehensive) test suite runs to completion, but let me know of any problems with weird, custom IDL files.
More changes to makepy to better support COM Constants. All external COM constants (eg, MSWord related constants) should now be available inwin32com.client.constants. No old code should break, but in the future the "old style" of using COM constants will be removed. This is all documented in the Client Side Quick Start documentation. Also made a few minor changes to thebGuiProgress param.