HELP! win32com, COM, Invoke problem

[TB]

I figured it out! Not really, I did it by cheating.

I found that GetTypeInfo on Session is not implemented, ( and things
went by going through the dynamic.Dispatch route), so I hard coded the
CLSID of Session in one .py generated by makepy. something like,
resultCLSID = pythoncom.MakeIID('{E8000132-8693-11D0-B8B1-
080009B6AB17}')
if ret is not None: ret = win32com.client.Dispatch
(ret, 'CreateSession', resultCLSID, UnicodeToString=0)

that caused Python to load the another .py (for the OCX) to be loaded
and used, and things works correctly now.

Still confused though, how could JScript got it right?

Another question, I found the python version of the script is quite a
bit slower than the JScript counterpart, so I ran the profiler, and
some output is like:
Tue Jan 02 23:19:23 2001    test1.prof

         747 function calls (745 primitive calls) in 16.042 CPU seconds

   Ordered by: internal time
   List reduced from 372 to 20 due to restriction <20>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        3    6.325    2.108   10.984    3.661 gencache.py:453
(_GetModule)
        1    2.948    2.948    8.492    8.492 E8000035-8693-11D0-B8B1-
080009B6AB17x0x1x0.py:28(CreateSession)
        1    1.386    1.386    1.386    1.386 72C8450A-A860-11D4-86DC-
0000B45B2F12x0x1x4.py:417(Start)
      3/1    0.208    0.069   16.040   16.040 <string>:1(?)
        1    0.126    0.126    2.111    2.111 E8200035-8693-11D0-B8B1-
080009B6AB17x0x1x4.py:5(?)
        1    0.121    0.121    2.544    2.544 72C8450A-A860-11D4-86DC-
0000B45B2F12x0x1x4.py:5(?)
        1    0.100    0.100    0.100    0.100 E8200035-8693-11D0-B8B1-
080009B6AB17x0x1x4.py:8528(ICSubCase)
        1    0.090    0.090    0.090    0.090 E8200035-8693-11D0-B8B1-
080009B6AB17x0x1x4.py:950(ICCase)
        1    0.077    0.077    0.077    0.077 E8200035-8693-11D0-B8B1-
080009B6AB17x0x1x4.py:5075(ICOEQuote)
        1    0.077    0.077    0.077    0.077 E8200035-8693-11D0-B8B1-
080009B6AB17x0x1x4.py:4783(ICOELineItem)

Interestingly, the _GetModule in gencache.py is the hotspot. the module
def is like:
def _GetModule(fname):
	mod = __import__("win32com.gen_py.%s" % fname)
	return getattr( getattr(mod, "gen_py"), fname)

looks like it needs to import a py file generated by makepy, in my case
a 460K (680K compiled) file, quite a big one. Is it the 'import' slower
or the 'getattr' slower?

--TB

In article <3A5274F3.3070001 at ActiveState.com>,
  Mark Hammond <MarkH at ActiveState.com> wrote:
> TB wrote:
>
> > Mark, thanks for your quick reply.
> >
> > I did notice that if you I take out the parens, this statement will
> > work, but when it bombs at the next statement:
> >
> > bo = form.CreateBO("Clarify.CBO.Generic")
> > the error message is
> ...
>
> >     ret = self._oleobj_.Invoke
> > (retEntry.dispid,0,pythoncom.DISPATCH_PROPERTYGET,1)
> > com_error: (-2147352567, 'Exception occurred.',
> > (0, 'Form.CreateBO', 'Invalid class string\015\012', None, 0, -
> > 2146827287), None)
>
> The COM object is returing this error.  It appears that it expects
> "Clarify.CBO.Generic" to be registered as a class in your registry.
>
> > the exception is thrown at the same Invoke line in dynamic.py. This
> > time CreateBO requires one parameter, but when it's called with
Invoke
> > (...DISPATCH_PROPERTYGET,1), it didn't thrown an exception of
> > BADCONTEXT, but it threw a 'Invalid class string', is it a bug in
the
> > control I'm using?
>
> It looks like the control is purposely throwing this error.
>
> > As for Makepy, I tried before but it didn't help. Let me make it
more
> > clearly. The Clarify.CBO.App.1 sits in a DLL called BOCLIENT.DLL,
but
> > all other stuff, session, FormContext etc sits in another DLL called
> > AXCOMMON.OCX. After I ran makepy on both files, I saw 2 py files
> > created, but when I step through the program I found it only used
the
> > 1st py file, not the 2nd one, which contains FormContext and etc. I
> > don't know COM so I can't explain why. Could you explain a little
bit?
>
> You may have trouble with an OCX.  Python doesn't really support
them.
> Pythonwin does to some degree - check out pywin\demos\ocx.
>
> Re makepy:  Each COM object has a method "GetTypeInfo()".  If this
> method works and provides the CLSID of the object, then the makepy
> system can locate and load the correct module.  This is the basis of
how
> makepy works.  However, in some cases, even though makepy has been
run,
> the COM object does not report its CLSID.  In this case, Python is
> unable to load it.
>
> However, in no case is the entire set of makepy generated files
loaded -
> so you wont see a makepy generated file loaded until a COM object it
> describes is first used.
>
> Mark.
>
>

--
--TB


Sent via Deja.com
http://www.deja.com/