Edit LabVIEW Table in a separate Excel-like Editor

[ReneW]

I suggest that NI should spend a separate Excel-like editor to edit the Tables in LabVIEW.

There are many proposals how to improve the LabVIEW-Table and its editing.

I recommend to stop thinking about improvements and add a separate Excel-like Editor instead.

This Editor could be used to enter, manipulate copy and paste table data. Perhaps more functions like loading data from a file could be added and integrated.

It should be accessible in the editing and running mode.

It should be possible to use it for controls and for constants.

It should be accessible by selecting a corresponding entry in the pull-up context menu (right mouse click).

I hope that this is not another duplicate to this table editing problem

[GriffinRU]

You can use Excel spreadsheet inside your front panel, you can even link it to document...

By the way in provided example you calling LabVIEW Array control a Table which is incorrect, array can be multi-dimensional while table just 2D.

-Artur

[smercurio_fc]

I would not support this idea, but it's not because it's a bad idea in general. The reason I wouldn't support it is that the array control is not a control that should normally be used on a user interface. It's a control that's really designed to be used in subVIs. The array control does not have the "finesse" that a user would require. You're better off using a control that's specifically designed to be more palatable to a user. The listbox control comes to mind as a control better suited for a user interface.

By the way, the Excel spreadsheet control that Griffin is referring to is probably the spreadsheet control from the Microsoft Office Web Components. This is NOT an Excel workbook control. It's a completely different beast. It does not read/write Excel workbooks. In order to have an Excel workbook on a front panel you'd need to open it inside of a web browser control.

[ReneW]

I usually use 1D or 2D arrays. But I see that an excel-like table would interfere with arrays >2D.

I miss a simple tool to enter and edit data into tables during the developing and debugging of my VIs. Because of this, I thought that a simple additional editor would help for debugging purposes. I agree that the LabVIEW arrays should be used for sub VIs and not for the user interface. But it was ment as a easy way to enter certain amount of data into a constant or a control.

Perhaps, there are better Ideas how to fill in data into arrays. It should be considered that it is although very annoying to enter data in arrays of clusters. I still hope that somebody will find a solution how to enter and read out data to and from arrays and arrays of clusters more easily.

[GriffinRU]

To: smercurio_fc:

Don't mix worksheet and workbook, to do what he is asking worksheet is sufficiat any you can implement it any way you like, link, direct, indirect...

To ReneW:

Fill LabVIEW arrays with file read function, i.e. paste data in text file and read in LabVIEW. crude but quick.

-Artur

[smercurio_fc]

---

GriffinRU wrote:

To: smercurio_fc:

Don't mix worksheet and workbook, to do what he is asking worksheet is sufficiat any you can implement it any way you like, link, direct, indirect..

---

I am not mixing worksheet and workbook. People use the term "spreadsheet" quite loosely. I chose my words quite carefully and explicitly. There is no Excel ActiveX control, and hence you cannot put an Excel "spreadsheet" directly on a LabVIEW front panel, or any other window for that matter. You could if you used a web browser ActiveX control on a LabVIEW front panel (as I noted). The Office Web Components Spreadsheet control (if that is what you were referring to) is a special type of control and has (as I noted) NOTHING to do with Excel. If that is not what you are referring to, then please enlighten us as to how you can "use Excel spreadsheet inside your front panel, you can even link it to document".

[GriffinRU]

Let's be clear here:

Things we can do programmatically:

Use Excel.exe as user interface and communicate with it over ActiveX interface and update LabVIEW controls as you wish.

Things we can do while programming or leaning how to use LabVIEW or just to simplify:

• Insert ActiveX Object ->create document -> Microsoft Office Excel WorkSheet  
• Right Click -> Document -> Edit -> manipulate in native Excel interface -> done ->close ->back into LabVIEW

All the rest is however you would like to make your user interface be and how hard you would like to program.

P.S. Back then, when LabVIEW 6i was in its grace, there was an ActiveX Excel control (probably web, not sure) which you could place on LabVIEW FP and play as if you are in Excel. I used in the past, but switch to Excel directly due to higher overhead...

Again, That was back then and not what I was offering.

[smercurio_fc]

---

@GriffinRU wrote:

Let's be clear here:

Things we can do programmatically:

Use Excel.exe as user interface and communicate with it over ActiveX interface and update LabVIEW controls as you wish.

Things we can do while programming or leaning how to use LabVIEW or just to simplify:

• Insert ActiveX Object ->create document -> Microsoft Office Excel WorkSheet  
• Right Click -> Document -> Edit -> manipulate in native Excel interface -> done ->close ->back into LabVIEW

All the rest is however you would like to make your user interface be and how hard you would like to program.

---

That's all well and good. One problem. What if you don't have Excel? The user is asking for something that would not require Excel.

Also, the user is not asking for something you can do "programmatically", or require you to jump in and out of Excel.

Another problem: ActiveX doesn't exist on Macs or Linux machines. LabVIEW is supposed to be cross-platform and hence would require a completely native solution, not something that relies on ActiveX.

---

@GriffinRU wrote:

P.S. Back then, when LabVIEW 6i was in its grace, there was an ActiveX Excel control (probably web, not sure)

---

That was the Spreadsheet Web Component that I've been talking about. It was not an Excel ActiveX control, and never had anything to do with Excel. It did not read/write Excel.

[donkdonk]

---

smercurio_fc wrote:

[...]array control is not a control that should normally be used on a user interface[..]

---

I think this depends on the type of LabVIEW developer: you are either a programmer that has to deliver a formal software package, or an engineer that performs measurements in the lab and -by nature of the experiments- changes the software multiple times a week or even a day. An engineer is likely to work in the edit environment and may almost never create an executable.

To me this idea makes clear that editing arrays in LabVIEW is not an easy task. As I understand it, ReneW just wants to be able to edit arrays (or tables?) as easy as a spreadsheet (excel being mentioned because everybody is familiar with it).

I fully agree that editing arrays in LabVIEW should be made easier, so kudoos.

A further general note: often I see people propose a workaround for the idea. That is good if you need a solution on short notice, but in general it should not be presented as the idea being unnecessary. Unless of course it requires less mouseclicks than the proposed idea 

[GriffinRU]

To: smercurio_fc:

"Another problem: ActiveX doesn't exist on Macs or Linux machines. LabVIEW is supposed to be cross-platform and hence would require a completely native solution, not something that relies on ActiveX."

Macs or Linux machines must have other wonderful tools for spreadsheets, so build a bridge from them to LabVIEW array, I won't recommend to overload LabVIEW controls. (Maybe as XControl in this case would help, build it if you need it or wait for solution from NI 🙂 )

Bottom line, use the tools you most familiar and comfortable with and then pass data to LabVIEW, do not re-create interface which is already done or has tons of support and well documented.

To: donkdonk:

"I think this depends on the type of LabVIEW developer: you are either a programmer that has to deliver a formal software package, or an engineer that performs measurements in the lab and -by nature of the experiments- changes the software multiple times a week or even a day. An engineer is likely to work in the edit environment and may almost never create an executable."

If you are an engineer(same apply for developer) and performing similar task over and over it is time to build a fixture and improve your efficiency, maybe I am different engineer but executable for me is a fixture which I am using a lot and it is proven and has most bugs fixed or identified. Now your program (executable) can be built with ability to expand or not that is where one engineer differ from another, i.e. one would have a Swiss-army knife another would have multi-thousand tools tool-box and third one would have hammer and chisel 🙂

-Artur

[Ray.R]

Rene,

Are you proposing something that "looks" like the Excel Spreadsheet?  Like a table with more of an Excel "feel"?

As for changing the 2D array, I agree with smercurio.  NO.  That's not the intented use of an array.

If you are proposing a new control, then that is different.

Interfacing Excel?  Again, I agree with smercurio for the reasons he stated and for other reasons.  (I don't want to hijack this thread for long political discussions)