04-09-2010 10:04 AM
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
04-12-2010 06:20 PM
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
04-12-2010 06:50 PM
04-15-2010 12:50 PM - edited 04-15-2010 12:51 PM
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.
04-15-2010 12:55 PM
04-16-2010 10:59 AM
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.
04-16-2010 12:01 PM
04-16-2010 03:39 PM
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.
04-22-2010 01:55 PM
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.
04-22-2010 02:30 PM