Calling GetValueByPointer.xnode in executable

[EricLarsen 8]

I've got a 3rd party DLL I call from within my application.  One of the functions returns a pointer to a variable length null terminated string.  I use the mysterious GetValueByPointer.xnode to dereference the string and return it's value.  This works great from within the Labview development environment.  I'm using 2013Sp1.

 

But when I compile the application into an executable, the xnode returns an error 7.  It appears the DLL is returning a valid pointer, but the xnode can't dereference it.  My hunch is that the pointer is crossing some kind of protected boundary, but I don't know for sure.

 

I suppose I could write a wrapper around the DLL call, but I really don't want to have to do that if there is a simple workaround.  Any ideas?

 

Edited October 9, 2014 by EricLarsen

[hooovahh 768]

I've never tried it but I think there is a LabVIEW.exe call that can do this called MoveBlock

 

https://decibel.ni.com/content/docs/DOC-9091

 

Still I've seen that XNode mentioned by NI and it should work.

[ned 57]

If that parameter is a string, why not just configure it as a string in the Call Library Function Node setup? Strings are always passed by pointer, and LabVIEW knows how to deal with it. Also, I assume you know what the maximum string length is. You should preallocate memory for that string, and pass it in on the input side. You can preallocate a string by initializing an array of U8 to the correct size, then converting the byte array to a string. Or, you can set the string length in the Call Library Function Node setup.

[EricLarsen 8]

 

I've never tried it but I think there is a LabVIEW.exe call that can do this called MoveBlock

 

 

MoveBlock would work if you knew the string length in advance.  I don't think you could use it for a variable length string.  The xnode is supposed to have some internal magic that handles strings, and it does work.  Just not in a compiled executable.

 

If that parameter is a string, why not just configure it as a string in the Call Library Function Node setup?

 

Sounds promising, but it doesn't appear to work.  Labview interprets this as a 3 or 4 byte gibberish string.  I'm trying to wrap my head around why this is.

[ned 57]

Odd. Another option is to treat it as an array of U8 instead of a string. Again you'll need to allocate enough space for it initially. Then you can convert from U8 to string yourself.

 

Can you share your code where you configure the parameter as a string, and also the prototype for the function you're calling? I assume you've set that parameter to be a C string.

[Darin 166]

The XNode uses a CLFN with the library wired by path.  I have used this CLFN inside an executable, see if it works for you.

 

[EricLarsen 8]

Darin, you're a genius.  I was barking up the wrong tree.  Error 7 is a file not found error, which often seems like one of those generic error codes that's thrown out when nothing else will do.  But no, in this case the error means exactly what it says, it couldn't find the library specified on the diagram.  Problem fixed!

[Kurt Friday 36]

I had a similar issue thanks for the post

 

I found I had to manually copy

 

LabVIEW 2014\resource\lvimptsl.dll

 

into the root of my exe

[Rolf Kalbermatter 506]

I've got a 3rd party DLL I call from within my application.  One of the functions returns a pointer to a variable length null terminated string.  I use the mysterious GetValueByPointer.xnode to dereference the string and return it's value.  This works great from within the Labview development environment.  I'm using 2013Sp1.

 

But when I compile the application into an executable, the xnode returns an error 7.  It appears the DLL is returning a valid pointer, but the xnode can't dereference it.  My hunch is that the pointer is crossing some kind of protected boundary, but I don't know for sure.

 

I suppose I could write a wrapper around the DLL call, but I really don't want to have to do that if there is a simple workaround.  Any ideas?

 

xnode.jpg

 

This appears to probably call libtiff and there the function TIFFGetField() for one of the string tags. This would return a pointer to a character string and as such can indeed not be directly configured in the LabVIEW Call Library Node. The libtiff documentation is not clear about if the returned memory should be deallocated explicitedly afterwards or if it is managed by libtiff and properly deallocated when you close the handle. Most likely if it doesn't mention it, the second is true, but definitely something to keep in mind or otherwise you might create deep memory leaks!

 

As to the task of returning the string information in that pointer there are in fact many solutions to the problem. Attached VI snipped shows two of them.

 

"LabVIEW Manager" calls a LabVIEW manager function very much like the ominous MoveBlock() function and has the advantage that it does not require any extra DLL than what is already present in the LabVIEW runtime itself.

 

"Windows API" calls similar Windows API functions instead.

 

[Ajayvignesh 0]

On 10/9/2014 at 0:24 PM, Darin said:

The XNode uses a CLFN with the library wired by path.  I have used this CLFN inside an executable, see if it works for you.

 

Could someone please convert this snippet to a .vi format here? 

I'm using LV-2016 and dropping this snippet in BD imports as simple PNG image. I hope if it's converted to .vi in LV2012, I can use it in LV2016.   

[Rolf Kalbermatter 506]

Nope sorry. Somewhere between transfering that image to the LAVA servers and then back to my computer something seems to have santized the PNG image and removed the LabVIEW specific tag. The image I got onto my computer really only contains PNG data without any custom tags. The same thing seems to happen with the snippet from my last post.

I suspect something in Lava doing some "smart" sanetizing when downloading known file formats, but can't exclude the possibility of a company firewall doing its "smarts" transparently in the background.

Hope that Michael can take a look in this if snippets have been getting sanitized on Lava or if it is something in our browsers or network.

I attached a simplified version of my VI for you.

C String Pointer to String.vi

Edited June 8, 2018 by rolfk