Colin Zhang Posted September 6, 2013 Report Share Posted September 6, 2013 (edited) 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 Quote Link to comment
mje Posted September 6, 2013 Report Share Posted September 6, 2013 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? Quote Link to comment
hooovahh Posted September 6, 2013 Report Share Posted September 6, 2013 (edited) 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 Quote Link to comment
Phillip Brooks Posted September 6, 2013 Report Share Posted September 6, 2013 (edited) 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 1 Quote Link to comment
Colin Zhang Posted September 6, 2013 Author Report Share Posted September 6, 2013 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 Quote Link to comment
Ton Plomp Posted September 8, 2013 Report Share Posted September 8, 2013 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 Quote Link to comment
Rolf Kalbermatter Posted September 9, 2013 Report Share Posted September 9, 2013 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 1 Quote Link to comment
Ton Plomp Posted September 16, 2013 Report Share Posted September 16, 2013 CAR 422317 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.