Re: Stack prob. Setting callback in native dll.

Do you know if this is documented in MSDN? I fine it hard to believe
that there is no way to get this to work unless I disassemble my
assembly, add the modification and compiled. Microsoft has said that
they designed .NET with interop. as a major goal.
Thanks for the information.



Michael Phillips, Jr. wrote:
There is one more step. You must use the apply modification option to the
delegate( i.e., modopt) using ildasm
see the following for details:
http://groups.google.com/group/microsoft.public.dotnet.framework.interop/msg/eaf7bd2549f5a3a3


dlbriggs" <dlbriggs1729@xxxxxxxxx> wrote in message
news:1150897040.463426.66240@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thanks fro the replay.
I have tried setting the CallingConvention to Cdecl, SdCall and WinApi.
None of this worked. And the thing is I have other calls into the dll
and they work OK.


Michael Phillips, Jr. wrote:
You may want to set the calling convention if it is not the default
WINAPI( StdCall ):

[DllImport("w32dll.dll", CallingConvention=CallingConvention.Cdecl)]
static void dllSetCallFp( void (*aFp)(void*) );


<dlbriggs1729@xxxxxxxxx> wrote in message
news:1150837798.880414.310440@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I have a 3th party dll writen in C. I have no problem calling most
functions in the dll from the managed code. But there is a function
that take a function pointer for setting a callback function that I am
having problems with.
I have the following code:

First in a wrapper class

[DllImport("w32dll.dll")] static void dllSetCallFp( void
(*aFp)(void*) );

Then in seperate class.

delegate void funDelegate(void*);
typedef void ( *FUNPT)(void*);
funDelegate ^ fp = gcnew funDelegate(MFun);
pin_ptr<funDelegate^> pp = &fp;
IntPtr ip = Marshal::GetFunctionPointerForDelegate(fp);
FUNPT cb = static_cast<FUNPT>(ip.ToPointer());
Wrapper::dllSetCallFp(cb);

MFun is just a test function.

void Client::MFun(void* pV)
{
int i = 9;
}

The problem is I can debug into the calling of MFun but when I return I
get the following errors
Run-Time Check Failure #0 - The value of ESP was not properly saved
across a function call. This is usually a result of calling a function
declared with one calling convention with a function pointer declared
with a different calling convention.
Then
'FatalExecutionEngineError'



.

Relevant Pages

  • Re: Stack prob. Setting callback in native dll.
    ... delegate(i.e., modopt) using ildasm ... static void dllSetCallFp(void (*aFp)); ... The problem is I can debug into the calling of MFun but when I return I ... with a different calling convention. ...
    (microsoft.public.dotnet.framework.interop)
  • Re: print "foo" without using ;
    ... The main reason that an OS (or other calling environment) wouldn't accept a void function, rather than an function returning int is that the calling convention is incompatible. ...
    (comp.lang.c)
  • Re: print "foo" without using ;
    ... but perhaps surprising is the fact that Microsoft ... >> actually accepts void as a valid return type. ... > returning int is that the calling convention is incompatible. ... The standard certainly makes calling a function ...
    (comp.lang.c)
  • Re: return codes for void main() blocks
    ... used in a monadic form? ... SetCurrentDirectoryin the finally block to restore the original calling ... void main ... int DoMain(char argc, char *argv) ...
    (microsoft.public.win32.programmer.kernel)
  • Stack prob. Setting callback in native dll.
    ... functions in the dll from the managed code. ... delegate void funDelegate; ... The problem is I can debug into the calling of MFun but when I return I ... with a different calling convention. ...
    (microsoft.public.dotnet.framework.interop)