On 30/11/2022 9:09 am, Bob Kline wrote:
So at least part of that puzzle is cleared up, though it's still
somewhat unsettling that only seven calls to ScriptItem.Close() are
made, regardless of how many ScriptItem objects have been instantiated
during a session.
The close method is
On 30/11/2022 3:06 am, Bob Kline wrote:
Cranking up the microscope (or spelunking deeper, whichever metaphor
you prefer), the first thing I'll say is that this code is devilishly
complex.
Here's what I've found in the latest pass.
First, there's a minor bug at line 353 of pyscript.py [1],
One more data point. I added a bit more to my logging and learned that the
seven calls to the ScriptItem constructor each time the macro is invoked
are for the seven global objects which the host application (XMetaL) makes
available to the scripts:
* FormDriver
* ActiveDocument
* Selection
*
Cranking up the microscope (or spelunking deeper, whichever metaphor
you prefer), the first thing I'll say is that this code is devilishly
complex.
Here's what I've found in the latest pass.
First, there's a minor bug at line 353 of pyscript.py [1], where
globalNameSpaceModule is set to None
On Mon, Nov 28, 2022 at 7:24 PM Mark Hammond wrote:
> ...
> The absolute best thing for us would be to reproduce the crash in the
> test code at
> https://github.com/mhammond/pywin32/tree/main/com/win32comext/axscript/test.
I presume that would depend on getting the vendor to open the kimono
and
