Thread: [pywin32-checkins] pywin32/com/win32com readme.htm,1.13,1.14
OLD project page for the Python extensions for Windows
Brought to you by:
mhammond
Menu
▾
▴
pywin32-checkins
|
From: Mark H. <mha...@us...> - 2004-04-11 04:54:56
|
Update of /cvsroot/pywin32/pywin32/com/win32com In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25041 Modified Files: readme.htm Log Message: Bring a few of the readmes into this century. Index: readme.htm =================================================================== RCS file: /cvsroot/pywin32/pywin32/com/win32com/readme.htm,v retrieving revision 1.13 retrieving revision 1.14 diff -C2 -d -r1.13 -r1.14 *** readme.htm 5 Oct 2002 02:36:41 -0000 1.13 --- readme.htm 11 Apr 2004 04:41:21 -0000 1.14 *************** *** 20,27 **** <h3>Recent Changes</h3> ! <ul> ! <li>makepy generation 'for demand' has been fixed, particularly when using ! events</li> <li>Unexpected exceptions in Python COM objects will generally now dump the exception and traceback to stdout. This is useful for debugging --- 20,47 ---- <h3>Recent Changes</h3> ! <h4>win32com.shell</h4> ! The shell interfaces have undergone a number of enhancements and changes. ! A couple of methods have changed signature between the first build with shell support (200) and later builds. ! SHGetFileInfo was broken in its result handling, so had to be changed - this ! is the only function used by the samples that changed, but others not used by the samples also have changed. ! These shell interfaces are now generally stable. ! <h4>New win32com.taskscheduler module</h4> ! Roger Uploe has contribted an interface to the Windows task scheduler. This is actually very neat, and it allows ! Python to edit the task list as shown by Windows Control Panel. Property page suppport may even appear later, ! now that the win32 library has the new win32rcparser module. ! <h4>ActiveX Scripting </h4> ! ! <p>Python only supports "trusted" execution hosts - thus, it will no longer work ! as an engine inside IE (Python itself no longer has a restricted execution environment). ! Python continues to work fine as an Active Scripting Engine in all other ! applications, including Windows Scripting Host, and ASP. ! ! <p>There is also support for Python as an ActiveX Scripting Host.</p> ! ! <p>Active Debugging seems to be fully functional.</p> ! ! <h4>Older stuff</h4> <ul> ! </li> <li>Unexpected exceptions in Python COM objects will generally now dump the exception and traceback to stdout. This is useful for debugging *************** *** 35,274 **** Outlook Addin<br> </li> ! <li><b>Potential Breakage</b>: 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)<br> ! </li> ! </ul> ! <h4>win32all-147/8</h4> ! <ul> ! <li>ActiveScripting bugs with ASP should have been fixed, including the ! dreaded <i>KeyboardInterrupt</i> problem. ASP should also be much faster ! second and subsequent loads of a page.<br> ! </li> ! <li>ActiveScripting now correctly registers all type libraries. This means ! that all ActiveScripting global variables should be using makepy supported ! early-bound objects.</li> ! <li>Dynamic dispatch objects now have a method <i>_FlagAsMethod,</i> 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 <i>ob._FlagAsMethod("AMethod")</i>, ! after which calling <i>ob.AMethod()</i> will work correctly.</li> ! ! </ul> ! ! <h4>win32all-143</h4> ! ! <p>ActiveScripting inside IE has been disabled by default. This is ! due to a <a ! href="http://starship.python.net/crew/mhammond/win32/PrivacyProblem.html">privacy ! concern</a> discovered in the engine. If you wish to re-enable this ! feature, you must execute:<br> ! <code>z:\> win32comext\axscript\client\pyscript_rexec.py</code></p> ! ! <h4>win32all-142</h4> ! ! <p>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)</p> ! ! <h4>win32all-136/ActivePython 2.1</h4> ! ! <p>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)</p> ! ! <h4>win32all-133 changes</h4> ! ! <p>Bug fixes! We now have an option to honour the hidden attribute ! on objects. This currently defaults to off, so nothing should break.</p> ! ! <h4>win32all-130-132 changes</h4> ! ! <p>Bug fixes. Structures can be created quite simply, using <i>win32com.client.Record()</i> ! - see its docstring for details.</p> ! ! <p>See also the <a href="#OlderChanges">older changes</a>.</p> ! ! <h3>ActiveX Scripting </h3> ! ! <p>This release contains full support for Python as an ActiveX Scripting ! Engine and Host. Check out the <a ! href="../win32comext/axscript/demos/client/ie/demo.htm">ActiveX Scripting ! Demos</a> (which includes information on registering the engine)</p> ! ! <p>There is also support for Python as an ActiveX Scripting Host.</p> ! ! <p>Active Debugging seems to be fully functional.</p> ! ! <h3>Known bugs and problems...</h3> ! ! <p>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 <i>pythoncom._GetInterfaceCount()</i> ! to determine how many COM objects are held by Python as your program terminates ! - this should return zero.</p> ! ! <h3><a name="OlderChanges">Even Older Changes</a></h3> ! ! <h4>win32all-129 changes</h4> ! ! <p>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,<i>struct.int_val</i>). 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.</p> ! ! <p>We support demand-building of <i>makepy</i> files. When a <i>makepy</i> ! file is built in this way, instead of a single file being generated in the ! gencache, a Python package is created. In the package <i>__init__</i> ! file is all the information you would normally find in a <i>makepy</i> file, ! except for the classes! As an object is needed at runtime, <i>makepy</i> ! 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 <i>makepy</i>, but don't have ! to suffer the huge delay running <i>makepy</i>. Indeed, there are some ! type libraries that are too large to run <i>makepy</i> at all - this solves ! that problem.</p> ! ! <p>This new demand-building feature is not enabled by default - you must ! run<i>makepy -d</i>, or specify the new <i>bForDemand</i> parameter to the ! <i>gencache</i>functions. 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 ! <i>makepy</i>does now)</p> ! ! <p><i>makepy</i> generated code should be even faster now - many of the run-time ! type conversions that the previous version performed have been optimized ! away (<i>makepy</i> already knows the return type of many functions - there ! was no need for it to check these types at runtime)</p> ! ! <h4>win32all-128 changes</h4> ! ! <p>We now have events working pretty well.<span style=""> </span>NOTE:<span ! style=""> </span>This is still experimental – all feedback appreciated. ! <span style=""> </span>See the docstring for <i>win32com.client.DispatchWithEvents</i> ! and <i>win32com\test\testMSOfficeEvents.py</i> for more details and samples.</p> ! ! <p>Active Debugging support improved again.</p> ! ! <h4>win32all-127 fixes (includes win32all-126).</h4> ! ! <p>All Arrays of VARIANT's of type VT_UI1 are now converted to a <i>buffer</i> ! object rather than the previous list of integers. In addition, a <i>buffer</i> ! 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 <i>buffer()</i> ! built-in on the object to create a buffer object that will force the new ! behaviour.<b>Note</b>: 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.</p> ! ! <p>A bug that caused the Active Scripting implementation to die has been ! fixed. (Specifically, the implementation of to <i>IActiveScript::AddTypeLib()</i> ! was buggy)</p> ! ! <p>Active Scripting bug when using IE5 fixed (it has a method called "print" ! which messed us up)</p> ! ! <p>Error handling when setting erroneous properties on COM objects fixed. ! There were cases where errors would not be reported.</p> ! ! <p>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.</p> ! ! <p>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.</p> ! ! <p>COM now supports byref date arguments.</p> ! ! <h4>win32all-125 fixes.</h4> ! ! <p>Better support for DCOM via <code>win32com.client.DispathEx(progId, machineName=None, ! …)</code>. Small DCOM demo in <i>win32com\test\testDCOM.py</i>.</p> ! ! <p>Registration of COM servers has been made a little simpler, and the QuickStart ! has been changed to reflect this. Classes no longer need <i>_reg_class_spec_</i> ! or <i>_reg_desc_</i> attributes - the registration process now provides sensible ! defaults. Also note that if <i>_reg_class_spec_</i> 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 <i>_reg_class_spec_</i> is specified, the original behaviour remains ! - you must ensure the path is correct yourself.</p> ! ! <p>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.</p> ! ! <p>Robin Becker has dramatically increased the speed of COM accessing certain ! objects (notably MSOffice) when not using <i>makepy</i>.</p> ! ! <h4>Build 123 and earlier changes.</h4> ! ! <p>Active Debugging should now be <b><i>nearly</i></b> capable of debugging ! stand-alone Python scripts.<br> ! 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 <a href="http://msdn.microsoft.com/scripting">http://msdn.microsoft.com/scripting</a><br> ! To debug Python scripts, use the following commands:</p> ! ! <pre>from win32com.axscript import debugger<br>debugger.Break()</pre> ! ! <p>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 :-)</p> ! ! <h4>Even older Changes</h4> ! ! <p>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.)</p> ! ! <p>Couple of minor interfaces added. <i>win32com.shell.shell</i> has been ! filled out some more.</p> ! ! <p><i>pythoncom.CoUninitialize()</i> 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.</p> ! ! <p>Regressed back to the default COM threading model being "Apartment", as ! defaulting to "Free Threading" seems to break so many clients. <i>sys.coinit_flags</i> ! still allows you to dictate the behaviour before <i>pythoncom</i> is imported ! for the first time.</p> ! ! <p><i>makepy</i> 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.</p> ! ! <p>More changes to <i>makepy</i> to better support COM Constants. All external ! COM constants (eg, MSWord related constants) should now be available in<i>win32com.client.constants</i>. ! No old code should break, but in the future the "old style" of using COM ! constants will be removed. <a href="html/QuickStartClientCom.html">This is ! all documented in the Client Side Quick Start documentation</a>. Also made ! a few minor changes to the<i>bGuiProgress</i> param.</p> ! <br> ! <br> ! <br> </body> </html> --- 55,59 ---- Outlook Addin<br> </li> ! </body> </html> |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X