Wednesday, January 28, 2009


Last week I was fixing a problem with a VI where the wrong text was shown in the Context Help window for some of the controls. Perhaps it's a VI you recognize...

Yes, embarrassingly enough, it was a bug with my Getting Started window. The small images to the left of some of the links are picture rings. They were showing their decidedly unhelpful labels in the help window:
After deciding that the picture rings should simply have the same names and descriptions as the items to their right, I added a property node to set the caption text and description.

Then I ran the VI. It didn't work. In fact, it fixed the context help for some, but not all, of the picture rings.

You might already be able to spot what I did wrong. If not, maybe you'll be able to guess after I explain more about captions.

What Are Captions?

When you place a control on a VI's front panel, it has a label where you give it a name. This name is shown in the context help window. It also provides the identifier for programmatic interfaces such as Set Control Value.

When the LabVIEW team added features to support localization of VIs, we needed to be able to change the name of a control. But if we changed the label, calls to interfaces like Set Control Value would break. So we introduced another kind of label, called a caption.

We also didn't want to make VIs bigger (in memory and on disk) by adding a part to every control and indicator that most wouldn't use, so captions are "lazily created." When you right-click on a control and select Visible Items>Caption, LabVIEW creates a caption for the control. It also hides the label (since you usually use a caption instead of a label, not in addition to it) which leads to the confusing situation where the menu option appears to have no effect (because the caption initially looks exactly like the label and is in the same location).

You can tell that a control has a caption by looking at the context help window. When the VI is in edit mode, the context help displays the caption and the label, with the label in square brackets. (Note that when the VI is running, the context help displays the caption but not the label).

Fixing the Bug

Coming back to my original story, when I checked the error out of the property node that was setting the ring caption, I found it was generating error 1320: "In run mode, LabVIEW cannot get or set a property for a control part that has not been created."

The problem was that some, but not all, of the rings had caption parts. As I mentioned earlier, captions are lazily created - you can't set the text on them if they don't exist, and LabVIEW can't create them on running VIs. The solution was to show (and thus create) the captions for all the rings. Luckily, I was using LabVIEW 8.6 and could use the new multi-select feature. I selected all the rings, right-clicked to show the Properties dialog and showed all their captions in one step. Problem solved.


Blogger Jonas said...

For older LabVIEW versions use tools\advanced\export strings.
When asked to export captions for controls without captions select yes and all the controls have capations.


2:26 AM, January 29, 2009  
Blogger Phil said...

What would be really nice is API access to the Context Help window.

I've created a tool for our developers to help upgrade VIs and LLBs from 7.0 to 8.6. It consists of an XControl that uses a tree control and context menus to programmatically run VI Analyzer, perform mass compiles and update the VI Description (we use this to record VI history).

I wanted to set the context help window to display a VI the way that the Project Explorer does, but there is seems to be no way to do this with the current version of LabVIEW.

See this LAVA posting:

8:25 AM, January 29, 2009  
Blogger Yair said...

Actually, in LabVIEW 7.0, you didn't have to explicitly create the caption in order to work on it. This is a change which was made in 7.1 and broke existing code.

Incidentally, it's not entirely clear from your description, but I think this also shows the value of automatic error handling. If you had it on, and assuming you didn't actually wire the error out initially, you would have seen the problem immediately.

11:43 AM, January 29, 2009  
Blogger Christina said...

Jonas - good tip! AFAIK that still works in the current version as well. Thanks!

Phil - Good suggestion. I see in the LAVA posts that you've also submitted it to NI. Thanks!

Yair - The 7.0-to-7.1 change of behavior was a necessary bug fix. We hate breaking existing apps and are working hard to improve in that area. You're absolutely right about automatic error handling and its value. I usually have it on when I'm developing new VIs but in this case I was modifying an existing VI where it was turned off. Thanks!

9:43 PM, February 01, 2009  
Blogger Yair said...

Interestingly, your case is actually an example of why using auto error handling is problematic.

Someone asked me once to find the problem in some code which opened a reference (I think it was a VI reference) and then did something on it, which was failing. The natural debugging move was to check the reference, but the reference was generated and the open function was not returning an error. Or so I thought. The VI actually had AEH disabled and the open function WAS throwing an error at the same time it was returning a valid reference. Had I not been used to AEH, I would probably have wired the error out terminal and found that out earlier.

I don't remember the details of why both an error and a reference were generated, but I seem to remember that it was reasonable behavior.

So, I still think that using AEH is correct for catching places you missed handling errors (or you can use the VI analyzer), but there are cases where using it is problematic.

1:35 PM, February 02, 2009  
Blogger Christina said...

Hi Yair,

I wish you could remember the details, because that sounds like a very odd situation that I'd like to learn more about. If the reference was valid, I would expect the subsequent operation to provide the error information, not the Open Ref.

I'm not sure this is really a problem with AEH as much as a valid warning about how one should use it. I think it's perfectly fine (and in cases advisable) to disable AEH once you've written all your error handling.

5:25 PM, February 04, 2009  
Blogger Yair said...

One thing I can say is that it was probably an open app ref, based on a post I made at the time, but when I searched through the code where I thought it might have been, I couldn't find one, so I can't give any more details. It's quite possible it wasn't in that code.

Since I didn't complain at the time, I guess I thought it was reasonable behavior.

2:05 PM, February 09, 2009  

Post a Comment

<< Home