Alec Munro wrote: > Ok, perhaps this will be useful. > > (Neither of these examples include the core arguments of the methods, > just the ones specific to InvokeTypes) > > What I call a method from I1, it calls _oleobj_.InvokeTypes with the > following arguments: > > 18, 0x0, 1, (24, 0), ((8, 1),) > > When I use the method from I2, it calls _ApplyTypes_(), which calls > _oleobj_.InvokeTypes with the following arguments: > > 1, 0x0, 1, (24, 0), ((3, 1), (12, 1), (16396, 2)) > > Now, from my reading (of old messages by Mark :) ), the last two > parameters specify method return type and argument type.
Well, it's the 4th argument that gives the return type. 24 is VT_VOID. That's unusual for a COM type. > In this case, > it seems like both methods return VOID, which seems fine. I'm a little > more concerned about the argument type. The first method is supposed > to take a single string, so that looks fine. Right; 8 is VT_BSTR, which is the typical COM Unicope string type. > The second method takes > an integer, a VT_TYPE, and a variant. I don't know if the > representation here accurately represents that. > 3 is VT_I4 (long), 12 is VT_VARIANT, and 16396 is a VT_VARIANT passed by reference, meaning an output parameter. > So, I'm fairly certain this puts that problem at something that > happens in InvokeTypes, unrelated to the arguments I passed in. I get > the impression that InvokeTypes is something of Microsofts, and > there's isn't really any way to observe what it's doing? > I've lost track. What's the root problem? Is it still the "Library not registered" issue when you call a method in Interface_2? Was this all registered through a type library, or through a regsvr32 call, or what? -- Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc. _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
