take screenshot and saves the image to a PNG file

[Avivit]

Hello,

How can I take screenshot and save the image to a PNG file?

thanks,

Avivit.

[tst · Accepted solution]

If you want an image of a VI's front panel, you can use the Get Panel Image method (or the Code Capture Tool, which provides a palette of VIs to do this).

If you want an image of the entire screen, you can simulate a key press on Print Screen, the use the Application class method Clipboard.Get Image to get an image of the clipboard content. If you search for "screenshot" you should probably find some examples already.

[PDC]

I have managed to print screen, read the clip-board, and save as a png file. The VI works fine. I then call this as a sub-VI within a loop  in order to print screen, save to a png and subsequently email to myself in order to check the progress of my VI. Since it's in a loop, I call it multiple times. I run into a problem, the Write-to-png built in VI never closes the file it wrote untill the VI stops running.

This is an issue because it prevents me from saving to the same file path more than once. Of course, I could simply make interative path names, but then I'd just end up with a lot of image files open in memory.

Is there a way to save a png (or any image file) such that I close the file after writing it (so it's no longer in use by labview)??

[tst]

Is this something which is reproducible in a simple example? I don't remember having LV keep open handles to a PNG file created by the PNG VIs, but I may not have done the exact same thing that you do.

Generally, when I have something where I have to create temporary files and can't control their lifetime, I will create them in a special temporary folder, then delete all the files in the folder together (at startup, shutdown, or whenever you feel it to be right).

[Darin.K]

I have never run into a problem writing to the same PNG file repeatedly.  Could you describe the steps.

[PDC]

this is a quite reproducible problem. Some more clarification on my part might help:

I have a loop that contains, among other this, (1) a sub-VI that prints-screen and saves as a png and (2) a sub-VI that emails me the png file as an attachment. The 1st sub-VI simply uses the user32.dll to simulate a print-screen key stroke, calls clipbpard get image, and then formats and saves the image to a png file using the built-in VI write-to-png. This loop should update this same png file, because the path does not change. However, I've noticed that while the loop is running the png file does not update. It simply keeps sending the 1st image it took. The image updates if the VI stops and is run again. I assumed the problem was either with the clipboard not updating or the file not writing.

I think the png file remains open while the main VI (i.e. this loop) runs because I cannot delete the file while the VI is running, only once it stops or is quit. Windows gives me an error that the file is currently in use by labview. Therefore, I think the file is not updated because it remains open.

I've attached the print screen VI. Feel free to stick it in a loop and give it a try if you don't spot something obviously wrong. I did not include the main-VI that I actually use since it contains a lot of instrument I/O, which would prevent someone testing the VI.

[Darin.K]

It seems what is in the clipboard is dutifully being written to file.

I get the screenshot a bit differently.  Try this.

[PDC]

Your version seems to work. I placed them in a loop (the loop contain a sequence that 1st calls the print screen VI and 2nd waits for 10s).

My version only creates a png file if the VI window is active (top window), and it seems to lag in that the 1st interation saves the png image that should have been saved on the last iteration from previously running the VI.

Your version updates the png file reguardless of wether the VI is the top window. Though yours oddly is saving two files... one with a different file name (actually the file name I used yesterday while trouble shooting) that is not the path i've sent and the file contains a image that only updates upon the 1st iteration. Not sure what that's about. 

I'm not sure why one seems to work (relatively) properly and the other doesn't. But they are two very different ways oftrying to accomplish the same goal.