In an application class I try to use this wrapper to receive the values event returned.
In particular in the constructor I initialize the wrapper object: Form1(void)
this->lib=gcnew Library(); //istanzio il wrapper
//event_registered= gcnew Library::eventRegistered(this,&Form1::processEvent);
and in the function I call a wrapper event register funciotn:
error_status err_reg_event=this->lib->registerEvent(); //utilizzo il wrapper
The problem: I think a mistake to use the wrapper by my application or also in wrapper building.
Infact I' ve got error on the callback function when I try to receive event message.
I apologize for my bad English, hoping to be able to explain problem
Someone can indicates me an example or tutorial to learn how can I work with managed C++/CLI and unmanaged C type?
thanks to help me.
I followed your advice and I've read How to: "Marshal Callbacks and Delegates Using C++ Interop"
I've tried to work on my application.
I' ve done this:
1) I decided to create a simple example without wrapper.h. So I' working only in a Form1.h.
2) Since my form1.exe work with the library of an electronic device and I constantly receive
the events returned by this device, I thinked to put the define of delegate, IntPtr and the callback unmanaged function as form1 private attributes and I declared them in the Form1 constructor:
3) After, in constructor, I call the function registerEvent(). In this function I put the calling at the library function "TED_PixRad_RegisterEventCallback":
4) the callback implementation in my Form1 is this:
void cdeclEventCallback(const event_id eventID, const Event *eventData, void* customData )
gcroot<Form1^> & native_handle = *((gcroot<Form1^>*)customData);
Oss1: I think I must using _native_handle and not passing this (Form1 refer).
Oss3: processEvent is an internal function of Form1 that receive the code eventID and write the code mean in a form1 label.
Oss2: The compilation is without errors or warnings.
Assuming that I can not debug because the device connected to a machine other than the development,I have seen that the device gives me error event handling return
In particular, writing message on Form1 labels I' ve seen that I cannot enter in cdeclEventCallback function and I cannot call processEvent().
I can not understand what could be in error and this is a logic error in using Marshal:: GetFunctionPointerForDelegate in my example.
I find that probably the error lies in the way the gcroot, because if I pass NULL in place of _native_handle and put processEvent () outside of Form1, I do not come back errors on callback events in the logs of the device;
OSS2: I used gcroot to pass ref of FORM1 between the managed and unmanaged code;
OSS3: I remember that the prototype of "TED_PixRad_RegisterEventCallback" library function is:
and customData for me is my Form1 (in general my object class).
I must implements processEvent like object function (then as Form1 funciotn) and so I must to pass FORM1 refer in TED_PixRad_RegisteredEventCallback that is the function of unmanaged library.
I've never done this with C++/CLI but I've done it quire frequently between C# (managed) and C (native), and the one thing to remember is in the native world you must declare the callback function as StdCall.
thantks for advice.
Reading your article, I had an idea:
- I haven't used gcroot but directly GCHandle.
- I must casting because parameter library function is void*.
This is what I've done:
1) I 've used GCHandle to build an handle to object (for my example FORM1) and I've used GCHandle.Alloc() to reserve memory when i send object refer from managed code to unmanaged library. I' ve done this in the constructor. So it is:
3) Since library function receives void* customData parameter and it returns this in callback function, I must cast my pointer Form1 refer from IntPtr to void*. After, in the callback function I must casting from void* to IntPtr and in second time I must casting from intPtr to Form1^.
The implementation of the callback funciton now is:
Now I must call processEvent like an object function and not like Form1 external function.
I compiled without problems and doing some tests I've seen that behavior is correct, that the occurrence of an event correctly calls the callback function and that this uses the correctly reference at Form1.
Less than denials I think the problem is solved, thank you all for your help.
I'm a long time lurker on CodeProject, and finally have a problem that I'm getting nowhere on.
We have a C++ application we're building in VS2008 that uses "it just works" interop to create reports using Crystal Reports. So there is a C# ReportHandler (which contains a reference to the Report itself), and a C++/CLI ReportWrapper. If the ReportWrapper is built as a static lib, it works under both WinXP x32 and Win7 x64. However, when the ReportWrapper is built as a DLL, it works under WinXP x32 but crashes under Win7 x64 (it's built as a x86 application either way).
It crashes not when the app starts, but when you try to bring up the File:Open dialog using CFileDialog::DoModal(). The call stack is not obvious:
If I force the "bVistaStyle" flag in CFileDialog to false, the dialog does work without crashing the app; however, it then causes strange out of memory errors later on when we try to actually load a file (using dynazip). That tells me that something nefarious is going on, other than just with the CFileDialog (I suspect some strange DLL corruption).
- we have a similar Report/ReportHandler/ReportWrapper in a different application, and there are no problems with that app.
- if the app is built in release configuration under WinXP x86, it runs fine when installed on Win7 x64.
- if the app is built in release configuration under Win7 x64 (as an x86 project), it runs fine.
So it only crashes when running the debug build (whether debugging or not).
Here's what I've tried so far:
- I compared project settings between the app that works and the one that doesn't. As far as I can tell they're the same.
- I compared project settings between the Release and Debug configurations.
- I created a dummy test MFC app and started pulling in libraries/assemblies/dlls from the app that doesn't work; in the test app, however, the same Report/ReportHandler/ReportWrapper works properly. However, I have not pulled in all of the libraries that are linked into the app.
- I've reread about implementing IJW interop (someone else implemented it) to confirm we've set it up properly.
- I've tried depends (x86), but depends crashes when I try to profile the app.
- I've enabled loader snaps to try and see if anything odd is going on, but have limited experience looking at DLL loading.
- various and sundry other things that I can't think of right now, all to no avail (I've been struggling with this for a while).
Any suggestions on how to approach this problem would be most welcome. Given what's going on, I think there's actually a deeper problem underlying this that's only exposed in this particular configuration (when built as a DLL) -- I don't think it's just a matter of the DLL configuration being the problem.
Gosh, on the surface I can only hazard a guess. You seem to have covered things pretty thoroughly though.
Some wild-assed guesses:
1. When you statically link and run the app, the .NET framework is automatically loaded. When you dynamically link and run, perhaps a different version of the framework is started outside of your control. For example, if there's a shell extension pulled in by the Open dialog, perhaps it's loading .NET 2 and you need 3.5 or 4? This could throw an exception when your DLL finally gets loaded.
2. Does the DLL form reference a C# assembly and fail b/c you need to handle the AppDomain.AssemblyResolve event? Just having the assembly in the same dir as the C++/CLI DLL does NOT mean that C# assembly will be found automatically as I've learned the hard way.
3. Any clues in the Fusion Log views after the failed load? (use fuslogvw.exe) or in the System Event viewer logs?
I'll ponder more but it's hard to help w/o playing around w/ things as I'm sure you're aware...
Thanks, John, I appreciate the effort. I don't mind guesses at this point, wild-assed or not.
1. I'll look further into that to make sure we're binding to the correct version. We've typically deployed our app binding to .NET 2, to keep the installer footprint small. Unfortunately I can't use depends to find out exactly what's being loaded.
2. I have "resolve #using References" set to the output folder where the assembly DLL is built, and I've made the assembly a dependency of the wrapper library in the VS solution. I've set references for it in no other way.
3. No clues. I ran fuslogvw and enabled all logging; when I run the app to point of failure, nothing appears in the log so I presume that means no binding is triggered. In my test app that does work, nothing shows up in the Fusion log until I actually launch the report. The app that's failing never even gets that far (I just run it and do File:Open).
Thanks for all the input, everyone. I'm currently trying out AppVerifier, something I wasn't previously aware of. It helped me figure out that there's a buried call to LoadLibrary() within a DllMain() and I'm just testing now to see if that's our issue.
That was it! We had a DLL unrelated to C++/CLI that was triggering a buried LoadLibrary() within its DllMain. Once removed, it's running fine. Talk about a red herring: it had nothing to do with C++/CLI, it just happened that by linking in that project, it pushed the app over the edge (but only in Debug and only in Win7). Nasty. It's a problem that's been plaguing us for months (but we were able to avoid it up until recently).
Thanks John for suggesting Application Verifier. Of course it didn't say "hey, this is wrong", but it did raise a flag in the DLL that was causing all the trouble and got me to focus on what was going on there. And that's exactly what I was looking for: not necessarily "tell me what's wrong with my code" but "how do I figure out what's wrong" and your suggestion helped nail it. And jschell, you were right about it being a bug in a different library whereas I had focused mainly on the C++/CLI project itself.
So thanks both to John Schroedl and to jschell for taking the time to respond, and to CodeProject for the great site. Much appreciated!
You want less than a millisecond? Our eyes cannot even see such speed. I do not know of anything that is faster than a timer in .NET... If your animation is not running to subtle, maybe you should look for smaller pixels or move the image by more than a dot instead of faster images.
No idea how to do that though. Just saying speed might not be the problem.
It's the only way I could get the collision working properly.
Obviously there are other ways. Here are a few ideas:
1. you don't need to draw anything to detect collisions, you could do it mathematically. That is modelling rather than animation. The model would generate the exact time and location of the collisions, animation would only be used to show the required frames.
2. even when collision detection is based on actual frames, you don't need to do it in real-time, you could calculate a number of new frames ahead of time (at the expense of more memory), and only show some of them, at the right pace.
Either way, you may choose to use floating-point for extra accuracy while calculating, and turn the relevant data into integers when calculating the actual frames.