LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

.chm help file and executable

Solved!
Go to solution

I'm using a .chm help file to provide context help for some VI's and controls in my application while running. I've put the .chm file path in the help path of the documentation dialog of the VI's and of some control typedefs along with the help tag. Everything works fine when running within Labview but when I create an executable and run it, I get inconsistent results. Some controls get access to the help file (question mark in context help window is blue) while others don't (question mark is grayed out).

 

How come the access to a .chm help file is inconsistent in the executable while it works perfectly in running mode?

 

My .chm help file is loaded in my project. I'm using Labview 2011 64 bits.

Marc Dubois
0 Kudos
Message 1 of 12
(6,079 Views)
Is it possible to post some screenshots?
-Check if it helps, generally miss this file paths. During executable and development, if you are using current vi path or app directory they are completely different.
http://digital.ni.com/public.nsf/allkb/FD7DE8BC8FFC256C862565F4006BE363
Thanks
uday
0 Kudos
Message 2 of 12
(6,037 Views)

The screen shots won't say much but here it is. Sometimes, the help file is available (left), sometimes it is not (right).

 

Context help picture.jpg

 

I think that the use of .chm help file needs to be better documented in Labview, especially when building executables. Here are some parameters that I figured out by trial and error. Some of those parameters solve some of my problems but a mysterious issue remains, possibility related to the number of control/VI's that refer to a specific help file. I have found a work around though (see last point).

 

  1. The help path in the documentation property page points to the actual help file.

  2. When creating an executable, the help file is copied from its original location to the Application path/data directory and all help file references point to the Application path/data directory instead of the actual file location.

  3. Help paths (and help tags) can be modified for VI’s through property nodes.

  4. Help paths and help tags cannot be modified for typedef controls.

  5. When a help path is set in the documentation page of a VI, the context help will point to the help file of the VI when the mouse is over a control, unless this control is a typedef.

  6. If the control is a typedef, the context help will point to the file indicated by the help path in the documentation page of the typedef. If there is nothing in the Help path, the question mark in the context help becomes gray instead of blue, even if there is a help file given in the VI documentation page.

  7. In the case of a VI template, the help path of the documentation page does not work when in an executable. The only method I found is to dynamically assign a “Application directory/data” to the help path using a property node, assuming that the help file has already been copied in the data directory for another VI or for a control (see code snippet below). This code can be used in any VI. I found it to provide more consistent results than relying on Labview to assign the correct file paths.

    Run time help path.jpg

  8. In some cases, and I haven’t been able to reproduce that problem in a new small VI, when a typedef points to the same help file than the VI in which that typedef is, the context help window will have the question mark grayed out for that typedef. As mentioned above, that problem is not consistent. I get the problem intermittently with a much bigger application. The solution I found is to make a copy of the help file and have the help path of the typedef points to the copy instead of the original. The question is: Is there a limited number of controls/VI’s that can refer to a specific help file?

 

In any case, I am interested to hear from anyone who could confirm, correct, or explain what I found out. Any other information about the use of .chm help files in executables would also be appreciated.

Marc Dubois
Message 3 of 12
(5,991 Views)

Hello,

 

I have built a VI that has a CHM file linked to itself and multiple typedefs.  I have been unable to reproduce the error you were seeing.  I would suspect that something else is going on in your large application that is preventing you from opening the file.  

 

Most of what you've said sounds true.  In number 4, I think you meant to say that these cannot be set via property node.  That is a true statement, although they can be edited if you open up the type def, and then set the property for that type def.

 

Number 3, this property can be set in either the VI properties, or via property nodes.

 

Did you have other questions that you were not able to figure out through trial and error?

 

Regards,

 

Shane C

 

 

0 Kudos
Message 4 of 12
(5,947 Views)

Hi,

 

In number 4, I meant programmatically, through property nodes or otherwise.

 

My  main question was about the reason why when I change (or just edit) the Help path of one VI or typedef in Labview edit mode for my large application, it affects the access to the same help file of the VI or other typedefs in the resulting executable. It is  either a pecularity of my specific application or some misterious limit in Labview that we won't know about. I guess I might have an answer to my question only if it is the latter case and someone at NI can respond about it.

 

Thanks for responding

 

Regards

Marc Dubois
0 Kudos
Message 5 of 12
(5,873 Views)

I have tried multiple ways to try and reproduce the grayed out behavior you are seeing, and I still can't make this happen.  If you have a VI that can replicate this behavior regularly, post it and I will test it.  This does not seem like it should be happening.

 

Regards,

 

Shane C

0 Kudos
Message 6 of 12
(5,849 Views)

It took me a while but I have been able to reproduce at least part of the problem in the attached project and its executable.

 

The original help file is "C:\Context help test\UI Help.chm". Its name has been changed (I added a "-") to see which control wrongly points to the original file or correctly to the "C:\Context help test\Untitled Project 1\My Application\data\UI Help.chm". The idea is that an executable cannot point to the original file location if it has to be transferred to another computer.

 

If you copy the "Context help test" directory in the root of your C drive, I think that you should see the problem. When running the executable, some of the controls (like the home, tabs, Record, Up buttons) will have the blue arrow in the context help window and others (like the Cancel and the Previous buttons) will have it grayed out if the dash is present in the original help file. Remove the dash and the arrow is blue for all controls.

 

It is only part of the problem I have seen with my other application but it should be related.

 

If you rebuild the executable, makes sure to rename the help file before.

 

Last minute note: If I build with LV 2011 64 bit, I get different results but the problem remains. However, if I build with LV 2011 32 bit, it seems that there is no problem.

 

Regards

Marc Dubois
0 Kudos
Message 7 of 12
(5,830 Views)

Thanks for posting your code.  I have been able to replicate the behavior your were mentioning.  Where adding the dash makes it so some Type Defs can see the file path, and some cannot.  I tried looking through your type defs and it looks like they all have the same exact settings for the filepath.  It seems odd to me that LabVIEW can see the CHM file under any of the type defs when you place a dash in front of it.  The filepath is incorrect, I am not sure why you would be able to see it CHM file.  It seems to me it ought to be all blue (without dash), or all grey (with dash).  Is that the behavior you are expecting?  BTW, the CHM file you sent is a blank file, I assumed this was on purpose, but I just wanted to check.  

 

Shane C

0 Kudos
Message 8 of 12
(5,803 Views)

Yes, the CHM file is a blank file on purpose.

 

Actually, what I figured out is that when you build an executable, the paths in the Help path documentation of VI's and typedefs are changed to application\data where the help file is copied by Labview during the build process. So, when running the executable, all VI's and typedefs should point to the file in the application\data directory, not to the original file ("C:\Context help test\UI Help.chm"). When a dash is added to the help file in the original location, the arrow should remain blue for all controls because they all should point to the "My Application\data\UI Help.chm" file. The fact that some controls point to the "\data" directory while other controls point to the original file is weird. In the case of the my big application, it seems that some controls don't point to either file because the arrow is gray not matter what (I couldn't reproduce that problem here). Furthermore, if I edit the Help path of one typedef, it might affect the help file behavior of other typedefs, even if they are not edited.

 

Notice that in the application I sent, if you drag a control that has a problem (pointing to original file) into the VI, the problem is fixed for the control but also for all other controls already in the VI that are based on the same typedef.

 

The problem can be fixed for VI's by programmatically by assigning the correct help path using property nodes but this fix cannot be used for controls.

 

I finally made it work in my application but I have to use 4 different help files (actually the same help file but with different names).

Marc Dubois
0 Kudos
Message 9 of 12
(5,792 Views)
Solution
Accepted by topic author MarcDub

I've re-built the application in LabVIEW 2013 and done some testing to see if I can re-create the problem.  I can't.  I can see the problem only in the executable you sent me.  When you build an executable, however, and want to deploy it to the target, you will want to use programatic context help paths anyway.  The method I used to accomplish this looks as follows:

 

Snippet.png

 

Create a static VI reference, and then use a relative file path to set the path to each control.  When I use this method, and then include the help files into my executable, I can programatically change the file path for the Type Defs.  This seems to be a better way of setting the type defs, in a way that the path will be relative to wherever the executable and its respective data directory are located.

 

Shane C

Message 10 of 12
(5,776 Views)