Dynamically loading help file from standalone application

[Hannamon]

Hello All;

I have written into my VI an option to load a help file (.chm) from my main application using the 'Open URL in Default Browser.VI'.  When I am in Development Mode, this works perfectly.  However, after I have compiled my VIs into an executable, this no longer works (i.e. nothing loads).  I am wondering if since the CHM file is not a default LabVIEW VI/LLB if this is where my problem is?  I have attached a BMP which shouls what I am doing.

I did manage to get the CHM file to install with my application, but as mentioned, it will not load.  I have also attached a bitmap showing my build properties for this.

Any assistance would be greatly appreciated.  Thanks.

DJH

[GuenterMueller]

Hello DJH,

the solution to your problem might be adding a "Strip Path", as discussed in
application - current vi path different - config file - LabVIEW - NI Discussion Forums

BR, Guenter

[Hannamon]

I do not believe it is...

The first response in that thread suggests that in the runtime version, to add a second strip path, since apparantly the application.exe somehow registers as one level in the path.  When I run the installer, all my development subdirectories are no longer in the final installed directory, so the way I understand it, this will not work properly (didn't work for me anyway).  Besides, when the Project Builder actually builds the .exe, should it not reference every relative path in the source code and build that in to the executable?  For example, the Builder places all my DLLs in a /data/ directory.  If I select the DIAAS Help.CHM file as a support VI, it is also installed inthe \data\ directory, but of course there is no link to it after the .EXE is built.

The second response refers to an OpenGL library, which I also could not get working properly.  Also, my company has poloicies concerning the use of third-party source code that I believe precludes me from using the OpenGL VI in this case.

Is there not a simple way of doing this?  Or is it really as complex as the threads I have read seem to indicate?

[GuenterMueller]

Sorry, the additional "Strip Path" in the application will only work if your .CHM keeps it's position when you run the application. If you install the .CHM to a different directory things might get more complicated.  But as you specify the LabVIEW project settings you surely know the file locations after the installer has run. Consider this and your application should run.

BTW, OpenG is Open Source. Hopefully your company allows you to benefit from this great collection of VIs.

If this does not help, would you please provide a screenshot of where your files are located when running with LabVIEW / your application?

Best regards, Guenter

[Dennis_Knutson]

The change required for path information is really not all that hard to understand. If you use something like Current VI's Path, it will return c:\folder\example.vi. When an exe is created, each VI is put into the exe which is really a type of llb file. To prove this, just change the extension to llb and you can view the contents just like like any other llb file. Then the Current VI's Path will return c:\folder\application.exe\example.vi. So, the extra strip path is required to get the folder name. Using the application property App.Kind in your program allows the same program to work in the development mode ans as an exe. It would be difficult for the app builder to automatically add a strip path because it be next to impossible to know what the purpose of the Current VI's Path function is intended by the programmer. You can also simulate the behavior of the app builder by creating an llb and testing all of your path's there before doing the build. Also, by default, the app builder does create a \Data folder but when you do the build, you can change where certain files get installed to.

Message Edited by Dennis Knutson on 05-22-2006 08:44 AM

[Hannamon]

You're right, in the end it really wasn't that difficult to get working... there were just a few things I needed to know:

(1) I needed to use the application property App.Kind to specify development or runtime version, since the number of strip paths used differed between the two.  For example, if the VI was a top-level VI, I typically needed one additional strip path for the runtime version.  If the VI was buried somewhere (i.e. a remote sub-VI), then I might need an extra strip path for the development version.  A bit of trial and error using breakpoints and probes, but no so difficult.

(2) For the runtime version, when using the application builder, it is possible to specify a different directory for each VI (if you wanted).  In doing so, it is possible to customise the final installed look of the executable.  So, it is therefore possible to reconstruct the same directory structure for the runtime version as it is for the development version (if desired) in order to keep the differences in path structure from the development to the runtime versions as minimal as possible.

Thanks again!

DJH