Build name conflicts (NI Report Generation Toolkit)

[Adam_H]

Hi All,

So I have been doing a little more digging into what is happening.  It appears to have to do with the some of the classes being locked.  It seems that in some cases the classes are locked and in others they are not.  I believe this is the root of the problem that we are seeing here.

[Joe_H]

HI all,

Great discussion. I absolutely hate the new report generation toolkit. It has broke every project for us and caused us much pain. Just so that you all know, the new report generation toolkit also breaks the build for teststand. If you use the report generation toolkit in a VI and use that VI with testand and you want to build a deployment you cannot do it.

See here for details

In my opinion NI needs to pull the product and go back to old report generation toolkit and do a lot more testing before they try to release it again. We pay way too much money for NI products to have to jump through so many hoops just because they want to "upgrade".  upgrades are usually good but this an upgrade gone wrong. Especially since they took the most generic toolkit and made it worthless.

We don't want it, Make the old report gen toolkit usable for LV 8.6

Message Edited by Jhoskins on 11-10-2008 12:46 PM

[Andrey_Dmitriev]

Colleagues,

After some experiments I was able to get application running while Report Generation Toolkit classes stored to the separate LLB.

The problem was with New Report.vi (where some paths was hard-coded). I have just replaced New Report.vi call with direct call of the appropriate SubVI for Excel and Word reports, and it works.

Now I have application and six llb instead of 100+ plain SubVIs.

In additional, no any naming conflicts occurred during build.

See attachment with example and build specs for details (LabVIEW 8.6)

Best regards, 

Andrey.

[billings11]

We have complained about build behavior of LVOOP since 8.2.  NI keeps saying "We're looking into it."  There has always been this pathetic problem of massive amounts of support vi's going into the exe directory if you use clases.  Ni has been looking into it for 2 years now.  Don't expect any real solution any time soon.  Every experienced developer knew it would be a disaster to use LVOOP in a toolkit.  This means if you want to use a single vi from the toolkit, like New Report.vi, just to maybe open an excel report, you have to package the entire LVOOP heirarchy.  Hundreds of extra vi's to use one.  And I've never built an LVOOP project without tons of problems.  None of this should come as a suprise to NI.

My question is, every developer I know who has tried LVOOP knew this report generation toolkit would be a disaster.  Why didn't NI?

I have used every labview release since 4.0 for large scale development, and there are 2 recent usable releases for long term development.  7.1.1 and 8.5.1 are the only two releases that I would qualify as ok to use for real application development.  Actually 8.5.1 may be the last release you'll ever need, because I don't see NI doing much to improve upon it.  My advice is to back off of 8.6 and stay with 8.5.1.  You can use the old report generation toolkit. 

[Andrey_Dmitriev]

>My question is, every developer I know who has tried LVOOP knew this report generation toolkit would be a disaster.  Why didn't NI?

I guess, NI uses DIADEM for report generation. 😉

Probably in a future Report Generation Toolkit will disappear. Same as State Diagram Toolkit (was just included into Dev Suite) was discontinued and replaced in LabVIEW 8.x with Statechart Module (which is included into Dev Suite as trial and required separate license, which is pretty expencive).

Andrey.

[Joe_H]

I just wish that they would give us the option of using LVOOP if we want to and not force it on us by upgrading toolkits to it. I am seriouslpy considering not upgrading anymore just because something "New and improved" comes out. I want something stable and that works, not new and improved.

just my 2 cents

[Hillman]

Hi All,

I hope your all well this evening.

I have been in this feed from the start, and I've since contact some of the premier engineers in the States Team after reading a fair number of comments asking for answers and work arounds etc. I felt the best I could do was to try and get some answers. So I just wanted to share the information I got,

"

We needed to re-architect the report generation toolkit to make some substantial changes in the way it worked due to licensing as well as bug fixes and feature improvements.  The old toolkit had a couple major problems, and due to us wanting to add features we decided to implement the toolkit with LabVIEW Classes.  It also makes the most sense to implement the reports interface with an object-oriented design as the notion of having different types of reports (regular report, html, Word, Excel, etc...) each with some shared basic functionality, and some differing functionality.  LabVIEW Classes are becoming more and more common in LabVIEW programs, and while still new, the feature is pretty stable.  We considered writing the toolkit with polymorphic VIs, but it was not possible given some limitations on polymorphic VIs.  We did testing on the toolkit and didn't find any major issues.

We have heard a few reports of some of the issues with the toolkit including the inability to directly get report references, and the extra files that are generated when building a LabVIEW executable using report generation toolkit VIs.  In most of these cases there are workarounds, but it looks like our recommended solution of merging the conflicting files into an LLB/DLL doesn't work when one of the classes is locked.

 ....

The specifying a DLL (which is really an LLB) to build the conflicting files into is the workaround.  If a class is locked it is probably due to being loaded in multiple application instances, so I would recommend restarting LabVIEW, open the project and then build the executable.  If that doesn't work then we need more information, because we have tested this workaround and have not had this problem with it.

"

Have you guys managed to work out the cause of the locking?

In regarding to the wish of having a choice between LVOOP and not is obviously not the direction R&D are looking at. One can only feel, that with the wealth of knowledge of these too issues that over time the LVOOP will become more settled into the toolkits. However, Like you say, with LVOOP you will forever have to include extra vi's.

Well I hope this gives you guys some more information... Im sorry I cant really make things happen.

Kind Regards,
James.

[Joe_H]

My only problem is that LVOOP does not work with Teststand if you want to do a teststand deployment. You can get it to work if you jump throough a bunch of hoops and workarounds. But as a customer I should not have to do that. LV is a very expensive software package and I think that it should work out of the box. I should not have to do anything put program. I should not have to stand on one leg and hold my tongue just right just to get some things to work. I had one of the top LabVIEW application engineers in my office just a week or so ago and he could not get it to work like it was supposed to. So if one if the top engineers for LV cannot get it to work then how can NI expect just the average LV programmer to get it to work. I am actually getting tired of LV being so "Buggy" and having to call technical support on almost a daily basis when a new version comes out. I absolutely hate the fact that LVOOP bloats an EXE so much that nobody wants to install your program because of it. I wish that NI would seriously reconsider using LVOOP on toolkits. OH and just to point out the fact that it is not only the report generation toolkit, it the standard report VI'S that ship with LV that are the problem too. I guess because they are LVOOP also.

LVOOP is also very cumbersome to use in VI that will go into a Teststand build because of the locking issue. It really does suck to have to be forced to use something that simply does not work or something that works in some ways but not in others. If it is a product that NI sells to go with NI products then it should just simply work flawlessly together just like it did in the past.

OK I'm done ranting now and I need to get back to learning C++ since that looks like the way that our company wants to go now. I do not want to stop using LV but if NO does not get it back to stable shape that it was in then I will be "FORCED" to.

[billings11]

"We did testing on the toolkit and didn't find any major issues."

A.  You didn't do enough testing.

2.  You didn't look for the right issues.

I think the real answer is for us developers to come up with an open source toolkit so no one ever has to buy the NI one.

[Herbert]

Hi all,

I just ran into the problems you are discussing and got as angry with NI as everybody here. Concerning "We did testing on the toolkit and didn't find any major issues" it looks like "they don't eat there own food": If any of the NI-developers would have to deliver applications to customers, they would realize that their solution is untolerable.

Now coming to the suggestion of Devin: Using LV 8.5.1 and toolkit 1.1.2 works for customers having office 2003 or older, but not office 2007. Do you think we could find an "open source" fix to this problem (maybe I should open a new thread?) ?

Herbert