Different behaviour when run in development environment or as built executable.

[jrveale]

This question was first posted as a followup (here) - but it clearly is a separate issue that warrants a new question. You can see some background info there, however.

I've created a simple VI which demonstrates the issue. It's attached, as is a built version of the application.

This VI uses the Windows API to create a live feed from a USB webcam, it then allows the user to save a still from the camera to a chosen location. It was created as a workaround for a project that can't afford the runtime license for NI's IMAQ drivers, let alone a development license for them.

The image save is achieved by copying the webcam feed at a given point in time, and then fetching the copy from the clipboard in order to get a savable image.

This works very well when the VI is run from within LabVIEW's development environment, however it consistently fails when run as a built executable.

It appears to be the saving that is failing overall. Debug indicators suggest that something about the interaction between copy & Clipboard.Get Image is wrong. I don't think it's a race condition however, as I've been quite careful with the wiring with respect to that, I've also looked into it a bit already - which I'll explain a bit below.

Any help anyone can offer would be greatly appreciated!

**Further info from my debugging efforts below, not required reading!**

I'll do my best to describe what I've found so far by watching debug indicators, but it'll be easiest to see by just running the VI:

If the clipboard is empty:

- No image is saved

- Indicators show no image is fetched from the clipboard

- Opening paint and pasting produces the image that should have been saved

-> I'd think "Oh, clearly the copy is happening after the paste" however, if I then tried again I'd expect:

-The previous image to be saved

-Indicators showing the previous image

However, the behaviour is exactly the same as the first attempt.

If the clipboard has something in it already (a string or something - I think specifically if it was copied from within the application...):
- An image of the previously copied item is saved

- Indicators show an image of the previously copied item

- Pasting into paint afterwards produces the image that should have been saved.

->As before, instead of the expected behaviour if this were due to a race condition, instead when trying again I get:

- An image of the previously copied item saved again.

- Indicators still showing an image of the previously copied item

- Pasting into paint produces the new image that should have been saved...

[MichaelBalzer · Accepted solution]

I think you might be out of luck using the Clipboard:Get Image function. The help for the function states it doesn't work in the RTE:

You may be able to use some other method of querying the clipboard (.NET?), but I'm unsure off the top of my head.

[jrveale]

Thank you very much, Michael! I'm surprised I missed that...

This certainly gives me an avenue to explore at least!

[MichaelBalzer]

I wonder if you could just flatten the image data to a string and use the Clipboard Read and Write methods? Those seem to be supported under the RTE.

[jrveale]

I've just found this: someone's .NET workaround for this exact issue.

Later in the thread the marked solution states that a change in execution is also required.

I'll try it now and see if it makes a difference!

[jrveale]

For future reference, the attached project / build works nicely.

Note that under Take Snapshot.vi's VI Properties->Execution, Preferred Execution System is set to User Interface. This is required for the .NET Image.Save call to work.

Thanks for the help!