Mailing List Archive

Python ActiveX Scripting interface
I've just tried to set up Python on my Windows NT box (NT4 SP4). I
installed Python (1.5.2) and Mark Hammond's Python Win32 extensions
(build 125) with no problems. I ran the ActiveX scripting registration
script, to install the scripting interfaces, but I still have no joy
in trying to use Python as an ActiveX scripting language.

In WSH 2.0, if I specify LANGUAGE="Python", I get a message about that
not being a known language. The Internet Explorer examples fail to
work (with script errors) - I'm using IE5.

I know this is so vague a report as to be pretty much useless - I
can't clarify much at the moment as I'm away from the machine in
question. But I was wondering two things:

1. Is there any reason why the Python script interface would fail to
work with WSH 2.0 or IE5? It seems unlikely, but I suppose it's
possible...

2. Can anybody tell me exactly what I should look for in the registry,
to be sure that Python is registered properly as a scripting host? (I
don't relish trying to understand the Python script that does the
registration...!)

Thanks for any help. When I'm next at the machine in question, I'll
try to isolate the problem a bit better.

Paul Moore.
Python ActiveX Scripting interface [ In reply to ]
Check out an earlier thread called "pyscript help" on 6/4/99
I believe that pyscript.py registers python as a scripting engine.
I had two problems one was a microsoft dll version problem with comcat.dll
comcat.dll is used to register com interfaces and I think it gets screwed up
in SP4.
The other was a change to the calculator demo.
--
--Darrell
Python ActiveX Scripting interface [ In reply to ]
On Wed, 9 Jun 1999 12:07:47 -0400, "Darrell" <news@dorb.com> wrote:

>Check out an earlier thread called "pyscript help" on 6/4/99
>I believe that pyscript.py registers python as a scripting engine.
>I had two problems one was a microsoft dll version problem with comcat.dll
>comcat.dll is used to register com interfaces and I think it gets screwed up
>in SP4.
>The other was a change to the calculator demo.

Hmm, thanks for the pointer. However, I seem to have a matched set of
comcat.dll and ole32.dll (the older versions) so that's not my problem
:-(

For a bit more detail, when I run the following script file (test.ws)
in WSH 2.0 beta, I get the error

D:\winnt\Profiles\Administrator\Desktop\test.ws(0, 1) Windows
Scripting Host: Cannot create script engine : Python

[Script]

<job ID="Test">
<script language="Python">
WScript.Echo("Hello, world!")
</script>
</job>

If I run the supplied "foo2.htm" demo, I just get "Done - errors on
page" displayed, with no indication of *what* error. None of the
python scripted buttons work, but the VBScript one does. The initial
bit of script does execute, though - I can see the results of the
"document.write" calls.

All in all, the whole thing looks very odd...

Actually, I just noticed that the web page directs trace output to the
"win32trace" destination. On starting the client I find that the trace
output says

Collecting Python Trace Output...
ScriptEngine QI - unknown IID {4954E0D0-FBC7-11D1-8410-006008C3FBFC}
Traceback (innermost last):
File "E:\Applications\Python\win32com\client\dynamic.py", line 247,
in _make_method_
fn = self._builtMethods_[name] = tempNameSpace[name]
KeyError: print
Redirecting output to win32trace remote collector
Hello
Location is
file:///E:/Applications/Python/win32comext/axscript/demos/client/ie/
foo2.htm
Hello from in the form
X is 13
a is Hi there
MyForm is X is 13
a is Hi there
MyForm is

Interesting - the IID it can't find is IActiveScriptProperty. What's
that? It's not mentioned in MSDN (not even the online version on the
MSDN web site, which I assume is fairly up to date...)

Curiouser and curiouser...

Paul.
Python ActiveX Scripting interface [ In reply to ]
Paul Moore wrote in message <375ecca3.3972892@news.demon.co.uk>...

>Collecting Python Trace Output...
> ScriptEngine QI - unknown IID {4954E0D0-FBC7-11D1-8410-006008C3FBFC}
>Traceback (innermost last):
> File "E:\Applications\Python\win32com\client\dynamic.py", line 247,
>in _make_method_
> fn = self._builtMethods_[name] = tempNameSpace[name]
>KeyError: print

Hmm. This is a bug. There was a bug that IE5 has a "print" method, and
this being a reserved word upset Python. All reserved words are translated,
but it appears this one is not.

I will try and recreate this soon. But I am short of time. Would you like
to help? If so, mail me.

>Interesting - the IID it can't find is IActiveScriptProperty. What's
>that? It's not mentioned in MSDN (not even the online version on the
>MSDN web site, which I assume is fairly up to date...)

That is almost certainly not the problem. There are a number of interfaces
QI'd for that we dont implement.

Mark.