Python
and ActiveX Scripting Python
and ActiveX Scripting Important: The installers install (not register) the new implementation. See Installing the AXScript Implementation for details on setting up the new implementation.
This documentation covers the following topics:
ActiveX Scripting is a technology which allows for "plug-in" languages to be used by a host application. Currently, the only hosts which support this technology are provided by Microsoft - the best known ones being Internet Explorer (V3 or better), and Active Server Pages (aka Denali).
To test or play with ActiveX Scripting, you will need one of these hosts.
Note
Please see the README.HTM in the win32com directory. It contains a link to the "AXScript Demos" page. This page allows you to automatically install the engine
But here are the "manual installation" instructions.
Installing either win32com or Pythonwin will install the new implementation. All you need to is register it. Perform these steps:
Then test it:
The language name is "Python".
The object model provided to Python is very similar to that provided by VBScript or JScript. All global functions (such as "alert()" in IE) are available, and all objects are available by name (eg "MyForm" is used to reference the form defined with that name in the HTML.
Python and IE work very well together. However, a key difference to the JScript/VBScript implementations is in "local variables". All objects are able to be fully referenced, but not all objects are available as "local variables". For example, in an event handler for a form, you would expect the forms objects (eg, buttons, text boxes, etc.) to be visible locally - ie, you would expect "Text1.Value = 'New Value'" to work - it doesn't! However, the explicit "FormName.Text1.Value" does.
To use Python in Active Server Pages (Denali) you must ensure the .ASP files are installed in a location known to the Internet Server.
There is a significant limitation when using scripts enclosed with <% tags. The current version of Denali strips all white-space from this code, making it impossible to write "if" (or any other block) statements in this context. Code that uses the <SCRIPT Language="Python" RunAt="Server"> tag works as expected.
It should be noted that a design decision in Denali makes it hard to mix and match the 2 styles. All code in <% tags is executed before <SCRIPT tags, regardless of their position in the source file.
Debugging this code can make life interesting! Future releases will support the Active Script Debugging interface, but for now we must use other means. (Note that this release nearly supports AXDebugging - in fact, it looks exactly like it does - don't be fooled!)
Neither Internet Explorer or Denali have a good place for Python "print" statements to go! To make matters worse, Denali is usually run in an environment where creating a window for such output is not possible.
To solve this problem, a module called win32trace has been written. This module allows one Python process to generate output via a "print" statement, and another unrelated Python process to display the data. This works even if the Python process generating the output is running under the context of a service, as Denali does.
To enable this debugging, simply "import win32traceutil" at the start of your script (ie, in the .HTM or .ASP file) - thats it! To actually see the output as it is produced, start a DOS prompt, and run the file "win32traceutil.py" (eg, "python.exe win32traceutil.py") This will print all output from all other Python processes (that have imported win32traceutil) until you kill it with Ctrl+Break!)
For further details, please see the win32trace documentation for more details.