Python COM Extensions Readme
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.
Recent Changes
- makepy generation 'for demand' has been fixed, particularly when using
events
- Unexpected exceptions in Python COM objects will generally now dump
the exception and traceback to stdout. This is useful for debugging
and testing - it means that in some cases there will be no need to register
an object with --debug to see these
tracebacks. Note that COM objects used by server processes (such as
ASP) generally have no valid stdout, so will still need to use --debug as usual.
- universal gateway support has been improved - we can now work as an
Outlook Addin
- Potential Breakage: makepy supported objects should now support
named parameters correctly. However, previously if there was a ByRef
param not marked as optional, it could still often be omitted. This
param may now need to be supplied (depending on the implementation -
it is true for VB implemented objects)
win32all-147/8
- ActiveScripting bugs with ASP should have been fixed, including the
dreaded KeyboardInterrupt problem. ASP should also be much faster
second and subsequent loads of a page.
- ActiveScripting now correctly registers all type libraries. This means
that all ActiveScripting global variables should be using makepy supported
early-bound objects.
- Dynamic dispatch objects now have a method _FlagAsMethod, which
allows you to 'declare' that certain attribute names are actually methods
rather than properties. This is used for some objects that don't otherwise
allow you to call these methods due to problems in their implementation.
OpenOffice is one such program. For example, you may call ob._FlagAsMethod("AMethod"),
after which calling ob.AMethod() will work correctly.
win32all-143
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
win32all-142
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)
win32all-136/ActivePython 2.1
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)
win32all-133 changes
Bug fixes! We now have an option to honour the hidden attribute
on objects. This currently defaults to off, so nothing should break.
win32all-130-132 changes
Bug fixes. Structures can be created quite simply, using win32com.client.Record()
- see its docstring for details.
See also the older changes.
ActiveX Scripting
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.
Known bugs and problems...
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.
win32all-129 changes
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)
win32all-128 changes
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.
win32all-127 fixes (includes win32all-126).
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.
win32all-125 fixes.
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.
Build 123 and earlier changes.
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 :-)
Even older Changes
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.
|
