Jump to content
News about the LabVIEW Wiki! Read more... ×
chigaitakanoha

Is it possible to access the native buffer from LabVIEW when a DLL is written in C++/CLI (.NET)

Recommended Posts

Hi,

I have a DLL written in C++/CLI and have a property available to LabVIEW to access the native memory space, but from the property I can't use examples described in this link: https://forums.ni.com/t5/Developer-Center-Resources/Calling-C-C-DLLs-Containing-Simple-and-Complex-Datatypes-from/ta-p/3522649

Is it because the DLL must be written in pure C/C++ instead of C++/CLI (.NET) ? 

Thanks!

 

Share this post


Link to post
Share on other sites

The page you linked to is only for c dlls. If its a .net assembly dll, you can use the labview .net interface.

https://forums.ni.com/t5/Developer-Center-Resources/Calling-NET-Assemblies-from-LabVIEW/ta-p/3523180

to test this, drop down a constructor node and from the dialog, select browse and locate your dll. If it loads, you're in the right spot.

Share this post


Link to post
Share on other sites

Thank you Smithd, I am able to access the managed memory space. I am trying to access the native memory space. So what has been done is this I have a buffer in the native and that's marshalled and stored in the managed space for LabVIEW to access. I am trying to access the native buffer from LabVIEW. 

Thanks,

Share this post


Link to post
Share on other sites

Why do you post this in the LAVA Lounge and not in the LabVIEW->External Code forum?

You really need to give more information. You mention .Net, C++ and CLI. That is all possible to combine, though not necessarily the most common way. You talk about native pointers and managed memory in a somewhat ambigous way that makes it very hard to know what you really have.

A memory pointer is not simply a memory pointer. It is important to know how it was allocated and with which exact function. That determines if a simple pointer is still valid when accessed from a different managed environment or not. Generally memory allocated in one of the involved managed environments (.Net or LabVIEW) can only be accessed through functions of that managed environment, otherwise you need to do marshalling, which LabVIEW does automatically when you use the .Net functionality in LabVIEW.

If your C++ code explicitly allocates memory through Win32 API calls or Standard C runtime calls (C++ allocations could be trickier especially in combination with compilation as .Net assembly), this memory is not managed by .Net but by your code. If you pass this pointer to LabVIEW and make sure that the pointer remains valid (no realloc() or free() calls at all ever between passing the pointer to LabVIEW and trying to access it in LabVIEW) you can simply use the function MoveBlock() as mentioned in those linked articles.  Of course you need to understand the difference between a pointer and a pointer reference in order to be able to correctly pass this pointer to the MoveBlock() function.

Show us your code and what you think is not working there.

One other question is why do you use C++ when you want to create a .Net assembly (or the opposite, why create a .Net assembly when you want to use C++). It is not the most logical combination as your .Net assembly still contains non IL compiled code, so is equally binary platform specifc as a normal DLL. Creating a real DLL instead might be more straightforward.

Edited by Rolf Kalbermatter

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use.