By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,911 Members | 1,124 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,911 IT Pros & Developers. It's quick & easy.

Using PInvoke to call functions has multiple behaviors

P: n/a
I wrote some code in C in a dll which I would like to call from C#.

However I'm stuck because of the strongly typed behavior of C# which makes
limitations.

Here are the prototypes for two functions which I have trouble mapping:
int _SetOption(int nOption, void *pSetting);

void *_GetDataField(int nType, int *npLength);

For the first function depending on the variable nOption it accepts either a
string, function pointer (for callbacks) or an integer.
In C you can just typecast anything to (void *) but unfortunatly it's not
that easy in C#.

For the 2nd function it can return either a unsigned char * array or a char
* zero terminated string depending on nType. Again in C you can just
typecast it to anything.

Any suggestions how to map my functions? The worst case scenario is to
create one prototype for each possible behavior for both functions. This is
tiredsome and errorprone to create 20+ prototypes for the same function.

Thanks in advance for any advice :)
-- John
Nov 16 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Hi, Hohn.
In C a void* normally implies a simple memory block, whatever the content
is. So passing a byte[] should work in most cases. For example, you can
convert string to byte[] with Encoding classes, convert int or long to
byte[] with BitConverter class, etc. Using the resulting byte[] as the
second parameter should work just fine.
The only exception is function pointer. I'm not aware of any way to
convert a delegate to byte array. So you would probably have to have at
least two prototypes of the function, one accepts a byte[], the second
accepts a delegate. (BTW: the callback at C side would have to be stdcall
convention).

For the second function call, the function can always be marshalled as
returning an IntPtr, then you can use the set of functions provided by
Marshal class to interpret the content of the memory pointer returned. For
example, use Marshal.PtrToStructure to get a struct, PtrToString to get
strings and Copy to get the raw byte[]. Again, if function pointer is among
the potential return types, you may have some problem: you may not convert a
function pointer to a delegate through any mananged code.

Hope this helps.
Ming Chen

"John Smith" <jo********@x-formation.com> wrote in message
news:uC**************@TK2MSFTNGP09.phx.gbl...
I wrote some code in C in a dll which I would like to call from C#.

However I'm stuck because of the strongly typed behavior of C# which makes
limitations.

Here are the prototypes for two functions which I have trouble mapping:
int _SetOption(int nOption, void *pSetting);

void *_GetDataField(int nType, int *npLength);

For the first function depending on the variable nOption it accepts either a string, function pointer (for callbacks) or an integer.
In C you can just typecast anything to (void *) but unfortunatly it's not
that easy in C#.

For the 2nd function it can return either a unsigned char * array or a char * zero terminated string depending on nType. Again in C you can just
typecast it to anything.

Any suggestions how to map my functions? The worst case scenario is to
create one prototype for each possible behavior for both functions. This is tiredsome and errorprone to create 20+ prototypes for the same function.

Thanks in advance for any advice :)
-- John

Nov 16 '05 #2

P: n/a
> In C a void* normally implies a simple memory block, whatever the
content
is. So passing a byte[] should work in most cases. For example, you can
convert string to byte[] with Encoding classes, convert int or long to
byte[] with BitConverter class, etc. Using the resulting byte[] as the
second parameter should work just fine.
The only exception is function pointer. I'm not aware of any way to
convert a delegate to byte array. So you would probably have to have at
least two prototypes of the function, one accepts a byte[], the second
accepts a delegate. (BTW: the callback at C side would have to be stdcall
convention).


Thanks for the advice. After working through you said I solved most of the
issues I had. Now I just got one issue left. I got 5 different function
pointer types. Is there some generic delegate type which I could typecast
each of these function pointers to, so I will avoid having more prototypes
then nessecary?
Fortunatly none of my functions return function pointers which you described
could cause further problems.

Thanks in advance.

-- John
Nov 16 '05 #3

P: n/a
Hi, John.
You can cast any delegate type into Delegate or MulticastDelegate.

Ming Chen

"John Smith" <jo********@x-formation.com> wrote in message
news:Oq**************@TK2MSFTNGP11.phx.gbl...
In C a void* normally implies a simple memory block, whatever the content
is. So passing a byte[] should work in most cases. For example, you can
convert string to byte[] with Encoding classes, convert int or long to
byte[] with BitConverter class, etc. Using the resulting byte[] as the
second parameter should work just fine.
The only exception is function pointer. I'm not aware of any way to
convert a delegate to byte array. So you would probably have to have at
least two prototypes of the function, one accepts a byte[], the second
accepts a delegate. (BTW: the callback at C side would have to be stdcall convention).


Thanks for the advice. After working through you said I solved most of the
issues I had. Now I just got one issue left. I got 5 different function
pointer types. Is there some generic delegate type which I could typecast
each of these function pointers to, so I will avoid having more prototypes
then nessecary?
Fortunatly none of my functions return function pointers which you

described could cause further problems.

Thanks in advance.

-- John

Nov 16 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.