Re: Stack prob. Setting callback in native dll.



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.
    ... 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)
  • Native DLL and callback in C++
    ... I'm trying to figure out how some stuff can be done when calling ... handle for the user of the DLL, in this case it's called Test and the ... function and call a function that, in turn, will call the callback ... void setCallback{ ...
    (microsoft.public.dotnet.framework.interop)
  • 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)

Loading