From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Copy to Clipboard Method (Table) copies one additional empty column more than expected

Solved!
Go to solution

Hi,

 

I'm using the Copy to Clipboard Method for a Table, to copy for example 4 rows with 3 columns. When I paste it to Excel I get 4 rows with 3 columns and an extra column, which is empty so the real size is than 4x4.

 

Is this a Labview Error or can someone explain it to me why this is happening? Or even better, how can I fix that?

 

I have isolated the problem to an extra vi so you can reproduce the error. Just let the vi run once and then paste the clipboard to Microsoft Excel.

 

My Labview Version is 11.0 32 Bit, Microsoft Office 2010, WinXP SP3

 

Regards


Marcel

 

 

0 Kudos
Message 1 of 6
(4,700 Views)

It looks like Export Data to Clipboard throws an extra tab after the last entry in the row.

The Help File doesn't really describe the format so I'm not sure if I'd call it a bug.

 

Looks like the same behavior if you use an array instead of a table.

 

You could use an Application Invoke node and the Write to Clipboard method to write whatever string you wanted.

 

 

0 Kudos
Message 2 of 6
(4,691 Views)
Solution
Accepted by topic author Marcel_C

Snippets apparently hate property and invoke nodes.

 

See attached vi for proposed workaround using the Clipboard.Write method.

Message 3 of 6
(4,686 Views)

Hi,

 

the workaround is 'working'.

 

Thanks for your fast response

 

/Marcel

 

Edit:// But it is still interesting for me if it is a Bug or not. Maybe someone from NI could make a statemant to this Issue.

0 Kudos
Message 4 of 6
(4,668 Views)

Hi Marcel,

 

as far as i know there was a change in the ActiveX interface from Office 2007 to Office 2010.

This problem occurs often in Exel 2010. In Exel 2007 you wouldn't have this bug.

 

regards,

Michael F.

0 Kudos
Message 5 of 6
(4,659 Views)

My vote: It is a bug.

 

There is no need for the additional tab at the end of the line. The end-of-the-line sign is the final separator of the row. I cannot think of a situation, where an additional delimiter would be needed on all rows. But as we see here, some programs are mislead by that sign.

 

The change in Excel (between the versions) is likely a bug-fix: After each separator a value is awaited. If that value is missing, zero or empty string is substituted. Imaging multiple (tab) separators following each other in a sparse matrix.

 

LibreOffice Calc 4.0 does not give me a choice to interpret the last column, though...

 

Cheers,

Message 6 of 6
(4,472 Views)