forums.naturalpoint.com

I wrote a c# wrapper for the Tracking Tools API and continously update it since Version 2.0. In the first time of developing it worked very well. Since Tracking Tools 2.2 we have different problems with some entry points. Here are two examples:

While this entry point works perfectly:
[DllImport("NPTrackingTools.dll")]
public static extern void TT_SetTrackableEnabled(int index, bool enabled);

This one only returns the value "true" even though any trackables were disabled with the function above:
[DllImport("NPTrackingTools.dll")]
public static extern bool TT_TrackableEnabled(int index);

The second example concerns the entry point which should return the information about whether the selected rigid body is found in the current frame:
[DllImport("NPTrackingTools.dll")]
public static extern bool TT_IsTrackableTracked(int index);

In this case the return value is also always "true" although some trackables couldn't be seen by the cameras.

I want to refer the thread http://forum.naturalpoint.com/forum/ubb ... #Post39187 where the user lich09 wrote "The only problem I am having is using the TT_IsTrackableTracked function which seems to return a library pointer..."

I changed the return value of this wrapping function from bool to int:
[DllImport("NPTrackingTools.dll")]
public static extern int TT_IsTrackableTracked(int index);

Now, i get results like the number 252117760 which seems to indicate a pointer address or something else.

Can anybody help me? Why this function doesn't work anymore with a return type bool?

Hey Nutreon,

I'm in no way an expert on wrapping native code with a managed layer but I have wrapped enough stuff to know that using the DllImport approach does seem to choke on certain data types for no particular reason.

It's unfortunate that these issues cropped up for you in recent versions as there have been no significant changes to the interface or architecture to merit any new issues like this.

I would like to recommend a slightly different approach to wrapping the Tracking Tools API, which will work for you and will avoid having to use the [DllImport] mechanism.

The approach I would suggest is wrapping the TT API with a C++/CLI wrapper instead of using [DllImport]. The only real difference is that it allows you to control the way data types are marshaled between native and managed as opposed to let DllImport do this automatically which has always been problematic in my experience.

I have a sample application that includes a basic C++/CLI wrapper for some of the functions in the API as well as how to properly marshal things like strings.

Please contact support for the sample app & wrapper and they can also put you in touch with me directly if you need more help.