Jump to content

[Discuss] Get Data From Clipboard


Recommended Posts

index.php?app=downloads&module=display&section=screenshot&id=30

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

Link to comment
  • 2 years later...

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

Link to comment
  • 1 month later...

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.

Link to comment

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.

  • Like 1
Link to comment
  • 3 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.