Mark Hammond skippinet.com.au> writes:
> There is no arbitrary limit that I recall. Can you show us a snippet of
> failing code and the traceback?
>
> Thanks,
>
> Mark
>
Hi Mark,
I've gotten right down to the problem. Has nothing to do with the number of
parameters. One of the parameters is
Brad Johnson ballardtech.com> writes:
> So I guess my question becomes how can I change the parameter type so everyone
> is happy?
>
Never mind. I managed to make it a reference to a SAFEARRAY of USHORTS without a
hiccup from either client. I guess I need to brush up a little bit on my COM.
_
> I've gotten right down to the problem. Has nothing to do with the
> number of
> parameters. One of the parameters is of type VT_VARIANT (0x000c). That
> variant
> type is not supported by the function PyCom_PyObjectFromVariant, which
> gets
> called along the chain of getting the values down to P
Mark Hammond skippinet.com.au> writes:
> Pass it as a variant holding the actual type instead of adding a kind of
> "indirection".
>
> Cheers,
>
> Mark
>
Thanks.
That's exactly what I ended up doing. I guess I was just a little too green to
do it right the first time. I didn't know how to pas
> That's exactly what I ended up doing. I guess I was just a little too
> green to do it right the first time. I didn't know how to pass a SAFEARRAY
> correctly, so I thought I'd hide the problem and put it in a VARIANT :-)
>
> Strangely, this actually worked for my C++ clients.
Best I can tell,
Mark Hammond skippinet.com.au> writes:
> but the code fails to gracefully handle the non-byref variant case, as you
> found. Oh well, some other day (or if someone is keen, a bug couldn't
> hurt...)
>
> Cheers,
>
> Mark
>
I added a bug to the SourceForge bug tracker :-).
___
