[python-win32] problem with reference parameter to COM function(makepy)

[Coleman, Michael]

> That is true in most cases - but its not obvious from the 
> makepy generated file - did you actually call the function?

Yes.  It seems the function requires one (Python) argument to be
present, even though conceptually this value is not used.  The function
always returns the value of this argument (as long as it's an 'int').
It sort of makes sense except that there seems to be a disconnect where
this value never actually gets set by the function call.

Actually, in calling the various object methods, I guess I don't really
have proof yet that the COM object is actually being called.  The python
code is requiring correct types for the arguments, etc., but since I'm
not yet getting any return values (and the object has no visible
side-effects), I'm not sure what's happening.


> > Is there something I can do to force this?  Or, am I doing 
> something else
> > wrong?
> > 
> > Here's the documented signature:
> > 
> >      long	IsError(BOOL FAR* pbIsError);
> 
> Its not clear what the true IDL signature is for the 
> function.  If the long is actually the HRESULT, then pywin32 
> will *not* return that value (but will instead throw an 
> exception if a failure code is returned).  Indeed, this is 
> what I believe is happening...

Is there an easy way to determine the true IDL signature?  Here's some
corresponding (apparently auto-generated) code from a Visual C++ example
program that uses this object:

long CXRawfile::IsError(BOOL* pbIsError)
{
	long result;
	static BYTE parms[] =
		VTS_PBOOL;
	InvokeHelper(0x7, DISPATCH_METHOD, VT_I4, (void*)&result, parms,
		pbIsError);
	return result;
}

My COM is pretty stale, so I have no idea what this was generated from.
Could I use this information to tweak the makepy output to make this
work correctly?


> I also note that the first param appears to be missing the 
> [out] qualifer in the IDL (reflected in the second tuple item 
> being 0).  If the single value you get returned is always 
> None, that will be the reason.  I'm afraid I can't recall 
> exactly what pywin32 will do in such a case.

This sounds like it might be a good lead.  Is there some way I can
adjust for this?

Thanks again for any ideas.

Mike