Jump to content

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


Colin Zhang

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
Link to comment

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
Link to comment

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
Link to comment

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 

Link to comment
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

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

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