Build name conflicts (NI Report Generation Toolkit)

[Andrey_Dmitriev]

Hi, George,

Can you please explain p.6 from the document given above:

"6. In the Destination Path control, change the extension from .llb to .dll. The destination will still be an LLB but the resulting file will have the .dll extension."

Why do we need to change extension from llb to dll? It should be OK with llb as well, isn't?

Andrey.

[Hillman]

Hi All,

This post has developed significantly - and Im sorry to see the problem was not resolved. 

Point 6:

I believe the reasoning behind this is so windows only has one file to handle. So if you generates a warning it would only be listed once (reducing the number of files created)- rather than for all the contents of the LLB. LLB's and DLL's have very similar functions, but LabVIEW will still open a .DLL as a LLB. 

As the link explains, "To minimize the number of files generated, you can follow this approach to create LLBs with .dll extensions which will mask the behavior from the end user."

I hope this makes point 6 a little clearer.

Kind Regards, 

Message Edited by Hillman on 11-05-2008 09:20 AM

[Andrey_Dmitriev]

"...the problem was not resolved", because here the fundamental problem occurred with classes in application, which is not clearly resolved yet.

Well, I have read how to Including Report Generation VIs in Stand-Alone Applications, then read how to Managing the Resulting Files from a Build Containing LabVIEW Classes, and now I have prepared simple test project, which uses HTML/Word/Excel reports.

There are two build specifications in the project:

My Application (No LLBs, OK) - this produces lot of warnings, and placed lot of VIs to the subdirectories (but working properly).

My Application (with LLB, NOK) - this will create separate LLBs for each class, but Word and Excel reports failed with following error:

--- 

"Error 7 occurred at Get LV Class Default Value.vi";

Complete call chain:

Get LV Class Default Value.vi

NI_report.lvclass:New Report.vi

MAIN.vi

---

I'm missing something? 

Andrey.

[pfhenry21]

in my case, my main problem is that from the labview project I visualise in real time the directory o my project with executable and install kit dir plus others. since all the files are contained into the exe I got no warning but since I made my executable and all the VIs of the report generation are put in the support folder my project find now lot of warning since of these VIs near my executable.

I use the labview project to visualise automatically my folder of the project with resources, sources, executable and install kit.

AT least executable because it will have to be added into the install kit later, so, how can I do with that ?

[Adam_H]

Hi pfhenry21,
Even with the llb’s included in the Application you build an installer just like normal.  I tried it on my end without any problems.  The entire application will need to be included for it to work properly but as long as that  is done it will be like building any other installer.

[Andrey_Dmitriev]

Hi!

Its me again.

With installer I have the same trouble as pfhenry21.

So, if we made installer based on the build spec, then we have no problems. But in case if we need to add all binaries to the project (application, support files, etc), then we have another conflict, because SuVIs already added to the project from vi.lib, and they cannot be added again from binaries. We have such logic because our application is "PlugIns" based, and Report Gen Toolkit was used in one of then PlugIn. For deployment right now we have the following "solution": we packing all SubVIs to the self-extracting archive, then this archive deployed to the target machine with installer, then core application perform unpack of this archive (once) before plugin call, and then plugin called. Quite inconvenient way. Deployment Report Gen SubVIs in LLBs is possible solution (because LLBs can be added to the project without dependencies conflict), but this doesn't work - see two posts above. Andrey.

[Altran_Ace]

thks, I'm not the only one to get these problems linked to the report generation...

[Adam_H]

Hi All,

 I am seeing the same behavior on my end as well. Both with the example Andrey posted as well when I create my own project. I think it might be something that I am doing wrong that is not clear in the Knowledgebase. I know it’s a little inconvenient but for the moment Andrey’s solution is not a bad idea.

[Andrey_Dmitriev]

Hi, Adam,

Of course, the solution always here, and can be found for every trouble.

But especially for this "generic" problem with classes all what we needed is the possibility for storing VIs with delimeted names in the LLBs. That is all.

All classes SubVIs (as well as libraries) caused no any conflict in the memory (because they represent as "NI_HTML.lvclass:Append Control Image to Report.vi"). Why they can't be stored in the LLB (or in executable) exactly in the same way? May be in LabVIEW 9? IMHO this will solve all problems immeaditely.

Andrey.

[pfhenry21]

well, solution from Andrey is lit bit complicated and it would be very nice if NI can provide an example of how to do it...

I got already a lot of work on project and I don't think this part as to be made by whom who a big user of labview, but can be a good try from the NI Team to apologize about the bad effect of the new report generation toolkit class oriented...