alphabit

That's great news, Lazlo. Just tried it and it works as expected :-) Sometimes It can be so simple... after you know how it works I see that at the end it was a matter of keeping the delegate alive so that the GC wouldn't collect it. Since the delegate is now declared at class scope, it holds a valid reference that doesn't get GCed. Weird things happen, but in the end it has its good sides... If we ever will see such behavior again, we know what could be done to workaround it! Thank you for figuring this out. Cheers.

Hi Lazlo, thanks for taking the time to investigate the problem. I see, it's one of the harder stuff to get rid off I also took some time these days to try to understand what could be the cause, but tbh I didn't dive into that much. Although I've collected a couple of links that I think might be helpful: Delegate Keep alive Marshal.GetFunctionPointerForDelegate Marshaling between Managed and Unmanaged Code Default Marshaling for Delegates Unmanaged Callbacks in .NET 2.0 How to: Marshal Callbacks and Delegates Using C++ Interop Pinning a delegate within a struct before passing to unmanaged code Unmanaged function pointers / Marshal.GetFunctionPointerForDelegate I've been reading your post at stackoverflow and that you managed to run the wrapper crash free while in debug build mode. Could it be that it's a matter of build optimization (Build - Optimize Code) that makes the difference in this case? It's not a practicable solution (I don't know if it would even fit this case), but maybe marking some specific methods to not be optimized could be a raw idea of a workaround? I was thinking about something like: [MethodImpl( MethodImplOptions.NoInlining | MethodImplOptions.NoOptimization )]. I hope the resources above help you a little bit... Best regards

Hi, you could try this one http://blogs.msdn.com/b/rextang/archive/2009/07/06/9819189.aspx Cheers

Hello and apologizes for the long post, I keep receiving the following exception while running a LE2 based C# application: CallbackOnCollectedDelegate A callback was made on a garbage collected delegate of type 'Leadwerks!Leadwerks.Core+EntityCollisionCallback::Invoke'. This may cause application crashes, corruption and data loss. When passing delegates to unmanaged code, they must be kept alive by the managed application until it is guaranteed that they will never be called. According to the MSDN ( see http://msdn.microsoft.com/en-us/library/43yky316%28v=VS.100%29.aspx) access violations occur when attempting to call into managed code through function pointers that were obtained from managed delegates. These failures, while not common language runtime (CLR) bugs, may appear to be so because the access violation occurs in the CLR code. The failure is not consistent; sometimes the call on the function pointer succeeds and sometimes it fails. The failure might occur only under heavy load or on a random number of attempts (happens to me!). This error is thrown regardless of which LE version I try to wrap (2.32, 2.40). What I try is to track a collision on a sphere body like: sphereBody.Callback(SphereCollisionCallback, (int)EntityCallbackType.Collision); and simply handle that event: private void SphereCollisionCallback(IntPtr _entity1, IntPtr _entity2, Vector3 _position, Vector3 _normal, Vector3 _force, float speed){ ...} The wrapped LE call that leads to the exception is: [DllImport(EngineDll, EntryPoint = "UpdateFramework", CallingConvention = CallingConvention.StdCall)] public static extern void UpdateFramework(); Any special voodoo GC stuff I should consider? Do I have to configure something additionally in the Project settings? Is there anybody having similar experience? The implementation which shows the mentioned behaviour is available on my other post at MyOtherPost. Meanwhile I left the 2.0 Header because there I can't event use the CollisionCallback. The old headers don't work either (same problem as my implementation here). Atm, I practically cannot do anything decent in C# with LE which involves collisions, so any help and pointings into the right direction are very much appreciated Edit: Just an additional technical note from an exception trace This happens when the exception occurs in the engine.dll - Exception Tracing First chance exception 0xC0000005 ACCESS_VIOLATION occurred at 0x001E2B9D, read of address 0x00000004 at 0x001E2B9D 788 0x001E2B9D 788 0x00DF0C3D 788 0x1010E814 engine.dll 788 0x101121BC engine.dll 788 0x1015A10C engine.dll 788 0x1015A780 engine.dll 788 0x1019005E UpdateFramework + 0x12 in engine.dll 788 0x001E5D33 788 0x001E5D97 788 0x001E04B3 788 First chance exception 0xC000001D ILLEGAL_INSTRUCTION occurred at 0x00DF0CD0 788 0x00DF0CD0 788 0x101121BC engine.dll 788 0x1015A0CA engine.dll 788 0x1015A780 engine.dll 788 0x1019005E UpdateFramework + 0x12 in engine.dll 788 0x001E5D33 788 0x001E5D97 788 0x001E04B3 788 0x001E010B 788 0x001E00A6 788 Module loaded: C:\Windows\SysWOW64\version.dll; Base address: 0x75320000 Size: 21504 Version: 6.1.7600.16385 788 Module loaded: C:\Windows\Microsoft.NET\Framework\v4.0.30319\diasymreader.dll; Base address: 0x53940000 Size: 688472 Version: 10.0.30319.1 788 Second chance exception 0xC000001D ILLEGAL_INSTRUCTION occurred at 0x00DF0CD0 788 Best regards ps: I am using Visual Studio 2010 Professional on Windows 7 Ultimate x64 and the project is based on .NET 4.0

FatalExecutionEngineError I have attached a small test class that should reproduce the behaviour. Simply call it quick and dirty using: new TestCollisionCallback().RunTest(); Edit: And press the "U" Key once or a couple of times, so that you see a sphere jumping up and falling down (I admit, it's way too fast). As soon as collision is detected, the error occurs. Best regards TestCollisionCallback.txt

The one provided with the headers. But also tried in my desperation with the 2.40, 2.32 and 2.31 ( knowing that it shouldn't work anyway).

Hi and great work. It's good to see solid support for C# and continuity in development ... although I'm struggling with event callbacks, to be precise with the collision callback! I don't get it working. I always receive a FatalExecutionEngineError which reads as follows: Some code to it: var groundBody = new Body.Box(10, 0.1f, 5) {CollisionType = 1}; var ground = new Mesh.Cube { Color = Leadwerks.Color.SandyBrown, Scale = { X = 5, Y = 0.2f, Z = 2 }, Parent = groundBody }; groundBody.Position = new Vector3( 0, -0.5f, -1 ); var sphereBody = new Body.Sphere(0.045f) { Mass = 1, CollisionType = 1, Elasticity = 2f}; var sphere = new Mesh.Sphere { Scale = new Vector3(0.05f, 0.05f, 0.05f), Parent = sphereBody, Position = sphereBody.Position}; sphereBody.Position = new Vector3(0, -0.65f, 0); sphereBody.Callback(sphereCollisionCallback, (int)EntityCallbackType.Collision); The main loop: while (!Window.HasRequestedClose) { if ( Leadwerks.Keyboard.KeyHit(Key.U)) { sphereBody.Velocity = sphereBody.CalculateVelocity(new Vector3(0, 1, 0), 3.125f); } Timing.Update(); Framework.Update(); Framework.Render(); Leadwerks.Graphics.Flip(); } And the callback itself: public void sphereCollisionCallback(IntPtr entity1, IntPtr entity2, Vector3 _position, Vector3 _normal, Vector3 _force, float speed) { Core.HideEntity(entity2); } Is this a bug in the implementation of the headers when handling callbacks / delegates internally? Did I make some mistake somewhere? I am using Visual Studio 2010 Prof, Windows 7 x64 and the latest C# Headers 2.0 from Aug. 26th. Glad for any help I can get ... Best regards

Hi Josh, thanks for the offer. Yes, I am interested in upgrading and would be happy to receive that link Did completely miss that change.

Hi all... ... so what does it mean in the end? I.e.: I have purchased long time ago a license through TGC at the early beginnings of LE. So I have SDKs until 2.28? And what if I would like to upgrade to the new, do I have to pay the full price? So I can't use decent c# headers on my old SDKs? It's a little bit confusing with the version numbering although. Thanx for any correct pointings. Cheers.