Copy image data to clipboard

[Lipko]

Hi all!

My brain and google skills stopped working and I can't believe there's no simple solution to this.

I have image data (not a displayed image) and I want to copy it to the clipboard. All solutions I found was using getimage or exportimage, which means a dummy indicator and also a small border around the picture (I would use it if I could get rid of that border).

Is there a more sophisticated/simpler method to copy the actual image data/picture? I'm on Windows so it can be platform dependent. Wrapping Clipboard.SetImage would be a solution but maybe some of you have a code sitting around.

Thanks in advance.

[Lipko]

Okay, I did it with the dummy picture method and I found a borderless picture control here:

 

Edited July 16, 2021 by Lipko

[hooovahh]

Glad you found a solution.  Keep in mind I think that method only works if you have the front panel loaded into memory.  I saw a clipboard API years ago but can't seem to find it now, which would probably work in that edge case better.

[Lipko]

Yes, I forgot to add this notion to the post. Not a biggie though, it means that's it's not so practical to subVI this function.
My other concern about such a solution that I'm not sure it works on older platforms if the dummy is off-screen. That's why I placed the dummy on screen and toggled its visibility, but it's not needed nowadays. But I didn't care to test...

[Yair]

On 7/19/2021 at 5:33 PM, hooovahh said:

Glad you found a solution.  Keep in mind I think that method only works if you have the front panel loaded into memory.  I saw a clipboard API years ago but can't seem to find it now, which would probably work in that edge case better.

I'm attaching some of Rolf's VIs from years ago. They do include code for writing an image to the clipboard (see the example in clipbrd.llb and look at the control or panel buttons). This would probably require adapting if you're on 64 bit LV.

Clipboard - RolfK.zip

[Rolf Kalbermatter]

On 7/29/2021 at 3:14 PM, Yair said:

I'm attaching some of Rolf's VIs from years ago. They do include code for writing an image to the clipboard (see the example in clipbrd.llb and look at the control or panel buttons). This would probably require adapting if you're on 64 bit LV.

Clipboard - RolfK.zip 629.71 kB · 3 downloads

Definitely needs some love to work in LabVIEW 64-bit. This library was developed ca. LabVIEW 6i and that is loooooong before the Call Library could support pointer sized integers (LabVIEW 2009) which all the handles in there need to be in order for it to work in 64-bit LabVIEW.

[ShaunR]

10 hours ago, Rolf Kalbermatter said:

Definitely needs some love to work in LabVIEW 64-bit. This library was developed ca. LabVIEW 6i and that is loooooong before the Call Library could support pointer sized integers (LabVIEW 2009) which all the handles in there need to be in order for it to work in 64-bit LabVIEW.

Windows handles are always 32 bit. It should be fine in 64 bit LabVIEW unless there are pointers in there - but didn't see any.

[Rolf Kalbermatter]

3 hours ago, ShaunR said:

Windows handles are always 32 bit. It should be fine in 64 bit LabVIEW unless there are pointers in there - but didn't see any.

My real life experience definitely does not support this statement. I have seen handles being returned that are bigger than 0xFFFFFFFF in value and crashing the process when treated as 32-bit value. So while this may be true for some handles it certainly isn't for all Windows handles. And yes that was about Windows handles, not some third party library declaring void* pointers as handle, that were in reality pointers to a struct (in which case not treating them as pointer sized integer certainly and positively will cause problems).

I do believe that some of the Windows handles are similar to LabVIEW Magic Cookies that are basically an index into an object manager and object class specific private data list, but there certainly are various different approaches and some handles seem to be rather pointers in nature. For instance the HINSTANCE or HMODULE is basically the virtual address of where the module was loaded into memory and is sometimes used to directly access resource lists and other things in a loaded PE module (EXE and DLL) through so called RVA (Relative Virtual Address) offsets in the module image data. It's not a neat way of doing things and one should rather use functions from the debug library but sometimes that is not practical (and if you want to program not so official things it might be sometimes impossible). Of course doing it all by hand has a lot of possibilities to miss some of the complications, so that it will break with non-standard linked module files or with extensions of the PE specification for new Windows versions.

Similar things apply to some COM objects like HIMAGELIST and others. They seem to be basically the actual COM object pointer that contains the COM methods virtual table directly, not some magic cookie implementation that references the COM object pointer. All the ImageList_xxxxx functions in the CommCtrl library are basically just compiled C wrappers that call the according virtual table method in the COM object. And while COM is object oriented, its ABI is defined in such a strict way that it can easily be called from standard C code too, if you have the correct headers for the COM object class. It's even possible to implement COM classes purely in C, as has been done for a long time by the Wine project, which had a policy that all code needed to be in standard C in order to be compilable on as many different platforms as possible. They relaxed that requirement in recent years as some of the MacOSX APIs can't really get easily called in other ways than Objective C, the Apple way of object oriented C programming, which was originally an Objective C preprocessor that was then putting everything through a standard C compiler anyhow.

Edited August 22, 2021 by Rolf Kalbermatter

[ShaunR]

I can't account for your experience but for this library it is fine.

[thbu]

Thank you, it works very well with 32-bit Labview (tested clipbrd.llb\CLIP Copy Control Image.vi only).

[Rolf Kalbermatter]

On 7/29/2021 at 3:14 PM, Yair said:

I'm attaching some of Rolf's VIs from years ago. They do include code for writing an image to the clipboard (see the example in clipbrd.llb and look at the control or panel buttons). This would probably require adapting if you're on 64 bit LV.

Clipboard - RolfK.zip 629.71 kB · 13 downloads

For anyone looking at this library, I did an update in LabVIEW 2009 to properly support both 32-bit and 64-bit LabVIEW without any potential trouble.

https://forums.ni.com/t5/LabVIEW/LV-slows-down-extremely-when-having-large-contents-in-clipboard/m-p/4251413