Built application is trying to load class items and llb that it can't find

[herbert.niesler@emsolutio]

Hi,

  currently using LV2010, but this problem first appeared when I went from LV8.2 to LV2009 SP1.  Have never resolved it, but now am trying to.  Any thoughts would be appreciated.

  In LV8.2 it all worked fine.  I have made some changes in the newer LV versions, at this stage I am not convinced that the changes are the cause.  Some of the changes were made to allow the project to build after going to LV2009.

  The project builds ok and runs ok when I run the built application on the PC that has the development environment.  When I go to another PC with RTE installed, then the wheels come off.

  As the application loads it starts asking for all sorts of vi's from lvclass and even for an llb.  See the attachments for a couple of the messages that come up.

  I don't understand why all the stuff it is asking for is not automatically included in the project.  On top of that I have found some of the lvclass items under "dependencies".  I get the feeling I am missing something obvious here, but until somebody shows me it is not obvious!

[Justin_P]

Hi Herbert,

For your first screenshot, it looks like an issue with your Report Generation VIs.  In LabVIEW 8.6 we did a major overhaul of the Report Generation Toolkit.  The changes that we made should prevent you from needing to manually include report gen VIs to the build specification. But you may be having some other issue related to the Report Generation upgrade.

To test if I'm on the right track, could you try making a simple Report Generation VI into an executable and see if you have the same issues on the deployment machine?

[herbert.niesler@emsolutio]

Hi Justin,

   I took the "Easy Text Report.vi" and built it into a project and ran it on the target machine with out any problems.

Now that it doesn't appear to be an obvious problem, let me fill in some more detail which I think might be relevant.

The VI's causing the problem are dynamically run from a top level vi.  See attachment, that shows how I accomplish this.  I did have to change the details of how I do this between LV8.2 and 2010.  In LV8.2 I had forced the subvi's to load by putting them in a case statement that was never executed.  In going to 2010, this did not work (wouldn't build) so I had to change the approach and followed a suggestion I got on this forum.  The suggestion allowed me to build but then when I ran it I came upon the current problem.

The attached file also shows some details of how I have my project organised.

[Justin_P]

Have you been able to successfully call the "Easy Text Report.vi" dynamically in an executable? 

[herbert.niesler@emsolutio]

  Hi Justin,

                Thanks for the ideas.  Have modified the project and it works on the target computer.  See attachment for details of how I have implemented it.  Not sure what the problem is in my main application, if this one works.  Certainly the report VI's are a few more layers down the VI chain in the main application.

  Will continue to think on this and experiment if I have any further ideas.  Also any further thoughts from you would be appreciated.

   Thanks

            Herbert

[herbert.niesler@emsolutio]

 Hi Justin,

            I have figured it out and its a stupid mistake.  In going away from LV8.2, I didn't realise that all those extra folders in the build destination directory were important!  I have re-built a number of other applications in LV2010 and there was no discernable difference in the build destination directory over LV8.2.

  Turns out it is not the case with applications that use the report vi's, the report related vi's go into various folders associated with the project.  So when I copied the build to the target machine I didn't copy the additional folders that were generated during the build.

  Copying the whole build directory to the target machine results in the application working.  What can I say!  Don't do that again!  Yeah but there will always be other possibilities to get it wrong in the future.  All the same, thanks for the suggestions Justin.

       Cheers

                   Herbert

[Justin_P]

Herbert,

I'm happy to hear that you were able to get everything up and running.  And thanks for posting your findings.  Hopefully this will help someone in the future.

Have a great weekend,