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

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

Recommended Posts

post-27969-0-69169200-1378474493_thumb.p 

 

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 by Colin Zhang

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 by hooovahh

Share this post


Link to post
Share on other sites

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

 

post-949-0-24604100-1378476780.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.gifCaution 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 by Phillip Brooks
  • Like 1

Share this post


Link to post
Share on other sites

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

 

attachicon.gifClipboard.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.gifCaution 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 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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

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.