Tim_S

QUOTE(TobyD @ Jan 17 2008, 01:41 PM) Yes, the first part looks recognizable. I don't see a "Get Image" under the clipboard, so I assume there's a flag I've not set in the LabVIEW ini file. Taking the data into a Draw Flattened Pixmap produces an interesting image, but not a correct image. The results remind me of interlaced image files. Before I forget again, thanks to everyone who is helping!

QUOTE(tcplomp @ Jan 17 2008, 07:09 AM) The Code Capture Tool doesn't provide what I'm looking for as I want to perform a screenshot of the entire display, which could include, say, an instance of Notepad. It appears that the tool accesses the clipboard, but is this different than the method that the invoke node Read from Clipboard performs?QUOTE(Louis Manfredi @ Jan 17 2008, 10:18 AM) Hi Tim:Have you tried SnagIt? (http://www.techsmith.com/) Not completely free, but inexpensive & has a free trial & I've been happy with it.Best, Louis In 10 minutes of playing about with SnagIt, I'm impressed with the user interface and the apparent ease of use. However, it doesn't appear to have a programmic interface, which is what I need (lousy customer specs!). There is an registration for ActiveX for SnagIt (nothing in .net), but the property and method nodes were empty.

I'm looking to perform a screen capture and am having some difficulty finding how to do this. By screen capture I don't mean a single VI's front panel, but the entire display. I found an example that simulates using the print screen button to capture the display to the clipboard. This worked when I pasted into paintbrush, however reading the clipboard in LabVIEW returned a zero length string. Searching resources hasn't produced any other information on how a screen capture of the display can be done. Ideas I've had appear to have run into walls. I'm using LabVIEW 8.5 on Windows XP. Anyone have ideas? (Dare I hope for sample code?)

QUOTE(Tomi Maila @ Jan 16 2008, 01:48 PM) From a bit of poking about, it appears that all of the information you're looking for is blocked from any remote access. I think the sugestions of the local application publishing the information in some manner (TCP, UDP, front panel, shared variable, etc.) to be your best solution.

I'm assuming you're using the open application reference, though I've noticed that you could be using the TCP communication or similar as well. Looking at the Open Application Reference, you have to know the machine name and can optionally add the port number when making the connection from A to B, so I assume you know both of those at A. You'd still need to get that information to C, though if you all ready know this information at A to where you can make the connection in the first place, then why don't you know it at C? What version of LabVIEW are you using? You may be able to use shared variables to have B publish the needed information to where A and C can access it. Tim QUOTE(Tomi Maila @ Jan 16 2008, 07:30 AM)

I've used both methods and which I've used depends on what the dynamic VI is doing. If it's something that I'm going to run once, I set the front panel control values and then run the VI. If it's something that's going to loop in the background, I may pass some initial values (configuration files path, for example) and then pass information to it using events, queues, and LV2 globals. The method I used depended on the application's structure and the nature of data to send. For example, error handling routines get their information from a queue so all the errors can be handled at once while a value that can be set from or used in multiple points in the application goes to a LV2 global.

This what you're looking for? QUOTE(thevoiceover @ Oct 3 2007, 02:18 PM)