How to toogle between languages for all text elements on a panel?

[stoeckel]

Hi folks!

On the panel of my program, there are about 30 or 40 text elements, e. g. labels of controls, indicators, string indicators themselves
and so forth. I need to implement a switch which allows the user to toggle between languages, let's say between English and German, for these text elements.

I wonder how one can program this feature in a most elegant way. I may, of course, put all 30 or 40 property nodes into my main diagram and feed them with the appropriate strings which may be stored in a case structure within a subvi. However, this would yield a rather crowded and complexly looking diagram. This diagram would need an unreasonably large area on the screen and would make the maintenance of the code unnecessarily uncomfortable.

Can anybody give a hint how to accomplish the feature in a more elegant way? What is the best programming style for this task? The best would probably be if I could put the property nodes into a subvi and write there into them. Unfortunately, this is apparently not possible.

Thankful for any advice,
Peter

[falkpl]

You can access labels/captions for all controls from a vi in a sub vi easily. Pass a reference to the top level vi to your sub-vi using a reference control in the sub vi. Then wire this reference to openVI reference, then wire this to reference to a "panel" property node and wire that to an "object[]" property node. You now have a reference to each control on your top level panel. This is very nice because you call access all objects even ones which have not been added yet. This vi can take an array of control references and update the captions (I would display caption and change this while keeping the label constant) using a prop. node to the currently selected language inside of the for loop. This update can be a done with nested case structures: outside case = label inside case = language. An even nicer method is to "hide" the multilingual text on separate lines of the descriptors. I have attached a simple version (one vi only but can make this a subvi easily). I think this is a fairly elegant solution. I dont know if there is a method to store/link multiple text strings to a single caption.

Paul

[alipio]

Hello

If I undestood your question, this NI example (language.zip) can lead you to an elegant solution.
http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=B45EACE3F0FB56A4E034080020E74861&p_node=DZ52039&p_source=external

Hope it helps you
Cheers
Alipio

[Johnner]

The only problem with the example Alipio mentions is that it uses a method (Import VI Strings) that cannot be called a run-time, so it's not appropriate for a situation where someone wants to have the user toggle between languages without closing the VI. Of course, if Peter is comfortable with having the application close and then reopen, then that is probably the way to go.

Paul's idea was a really interesting one--using the Description area programmatically for meta-data about the panel object. Of course, it's problematic if you want to use Description for its intended purpose of documentation and help, so I probably wouldn't go that way. It might be nice if LabVIEW formally provided a meta-data property for all panel objects that could be used for arbitrary purposes. Such a feature might be a good extension to the existing VI data memory space, and I think I'll suggest it as a product feature request.

--John

[stoeckel]

Hi folks,

thanks a lot for your hints. I need a solution which will work while the vi is running. The suggestion of Paul looks

very elegant. However, I not only need to change the language of captions but also of all other text elements on the

panel, like texts in Bool buttons, string indicators and so on. Therefore I must access various kinds of property

nodes. This doesn't seem to be possible with the solution of Paul since it only works with description texts and

with particular elements like controls which have a caption.

Does anyone have an idea how to approach the problem in a more general way?

Regards,
Peter

[falkpl]

Yes its too bad there is no metadata section. I was hoping that you did not need to use the description section which I have stolen to use for such metadata in the past. Filtering the right click events on a button makes the description section virtually invisible to the user at runtime. You can also use a text file to store all your language strings. Key the file just like an init file, with the first key being the control name, then the subkeys as the language with the value for the key saving the language specific string. Using an ASCII text file allows you to easily edit the strings. This also works but you will have an additional support file. Inside of the language change event you will handle it by the following pseudocode:
if(open_language_support_file(file)){ //handles errors with file open
{for(i=0;i object.caption = lookup_string(file, object[i].label, language);
}
}else{error in file}

So in conculsion a metedata section associated with each control where strings, references or other such data a programmer would need could be extremly helpful. You can implement one using a cluster but this would be inconventint to do for every control (cluster a control with a string "metedata" section) unfortunatly this would overcomplicate the programming for us since we would have to bundle and unbundle all controls each time we needed them. The addition of a simple string "metedata" properity to the object class for the programmer to use at will (ie read write) solves this. It also would allow pointers to controls since one can write a reference to other objects at runtime to this section to be used later in the program. Just some thoughts on the subject, sorry for being longwinded and leaving on a tangent.

Paul

[Johnner]

Peter,

So, you definitely can't tolerate starting and stopping your application when switching languages, even if it's more or less transparent to the end-user? That is, are you doing time-sensitive I/O or some other non-interruptible activity?

If you could tolerate a stop-restart when switching languages, then you could put your main VI in a subpanel and modify the example mentioned above so that the user's primary interface stays open while the language is changing, providing a better sense of continuity. Otherwise, I think your observations about the additional string information beyond just the captions are on the money, and you face a non-elegant resolution that involves code that could be time-consuming for you to manage as the VI changes.

I wonder what part of Import Strings is the run-time sensitive part? Maybe there's hope for the method to be extended to run-time in a future version of LabVIEW. Probably worth a product feedback suggestion.

--John

[stoeckel]

John, Paul,

thanks for your comments. My program must run with no stop 24 h all day. It's a program for visual
inspection on a capsule filling machine. Since this software will be used both in Germany and the US, I am wondering
how I could implement a button which just allows to toggle all text elements between the two languages.
Unfortunately, it seems that there isn't any smart way to accomplish such a feature. I am afraid I have to walk the
"pedestrian way" and program everything step by step with property nodes. This will make the vi difficult to maintain, of course. When it comes to simple text on the panel, this text doesn't even have property nodes. Here's really something which can still be improved in LabVIEW. Your idea, Paul, with the init-file doesn't really help me. I will have to feed the individual strings to individual property nodes, anyway. In this case, I can also put the strings as string constants directly into the diagram of the vi.

Peter