Need custom column widths in Append Text Table to Report

Question

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.lvlibet Table Column Width

Answer 1

There is a highly relevant thread under discussion here:
http://forums.ni.com/ni/board/message?board.id=fea​tures&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.