LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Need custom column widths in Append Text Table to Report

I need to print reports with tables of different column widths specified for each column, as the contained fields vary in width from just 3 characters in one column to 40 characters in another.  Also we are trying to match the reports generated by a non-labview routine.  In the past I have been able to achieve this by editing the Append Table to Report vi, working my way through the inner hierarchy to replace the DBL numeric COLUMN WIDTH control with a DBL numeric array.  The innermost vi, Set Table Column Width, assigns the numeric to a property node in a for loop, so the change is simple: replace the scalor with an array and enable indexing on the for loop.  Of course, after each Labview upgrade, I've had to go back in and repeat these edits on the overwritten upgraded vi's.  This time there is a problem.  The new version of this toolkit is object oriented, and disturbing these vi's wrecks the class methods in a way I don't understand (mostly because I've had no dealings with object oriented programming) and which cannot be undone.  I recently tried this and after not being able to fix the problem even with phone support, I had to spend the next two days unistalling and reinstalling Labview!  I desperately need a way to achieve this functionality without killing the toolkit, which is used (in its original functionality) by another absolutely critical program.  PLEASE HELP!

 

The hierarchy is as follows:

NI report.lvclass:Append Table to Report (wrap)

NI report.lvclass:Append Table to Report 

NI Standard report.lvclass:Append Text Table to Report

NI Standard report.lvclass:tables

NI Report Generation Core.lvlib:Set Table Column Width

0 Kudos
Message 1 of 13
(5,021 Views)

Hi Rob,

 

I'm working on the best way to change the current version of your toolkit for this application.  In the mean time, if you have the old disks with the older versions of the Report Gen Toolkit, or you have the older VIs modified already, you can follow these directions to install the toolkit to newer versions of LabVIEW.  While you'll have multiple copies of the same toolkit, it should allow you to easily modify the VIs and not worry about messing up the class structure:

 

http://digital.ni.com/public.nsf/allkb/58BE852CB35237C786256A290079DF39?OpenDocument 

0 Kudos
Message 2 of 13
(4,975 Views)
Thanks Kyle, I won't need the multi-column solution immediately, so I'd rather do it the moving-forward way rather than working on it twice.  One thing I should mention is I made the vi polymorphic so the datatype could still be a scalor for other applications. 
0 Kudos
Message 3 of 13
(4,968 Views)

Hi Rob,

 

Modifying the toolkit directly is proving to be much more difficult than I initially anticipated.  Are you making Excel-only reports?  It may just be easier to create a VI that changes the column widths than rewriting the VIs.  We could then permanently add this VI to your palette for future applications.

Message Edited by Smootastic on 04-15-2010 12:51 PM
0 Kudos
Message 4 of 13
(4,944 Views)
No these are printed reports, standard style.  I guess I'm not impressed with how helpful object oriented programming is in Labview.  This really shouldn't be so difficult, as I said I've done this numerous times for the previous toolkits in just a minute each time.  Why is this so cumbersome?
0 Kudos
Message 5 of 13
(4,939 Views)

Hi Rob,

 

Overall, this is functionality that is not supported, and it looks like you have two possibilities to get this working: One is if you can figure out how to get the object oriented coding to work with the newest version of the toolkit, but as you said, this is not straightforward and can cause trouble unless you are very familiar with object oriented programming. The other option is to use an older version of the toolkit, and modify that to do what you need.

 

Regards,

Stephen S.

National Instruments
Applications Engineering
0 Kudos
Message 6 of 13
(4,923 Views)
Is that to say NI will not be helping me with this?  Pretty disappointing lack of support, seems like a terrible idea to go to object oriented if even your own application engineers can't figure out such a simple fix.  Gotta give NI a huge thumbs down on this one, thanks for nothing.
0 Kudos
Message 7 of 13
(4,918 Views)

Hello Rob,

 

As you already know changing the underlying code of toolkits can be dangerous because NI doesn't guarantee that we won't change the underline architecture.  We do maintain that we will keep the external API (palette vis) compatible between versions.

 

That being said we did find that many of our users wanted to make slight modifications to our RGT because it was all ActiveX based.  In LabVIEW 2009 we introduced Excel get ActiveX References.vi and Word get ActiveX References.vi.  What these VIs do is return the ActiveX references so that the user can do any modification that they want.  Use these VIs in conjuntion with any ActiveX property and method you wish.  This is the recommended way to achieve functionality that is not included in the toolkit.

Regards,

Jon S.
National Instruments
LabVIEW NXG Product Owner
0 Kudos
Message 8 of 13
(4,891 Views)

There is a highly relevant thread under discussion here:
http://forums.ni.com/ni/board/message?board.id=features&thread.id=429

You may wish to read it and chime in as it is a discussion of LabVIEW's policy (and possible change in policy for the future) concerning the handling of non-palette VIs between LV versions.

Rob Hingle wrote:
> Is that to say NI will not be helping me with this?  Pretty disappointing lack of support, seems
> like a terrible idea to go to object oriented if even your own application engineers can't figure
> out such a simple fix.  Gotta give NI a huge thumbs down on this one, thanks for nothing.

I doubt that it is a simple fix -- our AEs are generally top notch at figuring out solutions for customers -- if it were simple, my bet is they'd have solved it. Asking an AE to work around a bug is different from asking them to rearchitect the toolkit. You are asking them to add a feature that the new version of the toolkit is not designed to support. The difficulty in doing this is completely independent of the decision to use LabVIEW classes to implement the toolkit. If any piece of software is not designed with a particular use case in mind, what may be a simple tweak under one design may become a very hard problem under another design.

 

In your case, the solution is very straightforward: Use the older version of the toolkit. Any time you create a custom modification of the VIs that ship with LV or one of its toolkits, you should make your own copy and have your VIs link against the copy. LabVIEW promises to maintain all the public functionality version over version. Usually we succeed at that. What we do not promise is to maintain our private implementation of that functionality. It is impossible for LabVIEW (or any other software library) to maintain all of its private internal operations while still continuing any development. Using a copy of the original VIs shields you from having to recode your changes every version (something you've already mentioned is a chore) and it guarantees that functionality that you relie upon does not disappear.

 

I hope you are willing to be understanding of this situation and not hold it against the AEs working on this. They try hard to provide excellent customer service, and spend lots of time inventing custom solutions for our users.  This happens to be a situation where the correct fix is not to modify the new toolkit version to do something it wasn't designed to do but to modify your development process so that the problem is solved now and into the future. 

0 Kudos
Message 9 of 13
(4,802 Views)
Thank you Aristos, I must say looking at things this way has lessened my frustration with NI, but regardless there is another philosophy at play here.  When you say this is not a trivial fix, you are only part right - it USED to be a trivial fix, but now you've complicated the toolkit to the point that even your own engineers can't edit it.  So while it is a valid point that NI cannot be responsible for lower level vi's for the sake of free development, NI SHOULD be responsible for maintaining architecture flexible enough to ALLOW editing.  Think if I had started with the current version of the toolkit, I would be completely incapable of achieving my modest goal because the latest methods are so rigid that the slightest editing destroys the entire toolkit to the point of needing to spend 24+ hours reinstalling Labview!  I urge the developers at NI to avoid these sorts of "improvements" in other toolkits, or they will all be completely useless for anything other than the handful of cookie-cutter applications for which they were designed.
0 Kudos
Message 10 of 13
(4,789 Views)