LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Writing to the System clipboard

This company uses LabVIEW 2012 and LabWindows 2010 in an Aerospace environment. The use of older versions is done to have commonality with their facilities across the globe. Thus, I cannot get them to upgrade.

 

On their new test station, they have 14 serial ports to communicate with the unit under test. I have developed a LabVIEW serial port interface program that will allow them to communicate with those serial ports. I have the ini file configured to allow the user to run multiple instances of the executable, for as many ports as they desire, during their testing. One option that they requested is the ability to right click the mouse, have a menu display to select copy or copy all of the data to the clipboard so that they can paste the received data into a test report. I used the LabVIEW App Invoke Node function Write to Clipboard and Read From Clipboard to perform the task. However, I have the issue that this works on some instances and does not work on other instances of the executables. Since the code is the same, the user enters which port to connect to, I do not understand why I have this issue. It works fine on my PC which only has a single COM port.

 

I decided to write two LabWindows functions to read and write to the clipboard using ClipboardGetText and ClipboardPutText. I call those dll functions from LabVIEW. The first call to the function ClipboardPutText works in the sense that the data is placed into the clipboard. However, I immediately get a fatal error and the process stops. (I did not save a screen image and the test stations are in use at this time). After that, none of the other instances will copy the data and they all result in a fatal error and stop. This is repeatable as I restarted the software numerous times as I tried to determine the cause.

 

Since I do not have access to the code for the clipboard functions, I cannot determine if I need to configure something else related to the clipboard or the process attempting to read/write from/to the clipboard. I will continue to search but wanted to ask the experts in control of the clipboard software to determine if they have any recommendations on what may need to be added.

 

For LabWindows, the only other call that I performed was a free command after I executed the ClipboardGetText, if the pointer to the text was not NULL.

 

I will post this in both the LabVIEW and LabWindows discussion boards in case one or the other has a solution.

 

Thank you for your help.

 

I can provide a zip file, containing the source code, to NI personnel if you provide an email address. Since I am a contractor, I am not sure if the company’s policy allows global posting of their code, although I may be able to reduce the code to a minimum example, if necessary.

0 Kudos
Message 1 of 11
(4,122 Views)

Crash Reports

Download All
0 Kudos
Message 2 of 11
(4,109 Views)

I would have expected that the function of the LabWindows methods would be the same as the LabVIEW built in methods to read/write from the clipboard? (So I would have expected the behaviour to be the same in both).

 

Perhaps you can use a Call Library Function to WINAPI or a .NET class (System.Windows) to read/write to the clipboard instead? 


LabVIEW Champion, CLA, CLED, CTD
(blog)
Message 3 of 11
(4,099 Views)

I'd like to delve a little more deeply into the experience you have with the LabVIEW App.WriteClipboard (and ReadClipboard?) methods, since they would be the obvious way to make this work (and I've used them without problem in the past).

 

When you say they "don't work", are you evaluating the error output of the invoke node?

Are you wiring *in* an error wire, and if so, are you 100% certain there's never an incoming error that would cause the invoke to be skipped?

If you can categorically rule out error in/error out issues, next I'd look at what application you're trying to do the paste operation into.  Is it Word? Excel? Notepad?  There may be some clues in your answer.

 

Finally, have you tried doing a ReadClipboard immediately after the WriteClipboard and compared/displayed the two strings as a debug attempt?

 

Hope this gives you some fresh thoughts...

Dave

David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
Message 4 of 11
(4,073 Views)

Other than Dave's suggestions (which I agree with. My experience with the method was also that it works quite well across process boundaries), you can also do a search here. There have been VIs posted in the past which make direct call to the Win32 functions for writing text to the clipboard. You can try rolfk's posts here and on LAVA.


___________________
Try to take over the world!
Message 5 of 11
(4,060 Views)

There was a bug fixed in LabVIEW 2013 for problems relating to copying large amounts of data to/from the clipboard.

 

CAR 39604

 

http://forums.ni.com/t5/LabVIEW/Labview-freeze-when-accessing-a-custom-menu-with-data-on-the/td-p/19...

 

 


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

Message 6 of 11
(4,031 Views)
Wow, Phillip, I never encountered that bug. Seems pretty insidious. I could be easily persuaded that that is the reason for some of the OP's issues.

Bill, just how much data are you typically placing on the clipboard each time?
David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
Message 7 of 11
(4,015 Views)

I have done more testing in an attempt to clarify the error condition. I upgraded to LabVIEW 2014 on a Windows 7 SP1 system. I have enclosed some screen shots to show what I am doing.

 

My software allows multiple copies, 14 in this case, versions of the executable to run at one time. The software controls serial ports. The enclosed image of the front panel, LabVIEW window.png, indicates the COM port, baud rate, and version at the top of the window. This first small control allows the user to enter a command to send to the port. The large bottom indicator displays the data received on the port. I have menu items, pressing the right mouse button, that allows the user to clear all of the data, copy selected data, or copy all data. I have enclosed images of the copy, copy all, write to clipboard, and read serial port parts of the code. I was only copying small amounts of data, perhaps less than 256 bytes.

 

Here’s what I have noticed:

 

  1. If I execute the code on my desktop computer, only 1 COM port, everything works fine. The copy and copy all will place the data into the system clipboard which allows the pasting of the data into Notepad.
  2. If I execute the code on the test station, opening all 14 ports, we are using the NI serial card for all of the additional ports, the code works fine, as in item 1, for a couple of the executables but not the rest.
  3. If I select a subset of the data being displayed, highlighted in blue by LabVIEW, then right click the mouse selecting the copy, the blue highlighting goes away but the data is copied to the clipboard allowing me to paste into Notepad.
  4. If I right click the mouse selecting copy all, the data is NOT copied to the system clipboard so that I cannot paste it into Notepad.
  5. In the Write to Clipboard function, I write to the clipboard and then read the clipboard. I added code to display, in a popup window, what was written to the clipboard and what was read from the clipboard. The data was the same although the data was not on the system clipboard so that I could paste it into Notepad.
  6. I tried to select a subset of the data being displayed and then right clicking the mouse to do a copy all to see if that made a difference. It did not.
  7. I tried to make the Write to Clipboard function re-entrant to test that theory. Not change in the behavior.
  8. At one point, I tried to use LabWindows. I used the LabWindows clipboard calls and then tried calling the Microsoft clipboard functions directly. While those functions worked in LabWindows without a problem, I would get executable crashes when I tried to call my LabWindows functions from LabVIEW. If I commented out the actually code part, the call to the functions would return without crashing the executable. The issue was not in how the LabWindows functions were being called but something in the clipboard calls themselves. So, I decided that making a call using LabWindows offered nothing that I could use. I returned to using only LabVIEW and updated to 2014 to determine if that might solve the issue. No luck so far.I do not understand why, when I call the LabVIEW function to write to the clipboard, that it does not work for every executable of the multiple instances. Is there some other function that needs to be called prior to writing to the clipboard due to having multiple instances? Why does selecting a subset work when I do the copy but not when I copy all. If I am passing the data to write to the clipboard, why does selecting a subset and the copying only that subset work but the copy all does not? I do not understand how LabVIEW handles multiple instances and is they are truly considered separate processes.

 

I seldom use these forums as I can get most of the code that I write to work as expected. Thank you for all of your help and suggestions.

0 Kudos
Message 8 of 11
(3,964 Views)

Additional Images:

Download All
0 Kudos
Message 9 of 11
(3,962 Views)

Thanks for your help.

 

The NI (National Instruments) software works correctly. The problem revolved around the developers of the software, for the unit under test, not initializing all of the ports exactly the same. They gave me some excuse for doing that which I just ignored. Anyway, the ports with the problem would transmit one or two NULL bytes when the unit had power applied because they were not initialized the same as the ports that worked, if at all. I ended up putting a filter in my code to analyzed the string replacing any NULLs with an asterisk. That resolved the issue.

 

Message 10 of 11
(3,912 Views)