[Discuss] Get Data From Clipboard

[Karissap]

Name: Get Data From Clipboard

Submitter: LAVA 1.0 Content

Submitted: 03 Jul 2009

Category: User Interface

LabVIEW Version: 8.0

Version: 1.0.1

License Type: BSD (Most common)

Potentially make this available on the VI Package Network?: Undecided

Copyright © 2007, Karissa Purcell

All rights reserved.

Author:

Karissa Purcell

--see readme file for contact information

Description:

This collection of VIs uses the Win32 API and Labview Methods to access the clipboard.

GetClipboardData.vi retrieves image, text or a file/folder selection and puts the data into a corresponding control.

Dependancies:

Labview 8.0.x or higher

Windows operating system (tested with XP)

Uses user32.dll, Kernel32.dll and shell32.dll (usually found in C:\windows\system32 folder)

Change Log:

1.0.1: Fixed Commenting.

1.0.0: Initial release of the code.

Click here to download this file

[pckost]

Hi Karissa,

I looked at the sample code for your "GetClipBoardData.vi" and I see the invoke node "Clipboard.get.image" that you are using to get the image from the clip board. I am using LabView 2011, and I have found that this invoke node is not supported in the LV runtime library. When my app is compiled it quits working. Is there a way to use user32.dll to do this?

Thanks

Paul Kostenick

Boeing

[Ravi Beniwal]

I ran into this exact issue with Clipboard.get.image not working in LabVIEW 2011.

Does anybody have any other ideas/ways to get image from Windows clipboard?

[Yair]

This seems to allow reading an image from the clipboard using Win32 functions:

http://forums.ni.com/t5/LabVIEW/How-to-obtain-image-from-excel-using-activex/m-p/690529#M316609

[Ravi Beniwal]

Thanks Yair!

I was (successfully) using some version of this in previous versions of LabVIEW, but it doesn't work in LabVIEW 2011. LabVIEW crashes with a "Exception: Access violation (0xC0000005) at EIP=0x0161495" message.

It fails at Clipboard.GetDIB.vi.

[asbo]

It silently crashes for me, LV2011/Win7 x64, but I didn't check to see where. My suggestion would be to figure out which CLN is causing the exception and rebuild it referencing MSDN to be sure everything's correct. Not sure why it'd be okay in past versions of LabVIEW, but if a rewrite doesn't work, submit it to NI - maybe something in CLNs got broken.

[Ravi Beniwal]

It fails at MoveBlock.vi (Function: "RtlMoveMemory")

[asbo]

Change the calling convention to stdcall (WINAPI).

[Ravi Beniwal]

Awesome! That was it! Works like a charm now! :beer_mug:

[Rolf Kalbermatter]

Change the calling convention to stdcall (WINAPI).

Noooo!!!! Please not!!! LabVIEW manager functions are ALWAYS C calling convention! That it seems to work is simply very bad luck (and it most likely doesn't really work but just not crash anymore). What the real problem is, is the fact that these VIs were written long before anyone knew what 64 Bit pointers will be and therefore LabVIEW also had no means to configure parameters as pointer sized integer since in all LabVIEW versions sizeof(*void) == sizeof(int32) was true.

The second paramter to MoveBlock() is configured therefore as int32. To make this work all Shared Library Nodes in that library need to be revisited to check for parameters being configured as (u)int32 but really being pointers and they need to be changed to be pointer sized integers. After that the library should work independent of the bitness of LabVIEW. This means that besides the second parameter to MoveBlock() at least the function where this wire comes from needs to be reconfigured too.

Edit: I see it uses the WinAPI RtlMoveMemory instead of LabVIEW MoveBlock(). From the VI Name I assumed it would be using the LabVIEW manager call. The problem about the pointer sized integer parameter however remains the same. It just so happens that Windows hasn't mapped the heap of your application above the 2GB range, otherwise it would badly crash.

And that library needs to have a lot pointer sized integer adaptions to make it 64 bit safe.

[asbo]

I hadn't even noticed the VI name, but you're absolutely right. Thanks for making the pointer-sized integer problem clear.

[imfirefly]

Thanks. Excellent work!

But I cannot find "Set Clipboard Data" VI package.