C# to C++ callback problem

[doodab]

Ah, now it makes sense. I've never seen anyone put a loop like that into a function called "registerCallback" before

I thought you meant you registered the callback and then there was a thread in the DDL that called it.

Why don't you just do away with the callback and put a loop in the mangled ^H^H^H^H aged code to call "getSomeData" every two seconds? That way you could perhaps pass in a reference to the destination structure and the marshalling would go more smoothly.

 

[suityou01]

Ah, now it makes sense. I've never seen anyone put a loop like that into a function called "registerCallback" before

I thought you meant you registered the callback and then there was a thread in the DDL that called it.

Why don't you just do away with the callback and put a loop in the mangled ^H^H^H^H aged code to call "getSomeData" every two seconds? That way you could perhaps pass in a reference to the destination structure and the marshalling would go more smoothly.

The function is a stub, that I am using to test my .net app. Ultimately it will be connected up to my WFP driver, and it will be callback based.

 

[doodab]

The function is a stub, that I am using to test my .net app. Ultimately it will be connected up to my WFP driver, and it will be callback based.

The function in the DLL or the .Net app will be connected to the driver?

I am presuming the DLL will be handling IO to the driver device and then the .Net app will be using the DLL as above?

 

[suityou01]

The function in the DLL or the .Net app will be connected to the driver?

I am presuming the DLL will be handling IO to the driver device and then the .Net app will be using the DLL as above?

Yep that's it. I tried having the .net app talking direct to the driver but despite microsoft's claims, it just isn't as quick as unmanaged (native) code, fact. So this dll should handle all the io flak from the driver, and only pass important stuff up to the front end.

Or so the theory goes.

 

[VectraMan]

Why don't you just do the DLL in C++ CLR? Then you can make the interface all .NET, and still call the native code.

 

[doodab]

Why don't you just do the DLL in C++ CLR? Then you can make the interface all .NET, and still call the native code.

Then you still have the problem of accessing the driver from managed code.

 

[VectraMan]

Then you still have the problem of accessing the driver from managed code.

No you don't. C++ means you can mix and match managed and unmanaged in the same function.

Did it work in the end? Looking back at the code, the thing that jumps out at me is that you're passing a FIREWALL_MESSAGE that's on the stack. I didn't think you'd be able to pass a delegate in either, but obviously you can.

 

[doodab]

No you don't. C++ means you can mix and match managed and unmanaged in the same function.

Did it work in the end? Looking back at the code, the thing that jumps out at me is that you're passing a FIREWALL_MESSAGE that's on the stack. I didn't think you'd be able to pass a delegate in either, but obviously you can.

How do you do that? I thought the boundary was always at a function call i.e. you could have managed and unmanaged functions in a mixed assembly but each function is either managed or unmanaged.

Good point though, the code might be easier to read and write.

 

[suityou01]

No you don't. C++ means you can mix and match managed and unmanaged in the same function.

Did it work in the end? Looking back at the code, the thing that jumps out at me is that you're passing a FIREWALL_MESSAGE that's on the stack. I didn't think you'd be able to pass a delegate in either, but obviously you can.

Thank VM will look into this.