Build name conflicts (NI Report Generation Toolkit)

[Darren]

Hey everybody,

Sorry I'm a couple of months late to the RGT bashing party. 🙂 I had not seen this thread until today.  I took over ownership of the Report Generation Toolkit late in the release cycle for version 1.1 back in early 2004.  I was the primary developer for versions 1.1.1 and 1.1.2.  I will also be the primary developer for the next release.  I was not the developer for the 1.1.3 release that accompanied LabVIEW 8.6, but I was very much involved in the early design and brainstorming.  I'd like to explain why we made some of the choices that we did.

As you may know, the LabVIEW 8.6 release centered around the Platform DVD, which was NI's way of unifying LabVIEW, its modules, and its toolkits, all under one installer.  The advent of the Platform DVD meant that the 8.6 release, and all future releases, would include updates for each and every module and toolkit.  It also meant that all products that fall under the Platform DVD umbrella would now be licensed, which gave LabVIEW users the benefit of being able to install and run any module or toolkit with a 30-day evaluation period.  So at this point, understand that it was a 100% requirement that the Report Generation Toolkit become licensed under 8.6.

Now, a peculiar thing about the Report Generation Toolkit prior to 1.1.3...it was the only LabVIEW toolkit that actually *replaced* files on disk when you installed it.  Specifically, it replaced vi.lib\utility\nireport.llb, several LLBs in the vi.lib\printing folder, several .mnu files in the menus folder, a .chm or two in the help folder, etc.  All of these replaced files had added functionality to support generating Word and Excel reports.  If you uninstalled the toolkit, we would replace the files with the original core LabVIEW files.

Unfortunately, this design was completely incompatible with the way licensing works.  In order for VIs and palettes to check license status, the VIs and .mnu files in question must be part of a licensed library.  There was no way we could continue to overwrite files on disk (and remove/replace them on an uninstall).  That would require us overwriting the files when you install the toolkit, but if you're doing an eval, and you didn't activate after 30 days, we'd have to somehow revert back to the old files...but if you then activated at a later date, we'd have to replace the files again.  There's nothing in our licensing scheme that even remotely supports this behavior.  And since RGT was the only toolkit that fell into this category, we decided the best idea was a redesign of the toolkit, and the Report Generation API in LabVIEW, to support a plug-in architecture where we could install new files alongside the core Report Gen VIs to add the Word and Excel functionality, without changing anything in the core VIs (which support Standard and HTML reports).

So looking at an API that was refnum-based and needed the possible dynamic creation of report types (i.e. sometimes you may have the Word and Excel stuff installed, but sometimes not), we decided to go with LabVIEW Classes.  Obviously there are pros and cons to this approach...the biggest con, as we have seen in this discussion thread, was the creation of folders of support VIs next to the EXE when building an executable.  I'll be honest, we did consider this scenario while brainstorming the redesign, but since the issue of building same-named VIs into an EXE already existed prior to the toolkit (since it can happen with standard .lvlibs), and since we knew we had no choice but to go ahead with the redesign, we stuck with the LV Classes approach.

All this being said, we did not anticipate it being as big a problem as all of you (and even some internal LabVIEW users at NI) have indicated.  And for my part in the decision-making, I apologize for that.  I will reiterate a previous point made in this thread, which is that we are actively investigating ways to solve the "extra files next to the EXE" problem in a future LabVIEW version, not just for RGT, but for any app that has same-named VIs.

So now that I own the toolkit again, I'm happy to take suggestions on things y'all would like to see "fixed" in the next release.  And let's assume that the architecture will continue to be class-based, and that we are already trying to solve the extra files with the EXE issue.  What other major problems have y'all had with this most recent release of the toolkit that you would like to see addressed?

-D

[Herbert]

Hi Darren,

since you ask for suggestions, I would like to place my wish of transferring numbers in binary format to Excel, as I described in

Writing double precision to Excel

It would be a really small modification and make my life much easier. In addition, the customer gets the numbers in their original precision without any truncation.

Thank's

Herbert

[billings11]

Darren,

It's great that you posted.  But there is only one solution.  The only way to fix the toolkit is to redesign it without LVOOP.  That is the ONLY adequate solution.  Think about it... there is no other way.

Besides, what is the benefit of using LVOOP in the toolkit anyway?  There's nothing it is allowing you to do that you couldn't do with normal vi's.  So its simply not worth the headache!  Sit down and list the pros and cons of LVOOP in the toolkit.  Lots of us could have told you the cons... what are the pros?

And remember, it's not just that the support vi's get packaged next to the exe, it's the fact that the entire report gerenation toolkit is going to get packaged  with every exe now!  I'm adding every single method vi from the toolkit to the build instead of just the four or five vi's I'm actually using.

And the packaging problems with LVOOP that NI is "working on solving" have been in two releases since 8.2 now and remains unfixed, so don't hold your breath.

Message Edited by billings11 on 02-02-2009 05:52 AM

[Darren]

Hi Herbert,

We already have CAR# 130447 filed against the toolkit regarding the numeric vs. string data being passed to Excel.  I have added a link to your forum post to the CAR so I can investigate the way you solved the problem.  I will look into adding this functionality in a future version of the toolkit.

I appreciate any other suggestions you may have, again making the assumptions that I stated in my previous reply.

-D

[Joe_H]

Darren,

I am glad you are taking this back over. I have had some major issues with the RGT. One of those issues can be found here. Let me explain a little more in detail about what I had to do to get it fixed.

1. The EXE that I was building was a user interface for TestStand.
2. I built the UI in LV and also built it into an EXE with LV.
3. Then I included the EXE in the build of TestStand so that I could create 1 installer for everything just like all the documentation states that you can.

The problem with doing it this way is that the TS builder would not build anything because of the name conflicts and such with the RGT. Finally what i had to end up doing was.

1. Take the UI EXE out of the build process for TS.
2. Build an installer with LV that only installs the UI EXE.
3. Build an installer with TS that at the end of the install for the TS stuff it would then run the installer for the UI EXE.

Now, all of this works great but it cost me and NI AE's a lot of time and effort to get this figured out. I even had a person by the of Jeffrey Phillips from NI come over and see if he could understand why we could not get it to build the way that it was supoosed to. There were many NI AE's that helped me out from the LV side and the teststand side and this was the only way that we could get it to work.

So I hope the next generation of the RGT will be tested with the build process of TS in the manner that the TS documentation describes and that it will be backwards compatible also.

Everything works just like it is supposed to when I do not use the RGT that is LVOOP based.

I guess a real good way to fix the problem is to go back to the "OLD WAY" and just make the RGT a part of LV and not an add on toolkit that needs a license anymore. Seems to me that all of the time spent to work out all of the "BUGS" and keeping the users happy would far outway the cost of the toolkit.

just my 2 cents worth.

you are welcome to call me if you have any questions or if you want me to test out any of the "FIXES" on our test machine.

[Darren]

Hi Joe,

Thanks for the response.  I'm thinking that the investigations we're doing to avoid having the folders of support VIs next to the EXE would effectively solve this problem, since you would no longer have name conflicts for files if those files aren't there anymore.  I'll talk to the TestStand guys to make sure we're covering our bases here.

Also, have you applied for the LabVIEW 2009 beta yet?  At some point during the beta you'll probably be able to try out some new and updated functionality in LabVIEW and RGT to see if the TestStand/LabVIEW EXE issue is resolved.   Make sure that any discussions you'd like to have regarding this are started in the beta forum and not here.

-D

[Joe_H]

I have applied as I always do for LV betas but I have not heard anything back as of yet. I will check the functionality but it is NI's job to really make sure that this works not mine. I have already put in 4 Mnths of my time trying to get the TS installer to build correctly with this issue and I think that is enough. When I get the Beta and try it I will start a discussion on the beta forum.

Thanks Darren. We know it is not your fault that it turned out the way that it did. We just hate it when NI changes something and does not fully test it with all of their products that they claim it will work with, ie LV and TS do not always play nice together.

[billings11]

I feel your pain Joe.  Stay strong.

[Herbert]

Hi Darren,

since I already revised the VI's, I might as well publish my solution. Find attached, how I managed to make Excel "eat" binary numbers, as well as how I dealt with the RGT-Class-VI's.

It is clear that the VI "Append Numeric Table to ReportH.vi" is broken, because of the Class-conflict. However, all inside it should be correct, since it works (tested on about 5 different machines).

To repeat again: I really appreciate NI protecting as few code as possible:

     First, I do learn from the code presented.

     Second, nobody is perfect and thus, bugs are always present - bugs that might be corrected by the user itself on the fly instead of waiting for an upgrade.

     Third, no tool covers all the wishes of its customers. Keeping software as open as possible gives us more flexibility to adapt the tools to our specific needs.

Please, throw such arguments - important to me and probably to many other users - into discussion when it comes to decide, how to protect NI's intellectual property. There will never come up "the" solution, but hopefully a good compromize.

Herbert

[AEI_JR]

After running into these issues, and reading through the nightmares in this thread, I guess I'll just save my VI for version 8.5 and uninstall LV 8.6.1 and RGT 1.1.3, going back to all previous versions.  I'm sure it will be a headache, but I have time constraints to get applications done that can't wait months for NI to catch up with solutions.  Work arounds are no good; I need concrete fixes when deploying systems to the field.