Modifying a built-in LabVIEW library

[callanb]

Hi everyone,

I've run into a problem with being able to set column widths for reports through Append Numeric Table to Report.vi and have come across a few posts about how to solve that problem, but it involves modifying a subvi deeper down, NI_ReportGenerationCore.lvlib:Set Table Column Widths.vi.

I'm doing development with another programmer, and I'm worried that the project won't run after I've made the changes.

Can I do something like make a new copy of that library that will remain seperate? Or is there some other way around this problem I don't know about?

[JÞB]

as a rule of thumb- don't edit code supplied with the IDE.   First something you aren't using now may DEPEND on that function and you just broke it.  Second when you get your next maintenance dvd the "fix" may change.  Third- how do you deploy this fix without breaking someone elses code? Forth, the developer who wrote the code you just inadvertantly broke may lose all of their hair debugging a vi.lib function and may be armed when they next see you!

however, there is nothing stopping you from copiing the library to a new location with a new name (and new names for the vi's in the library)  Now its user code and noone will hunt you down for breaking their code!

[callanb]

Thanks for the info.

So, if I wanted to make a new copy that I could mess around with, is there an easy or thorough way I could make a copy of all the sub VIs? Do I need to make a new copy of the library or...?

[Ben]

I concur with all that Jeff wrote right up till you start talking about the new add-ons taht have been converted to LVOOP.

To modifiy those you will have to have the password to change the Class library ... "sad panda".

For those you have to work with what Ni gave us or re-write them ourselves.

now to the Report Toolkit.

NI has added methods that expose the references you need to get at those properties yourself. I suspect you found those threads that discussed the isue when originally found. If your install does not have the methods to get at the refs then you should get a new version that does allow you to mod the fucntioality.

I hope that clicks for you.

If others have figured out how to mod those LVOOP add-ons from NI sans passwords, I am all ears.

Ben

[Coq_Rouge]

---

@Jeff Bohrer wrote:

as a rule of thumb- don't edit code supplied with the IDE.  

---

I do not quite agree in this. The Labview functions are not some holy grail never to be touched. But you should always work on a copy of the IDE code, and store it in a folder separated from the IDE code. You must also come up with some sort of naming convention, so the code do not get mixed, and the same goes for the icons. I often use a screaming yellow color as fill on the icons that I mod. So I easy can recognize a mod VI. This may be some job. But it can be worth the effort.

[Mark_Yedinak]

---

@COq Rouge wrote:

---

@Jeff Bohrer wrote:

as a rule of thumb- don't edit code supplied with the IDE.  

---

I do not quite agree in this. The Labview functions are not some holy grail never to be touched. But you should always work on a copy of the IDE code, and store it in a folder separated from the IDE code. You must also come up with some sort of naming convention, so the code do not get mixed, and the same goes for the icons. I often use a screaming yellow color as fill on the icons that I mod. So I easy can recognize a mod VI. This may be some job. But it can be worth the effort.

---

I think Jeff was saying the same thing as you. His point was that you shuold never modify the code located in the IDE's environment itself because it is likely that the code can be changed during an upgrade. At the end of Jeff's post he clearly stated it is OK to copy the code and modify it. The moral of the story here is if you modify the library code itself don't be surprised if your modifications are undone on your next LabVIEW upgrade.

[callanb]

Thanks for everyone's input.

Ben, I'm specifically talking about the regular print-to-printer report generation, not the Microsoft toolkit. I haven't been able to find any solutions, just more complaints like this one:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Report-Table-Multiple-Column-Widths/idi-p/1266906

At this point I need to be able to specific different column widths and different cell font colors. Seems like the only way to accomplish this is to modify IDE code.

[Ben]

---

@callanb wrote:

Thanks for everyone's input.

Ben, I'm specifically talking about the regular print-to-printer report generation, not the Microsoft toolkit. I haven't been able to find any solutions, just more complaints like this one:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Report-Table-Multiple-Column-Widths/idi-p/1266906

At this point I need to be able to specific different column widths and different cell font colors. Seems like the only way to accomplish this is to modify IDE code.

---

Still sounds like what I was talking about. The early versions did not expose the refs and a fix was latter released tht did expose the refs you need to apply your own setting.

Sorry if this is a distraction,

Ben

[callanb]

Well if you don't mind to take a second to help understand more.. 

I'm looking at "Append Table to Report.vi" right now, as it is implemented in Text Report.vi in the examples. There is a single double type input for column width, that gets applied to all columns.

I don't see how I can get around that limitation? 

edit: Labview 2010 is what I'm using.

[Ben]

I don't mind but my boss does.

As it stands now you have to give up on this desire, hack the code OR call NI and log a service request. The App Engineer should be able to find the issue in the KB and get tell you if "Ben is full of it" or get you pointed the right direction.

I am allowed to answer questions but doing real work (with a PO in place) is "right out".

Ben