Why Invoke Node named Clipboard.Get Image is not working when build .exe application?

[Colin Zhang 0]

 

 

As above the code, it work fine under development platform, but failed when building .exe application. 

After troubleshot, find out the broken point is the Clipboard.Get Image.  What is the problem? Why does it not work fine?

 

This vi is used to copy the screen shot, and then save to PNG file. 

 

Update: 

1. Thanks, mje. Attache the VI, in fact you can copy the PNG file to BD directly and get the code.

screenshot.vi

Edited September 6, 2013 by Colin Zhang

[mje 193]

Having trouble with that snippet, it doesn't seem to have meta data allowing me to drop it on a diagram. Can you attach the VI instead?

[hooovahh 651]

Looking at the help on that invoke node method in 2012 it states that it does work in the Run-Time engine.  So I wanted to to test it and make an EXE.  I don't have 2010 but I do have 2011 so I started there.  The problem is in 2011 this invoke node method is private (and I assume 2010 as well) which means that it was probably just a test case and not fully implemented.  I would recommend staying away from private methods, especially if it is in an EXE.

 

That being said the work around is you can use other methods to get access to the image.  Here is one 

 

http://lavag.org/files/file/30-get-data-from-clipboard/

 

The other one by RolfK I like better but can't seem to find a link to it at the moment.

 

EDIT:  Sorry the clipboard code posted above uses the same Get Image function.  RolfK's does not but as I said I can't find a link.

Edited September 6, 2013 by hooovahh

[Phillip Brooks 189]

I recall this code from the NI forums.

 

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

 

I downloaded the example and noticed that the DLL call includes the path to the file user32.dll

 

 

Check the locations of the shared library in your VI. It may incorrectly include the path...

 

 

 

From the NI help: ( http://zone.ni.com/reference/en-XX/help/371361J-01/lvexcodeconcepts/locations_for_shared_libraries/ )

 

To specify the location of a shared library, you can enter the name or path in the Library name or path text box of the Call Library Function dialog box. You can also wire the name or path to the path in input of the Call Library Function Node.

Caution Do not specify the location of a system shared library, such as kernel32.dll, by path. Because LabVIEW automatically includes by-path shared libraries in build specifications, you might distribute a system shared library to another computer inadvertently. Redistributing some shared libraries, such as kernel32.dll, might cause the target computer to crash. Therefore, always specify system shared libraries by name.

Edited September 6, 2013 by Phillip Brooks

[Colin Zhang 0]

Thanks, this is the same code. Yes, I do not specify the path. 

I recall this code from the NI forums.

 

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

 

I downloaded the example and noticed that the DLL call includes the path to the file user32.dll

 

Clipboard.png

 

Check the locations of the shared library in your VI. It may incorrectly include the path...

 

 

 

From the NI help: ( http://zone.ni.com/reference/en-XX/help/371361J-01/lvexcodeconcepts/locations_for_shared_libraries/ )

 

To specify the location of a shared library, you can enter the name or path in the Library name or path text box of the Call Library Function dialog box. You can also wire the name or path to the path in input of the Call Library Function Node.

Caution Do not specify the location of a system shared library, such as kernel32.dll, by path. Because LabVIEW automatically includes by-path shared libraries in build specifications, you might distribute a system shared library to another computer inadvertently. Redistributing some shared libraries, such as kernel32.dll, might cause the target computer to crash. Therefore, always specify system shared libraries by name.

 

Thanks, yes, this is the private method until LV2011. I also heard it becomes to public one on LV2012. This morning, I asked another people to test on LV2012. Unluckily, the result is still failed. Of course, I don't verify it personally.

Looking at the help on that invoke node method in 2012 it states that it does work in the Run-Time engine.  So I wanted to to test it and make an EXE.  I don't have 2010 but I do have 2011 so I started there.  The problem is in 2011 this invoke node method is private (and I assume 2010 as well) which means that it was probably just a test case and not fully implemented.  I would recommend staying away from private methods, especially if it is in an EXE.

 

That being said the work around is you can use other methods to get access to the image.  Here is one 

 

http://lavag.org/files/file/30-get-data-from-clipboard/

 

The other one by RolfK I like better but can't seem to find a link to it at the moment.

 

EDIT:  Sorry the clipboard code posted above uses the same Get Image function.  RolfK's does not but as I said I can't find a link.

Yes, this is 

[Ton Plomp 169]

I have noticed the same recently.

One small detail that is quite strange, if the clipboard contains text, you get an image of the text back.

I'll try to install 2013 in the next few days, to see if it's fixed.

 

EDIT:

retested with LV 2013, still broken

 

Ton

[Rolf Kalbermatter 430]

The other one by RolfK I like better but can't seem to find a link to it at the moment.

 

EDIT:  Sorry the clipboard code posted above uses the same Get Image function.  RolfK's does not but as I said I can't find a link.

 

The code is part of the code capture tool here on Lava. And a thread with that library alone is here:

 

http://forums.ni.com/t5/LabVIEW/LV-slows-down-extremely-when-having-large-contents-in-clipboard/m-p/300818#M157084

[Ton Plomp 169]

CAR 422317