win32com events bug fixed.

Alex Martelli aleaxit at yahoo.com
Thu Oct 12 06:10:38 EDT 2000


"Mark Hammond" <MarkH at ActiveState.com> wrote in message
news:lG6F5.16908$aD2.74661 at news-server.bigpond.net.au...
> "Alex Martelli" <aleaxit at yahoo.com> wrote in message
> news:8s174102cic at news1.newsguy.com...
>
> > I'm trying, but with some problems -- I don't think they're related
> > to the fix in the events-bug, but rather to 134/2.0c1 coexistence or
> > to some installation error on my part.
> >
> > Specifically, for example, the following VBScript file dic.vbs:
>
> I get a different error:
>
> L:\temp\hello.vbs(4, 1) Python COM Server Internal Error: Unexpected
> Python Error: win32com.server.p
> olicy error: This class does not provide _invokeex_ semantics
>
> Meaning I got further than you, and dictionary.py has a bug when
> working with IDispatchEx() (and I will look into that!)

OK...


> I'm not sure what causes your thread-state error tho.  Can you try
> running "win32comext\axscript\client\pyscript.py" and

Done.

> "win32com\servers\dict.py", and try your example again?

Can't do -- you mean ...\dictionary.py?  I don't have a dict.py there.


What happens is:
a. if I do have the desired line to prohibit inprocess serving,
    _reg_clsctx_ = pythoncom.CLSCTX_LOCAL_SERVER
in the classbody of DictionaryPolicy in my shareddictionary.py,
then the dic.vbs script hangs in the
    set ob = CreateObject("Python.SharedDictionary")
line -- object creation is apparently then "just not happening".

b. commenting out that line, and rerunning shareddictionary.py
    to re-register, then the above-mentioned CreateObject does
    succeed but then I get the
Fatal Python error: PyThreadState_Get: no current thread


This seems to be happening only with VBScript from within WSH
(i.e., as you mention, with IDispatchEx, I guess).  It does
work fine, for example, from within regular Visual Basic (if
one takes care to manually update the registry to delete the
inproc server entry, and exit-and-reenter Pythonwin, when
doing step B -- otherwise the inproc entry remains, or the
process is caching the inproc server, so the system-wide
unique process is not being run:-).

So, all in all, it's possible that we're only seeing anomalies
connected to IDispatchEx anyway (can't guess why different
anomalies on my PC and yours!) -- pity that scripting languages
(WSH to be precise) now seem to be using that, so those bugs
get picked up by default when trying to do a quick & dirty
test from vbscript!-)


But anyway, back to the title -- com events do work fine
again with win32all 134 + your fix + python 2.0c1, so the
world is beautiful once more...!-)


Alex


>
> Has anyone else tried with RC1?  I should put a new win32all
> together...
>
> Mark.
>
>





More information about the Python-list mailing list