Significant changes for the win32com extension module: The installation program will NOT create any new items on the start menu. All it does is make win32com available to an existing Python installation. If you have installed win32com previously from an installation such as this, you should uninstall it before proceeding - and manually remove the .pyc files - sorry - working on that! If you have win32com installed through installing Pythonwin, you should find the win32com directory, and remove it. August 97 --------- Unicode objects are implemented almost everywhere. Unfortunately, there are some places where they are not automatically converted to strings where they maybe should be. $VssLog(project)$ July 97 ------- * Integrated win32com with pywintypes, allowing Unicode, IID's etc to be used in any Windows extension. * Support for EXE Servers is now semi-supported. Pythoncom.exe is the host EXE, but note that "register.py" etc do not yet support this model - you need to hit the registry yourself. This should be considered very beta. * Added a technique for allowing "COM Extensions" to be installed seperately, in seperate directories, but still allow them to appear as part of the "built-in" COM functionality. Currently MAPI uses this technique, and AXScript and AXDebug will soon be moved to it. May 15, 1997 ------------ * Fair bit of work on makepy and dynamic. Note that: win32com.client.Dispatch() is now the "official" way to create a Dispatch object. If you have previously imported a makepy generated support file, win32com.client.Dispatch() will correctly return a class from the makepy file. If no support is available, it will return a win32com.client.dynamic.Dispatch() object. As previously, win32com.client.dynamic.Dispatch() will always return a dynamic object, whether makepy support is loaded or not. * Far less divergence between "makepy" and "dynamic" objects. In the past, it was often necessary to use a different coding style depending on whether you had makepy support or not (eg, Excel 7 needed quite different code). In general, this has been fixed (eg, all MSOffice test run both as dynamic and makepy - the only difference is speed. Note that Office97 can be _very_ slow at startup without makep support loaded. * Full support for Office 97. Note that Word97 has changed its object model, and their "compatibility" layer doesnt work with Python - you will need to change any code that uses Word. See the win32com\test\testMSOffice.py for a demo of talking to word. * Support for interfaces with variable arguments supported. * Minor typos (aka bugs!) in ActiveXScripting. April 26, 1997 -------------- * Lots of work on AXScript and AXDebug. Quite a few leaks plugged. * Work on the makegw tool for generating C++ code. Currently broken in a number of serious ways! March 25, 1996 -------------- * Severe memory leak in all COM arguments spotted and fixed by Greg. * short float support added by Jim. * Far better AXScripting and a new AXDebug module by Mark. The AXDebug module does not yet allow debugging of Python code, but it _does_ allow Python to work with the debugger-enabled MSIE. * Ability for Python to "unwrap" another COM server (say what?:) * ISupportErrorInfo somewhat supported on client side - just waiting a general "OK" from Greg before converting the whole kaboodle! Feb 14, 96 ---------- More makepy and variant fixes. Few internal re-orgs. ISupportErrorInfo now supported. Jan 12, 96 ---------- - A few Makepy problems with setting properties fixed. Jan 8, 96 --------- - Fair bit of internal code reorg. Gregs "Stream" support beefed up. - Greg also created a "PyTime" object for VARIANTS. See either the win32com.hlp file, or daodump.py, for basic instructions/demo. __print__ method on this currently a bit broken. - build.py/makepy upgraded again. Enums support now true enum, meaning non-zero based collections work. Also better support for "properties" that take arguments - these are now transformed into a method. It tries to be smart, and allow the original property to be used if enough of the args have defaults, etc. Dec 15, 96 ---------- - Far far better makepy support for alias, enums and typedefs - Safearray support enhanced significantly. - C++ Test harness, which can be used to generate test cases for both makepy.py and the runtime system. Makes excellent test harness for both makepy Alias/Enum substitution, and PythonCOM runtime Python<->VARIANT translation. Dec 11, 96 ---------- - Changes to makepy to better support aliases. - Whole lotta new interfaces from Greg. Dec 1, 96 --------- - Added the start of a test suite. - pythoncom.dll now lives in the Windows system directory, although win32com.pythoncom works (and is the "official" way!). - Connection point support added. makepy will now generate code suitable to be used as an OCX, or as a connection point sink. Slightly wierd connection point demo (client and server!) is in demos\connect.py Note - All old OCX code will be broken. You must regenerate all .py files, AND CHANGE ALL SUPPORT CODE (sorry!). Specifically, the name of the class you should sub-class from will have changed - it is now prefixed by OCX. Eg, ocxtest.py used to have: MyCal(msacal70.Calendar) - it is now MyCal(msacal70.OCXCalendar) - Even more changes to makepy/dynamic.py and its infrastructure. Specifically: * Python COM clients can now call Python COM Servers (ironic problem, that!:) All clients without type information should work better. * Makepy generated classes, once imported, can share across each other. Eg, the MSACCESS type library references interfaces in the DAO library. This now works totally seamlessly. * Makepy makes some simple detection of enumerators. Notably, DAO and MSACCESS work well - eg "for table in db.TableDefs:" now works as expected. * Circular reference cleaned up. Previously, (almost) all dynamic.py created objects were immortal! This has removed most reference counting problems (apart from the standard Python ones, including the "last traceback" one, which does bite here.) --------- - changes to dynamic.py - works much better with MSWord. - more fixes to makepy.py - methods in generated scripts will return COM objects far far better (ie, now it is natural) - resurrect Curt's tlbrowse.py, and create catbrowse.py. - added more interfaces. - resurrected autoduck .hlp file generation. - added better OLE argument handling - added conversion of Python sequences to arrays (you can now return sequences from a COM server) - support for creating enumerators (an object that responds to IEnumVARIANT). win32com.server.util.ListEnumerator is an example. - internal fixes and changes - simplified IID management - expanded capabilities from policy.py - pythoncom.CoInitialize and CoUninitialize for threaded COM clients - other fun things