Help required with interop

  • Thread starter Thread starter Jon Skeet
  • Start date Start date
J

Jon Skeet

I'm trying to speed up a data migration tool I'm writing that uses COM
interop. Currently I'm accessing each field within a record
individually, which works, but means going across the managed/unmanaged
boundary a heck of a lot.

The COM object I'm working with has a method which I'm sure *should*
help, but I can't get it to work. It's described in the documentation
as:

GetDataEx method:

Description: Returns an array of strings containing the data for each
field specified in an array of fields.

Syntax: GetDataEx iFieldArray, szValueArray

Parameters: iFieldArray Returns an array of short integers (or
pointers to short integers in Visual C++)
that represent the field IDs of fields
for which to get the data contained in the
fields.

szValueArray Returns an array of strings (or BSTRs in
Visual C++) for the data that is returned for
the specified fields. The same number of
elements must be specified for the
iFieldArray and the szValueArray parameters.

Note: In Visual C++, use VARIANT.pparray instead of Variant.parray for
pointers to elements in the array.

Return type: void

Example: [irrelevant stuff snipped]

Dim IdArray(10) as Integer
Dim OutputArray(10) as String

' Snip getting the appropriate db object

IdArray(0) = 5
IdArray(1) = 6
IdArray(2) = 10
IdArray(3) = 15

db.GetDataEx IdArray OutputArray



Now, I've tried a number of ways of doing this, but none of them have
worked. The most obvious one is something like:

short[] fields = new short[]{1};
string[] values = new string[1];

db.GetDataEx (fields, values);

but that sets an error code of "invalid parameter" - as does everything
else I try.

Any light anyone could shed on this would be much appreciated...
 
Does that help at all?
Not really. If you have the tlb file then you can load it up using the
Ole/Com object viewer found under the tools menu of dev studio. This might
give you a bit more info on the method.

Regards
Lee
Jon Skeet said:
Lee Alexander said:
From the documentation it looks like it expects and array of pointers to
integers. Whereas you are passing a pointer to an array of integers.

Yup - I wondered about that. I tried declaring it as object[] so that
boxing would take place, hoping that the reference would effectively be
a pointer to a short. It didn't help...
Could
this be the problem? Do you have the IDL for the offending function??

I don't, but I have the relevant sections of the tli/tlh files (with
names changed to protect the innocent. From the tli file:

inline HRESULT [Removed]::I[Removed]::GetDataEx
(const _variant_t & vFieldArray, const _variant_t & vValueArray )
{
return _com_dispatch_method(this, 0xe0, DISPATCH_METHOD, VT_EMPTY,
NULL, L"\x000c\x000c", &vFieldArray,
&vValueArray);
}

Does that help at all?
 
Lee Alexander said:
Not really. If you have the tlb file then you can load it up using the
Ole/Com object viewer found under the tools menu of dev studio. This might
give you a bit more info on the method.

Aha. Cheers - sorry, it's a while since I've done any "real" COM work,
and I didn't do much then :)

Hmm. It doesn't seem to give much more info:

[id(0x000000e0)]
void GetDataEx(
VARIANT vFieldArray,
VARIANT vValueArray);

Distinctly unhelpful :(

Never mind - I've found another way of speeding things up considerably:
loading the whole database into memory to start with! I think a lot of
the time was being spent jumping around different records in the
database...
 
Never mind - I've found another way of speeding things up considerably:
okies.

Regards
Lee

Jon Skeet said:
Lee Alexander said:
Not really. If you have the tlb file then you can load it up using the
Ole/Com object viewer found under the tools menu of dev studio. This might
give you a bit more info on the method.

Aha. Cheers - sorry, it's a while since I've done any "real" COM work,
and I didn't do much then :)

Hmm. It doesn't seem to give much more info:

[id(0x000000e0)]
void GetDataEx(
VARIANT vFieldArray,
VARIANT vValueArray);

Distinctly unhelpful :(

Never mind - I've found another way of speeding things up considerably:
loading the whole database into memory to start with! I think a lot of
the time was being spent jumping around different records in the
database...
 
Back
Top