I
intrepid_dw
Hello, all.
I've created a C# dll that contains, among other things, two functions
dealing with byte arrays. The first is a function that returns a byte
array, and the other is intended to receive a byte array as one of its
parameters. The project is marked for COM interop, and that all
proceeds normally.
When I reference the type library in the VB6 project, and write the
code to call the function that returns the byte array, it works
perfectly. However, when I write the code to call the method that
expects the byte arrary as a parameter, VB informs me that "Function is
marked restricted, or uses a type not supported by Automation." The
Object Browser shows the library AND the method with its (correct)
parameter list.
The latter portion of the warning didn't ring entirely true to me,
because I had returned a byte array with no problem. It occurred to me
there might be a problem on the outbound side.
As a test, I built a quick-and-dirty VB6 COM DLL with a method that
expected a byte array, and the OLEView utility for that DLL showed the
TLB for that method showed this signature:
VB6 dummy COM DLL method:
HRESULT TestMethod( [in] SAFEARRAY(unsigned char)* parm,
[out, retval] BSTR* pRetVal);
However, when I looked at the IDL for the Interop assembly of my C#
code, the Byte array parameter signature was as follows:
C# class method w/System.Byte[] as parameter
HRESULT MyMethod( [in] SAFEARRAY(unsigned char) FileContent,
[in] BSTR FileComment,
[out, retval] BSTR* pRetVal);
Note the difference in the signatures for the first parameter; the
first is [in] SAFEARRAY(unsigned char)*, but the latter is only [in]
SAFEARRAY(unsigned char). Why the difference?? Each is expecting the
same thing.
My initial thought was that this, perhaps, was a bug in the IDL/TLB
generation code from C#, but that seemed unlikely (?). Can anyone else
offer any suggestions or help?
Ultimately, I really just need to pass a byte array from VB6 to C#, so
I figure someone is bound to have done that before. If anyone has any
suggestions, I'd be appreciative.
Thanks,
David
ps Please reply to group; email herein is long since dead.
I've created a C# dll that contains, among other things, two functions
dealing with byte arrays. The first is a function that returns a byte
array, and the other is intended to receive a byte array as one of its
parameters. The project is marked for COM interop, and that all
proceeds normally.
When I reference the type library in the VB6 project, and write the
code to call the function that returns the byte array, it works
perfectly. However, when I write the code to call the method that
expects the byte arrary as a parameter, VB informs me that "Function is
marked restricted, or uses a type not supported by Automation." The
Object Browser shows the library AND the method with its (correct)
parameter list.
The latter portion of the warning didn't ring entirely true to me,
because I had returned a byte array with no problem. It occurred to me
there might be a problem on the outbound side.
As a test, I built a quick-and-dirty VB6 COM DLL with a method that
expected a byte array, and the OLEView utility for that DLL showed the
TLB for that method showed this signature:
VB6 dummy COM DLL method:
HRESULT TestMethod( [in] SAFEARRAY(unsigned char)* parm,
[out, retval] BSTR* pRetVal);
However, when I looked at the IDL for the Interop assembly of my C#
code, the Byte array parameter signature was as follows:
C# class method w/System.Byte[] as parameter
HRESULT MyMethod( [in] SAFEARRAY(unsigned char) FileContent,
[in] BSTR FileComment,
[out, retval] BSTR* pRetVal);
Note the difference in the signatures for the first parameter; the
first is [in] SAFEARRAY(unsigned char)*, but the latter is only [in]
SAFEARRAY(unsigned char). Why the difference?? Each is expecting the
same thing.
My initial thought was that this, perhaps, was a bug in the IDL/TLB
generation code from C#, but that seemed unlikely (?). Can anyone else
offer any suggestions or help?
Ultimately, I really just need to pass a byte array from VB6 to C#, so
I figure someone is bound to have done that before. If anyone has any
suggestions, I'd be appreciative.
Thanks,
David
ps Please reply to group; email herein is long since dead.