We've got a project we've supported for many years which involves
using XMetaL (a commercial XML editor) customized with macros written
in JScript. The vendor claims that the scripting "can use any
scripting language that conforms to the Microsoft Scripting Language
Interface." Since JScript is much more restricted in what it can do,
and since our team is much more familiar with Python than with
JScript, we would like to switch to Python for our scripts. However, a
dirt-simple proof of concept fails with a memory access violation. We
created a macro file with a single macro which displays an alert box
with a simple string. If the lang attribute for the macro element (the
macros are stored in an XML file, with the code for each macro stored
in a MACRO element) is set to "JScript" the macro can be run an
unlimited number of times without any problems. If the lang attribute
is set to "Python" (the macro is so simple that the syntax is
identical for the two languages) the macro can be run once without any
apparent problems, as long as you close the XMetaL application and
launch it again before the next run of the macro. However, if XMetaL
is launched and the macro is run twice or more before shutting down
the application, it is no longer possible to launch it again until the
user logs off the machine and logs back in. When the user logs off, a
dialog box appears reporting a memory access violation ("xmetal.exe -
Application Error. The instruction at <memory address> referenced
memory at <memory address>. The memory could not be read."). To be
clear — the macro does what it's supposed to (display a dialog box
with a string) each time it is run. The problem only manifests itself
when trying to launch the application again or when logging off the
machine. Interestingly, when the application is in this "I can't be
launched again and I will report a failure at logoff time" state there
is no evidence that the process is still hanging around. It doesn't
show up in Process Manager, for example. But it seems clear from the
title bar of the error dialog that it's coming from the application.At this point I don't know for sure whether the problem is caused by something the XMetaL application is doing wrong (and presumably differently than what it does when the scripting engine is JScript) or by something that pyscript.py is doing. I am aware that I could easily get caught between two projects, each of which claims that the failure must be caused by the other. I have reported the problem to the XMetaL support team and I am waiting to hear what they have to say. I'm hoping that the data point of "one macro invocation succeeds, two macro invocations fail" provides a useful clue. What would be helpful from the pywin32 team's side would be any suggestions you might have for how I might go about tracking what's going on, presumably by hacking pyscript.py and/or framework.py in win32comext/axscript/client to add logging to the file system. Perhaps, for example, I'll be able to find something which is supposed to get released at application shutdown time but which isn't. I'm still trying to absorb the axscript/client code and wrap my head around what the processing flow is and what the different classes are doing. Any clues for where to start? Anyone else run into similar memory access violations using Python as a Windows Scripting Host? Many thanks! -- Bob Kline https://www.rksystems.com mailto:bkl...@rksystems.com _______________________________________________ python-win32 mailing list python-win32@python.org https://mail.python.org/mailman/listinfo/python-win32
