report toolkit: development vs. application

[gnunesjr]

I'm having a problem with the report toolkit when I compile my application.  Everything works fine in the development application.  When I compile my application, however, none of the Report Generation Toolkit VIs can be found.

The problem seems to be this bit of code (Word Find Application Directory.vi called from New Report.vi):

It claims that it will solve the problem, but it appears not.  This generates a reference to the location of my compiled application!  Not to the location of the toolkit VIs.  

Am I doing something wrong???

Thanks,

-GN

[MikeS81]

Hi gnunesjr,

which version of LabVIEW do you use.

Maybe this helps:

http://digital.ni.com/public.nsf/allkb/2AE85CF95217E60786257540000D818C

Mike

[BCho]

Hey gnunesjr,

You had mentioned that your reference to your code works in the development environment but not the .exe environment. What happens in the .exe environment if you use the strip path twice? This should give you the same reference then as you have in the developments environment. However, in doing this, you will want to put a little more logic in your code to check to see whether or not your are in an .exe or development mode. Then either use the strip path twice or once accordingly.

[Broken_Arrow]

Include the Word and Excel support VI's in the build specification under support files.

The "Current VI's Path" constant can cause problems with the EXE, especially as you transport the program from one computer to another. Change the Current VI's Path constant to an explicit path and see if that fixes it.

Message Edited by Broken Arrow on 07-09-2009 02:58 PM

[Jörn]

Are you putting the subVIs in a library when you build the app? Then you might not access the path for writing stuff. Changing the propertiers for building the application might help.

[gnunesjr]

Broken Arrow:  Yes, installing an explicit path constant works, but it is neither elegant or portable.  I was sort of hoping the Toolkit (which I paid extra for, let us all note) would just work.  I have to say that NI has given themselves a black eye here for no reason.  In general LabVIEW works extremely well.  If you have a quality product like that, why would you sully your reputation and needlessly anger your client base by selling something that is such a piece of...well, this is a family-friendly forum, so I'll let your imagination fill in the rest! 

The knowledge base articles linked by Mike look like they could provide a better solution, provided all the other ugly stuff that surfaced can be fixed.

I'll post when (if!!!) I can get it all sorted out.

Thanks all for your thoughts,

-GN

[Broken_Arrow]

---

gnunesjr wrote:

Broken Arrow:  Yes, installing an explicit path constant works, but it is neither elegant or portable.  

---

Correct. I went through the same things and feel the same way*. I just thought that, once knowing that (and it looks like you already knew it) you could have the user do a one-time setup, linking the path to where it needs to go, then storing that.

*I have gone well out of my way interfacing to Excel with property nodes to avoid using the Toolkit. The other problem I have with the toolkits in general is, if you are sharing code responsibilities, and someone doesn't have the toolkit, it's BrokenArrow.