Showing results for 
Search instead for 
Did you mean: 

parse export strings



LabVIEW has a feature to export strings from the front panel to file.

You go to Tools->Advanced->Export Strings...

Is there any library out there that parses the output of that file?


It's not XML so XML parsers refuse to do it. I was wondering if anyone is aware of a library availible in LabVIEW to parse this file?

0 Kudos
Message 1 of 11

This should be what you are looking for:








0 Kudos
Message 2 of 11



Thank you for your post.But this doesn't adress my problem.

There are two functionls export and import.


I need something that parses the file.


I want to do the following:

1) Export the file fromt he VI

2) Parse it externally and replace one language strings with another set of strings.

3) Use the Import you've hightlighted to import back.


I was asking if there is some API I could use to do the steps from point 2.



0 Kudos
Message 3 of 11

@Mac671 wrote:


2) Parse it externally and replace one language strings with another set of strings.


Just a couple of ideas:


a) you could change the strings internally in Labview, even programmaticaly, and than save the different copies of the files


b) You could use place-holder strings and search and replace for them in your external parser





Message 4 of 11

Hi Maciej,


As you say, the resulting file from the export strings is not quite in correct xml format. This is something which is being addressed in R&D, with the intention of producing a well formatted xml file, but is not implemented as yet.


I have found some 3rd party VIs which are used for translation, you can use the functions to parse the file, then edit the allowed information and put it back into a file which can be used for importing. There is a readme which explains the use of the top level VIs in the library, so I won't explain it here, but leave you to explore for yourself.


Hope this goes some way towards helping you fulfil your requirements.



Ian S
Applications Engineer CLA
National Instruments UK&Ireland
Message 5 of 11



I have also found an example of a translator here which parses to an array of data and allows you to translate each element. It may be easier to use.

Ian S
Applications Engineer CLA
National Instruments UK&Ireland
Message 6 of 11

Marko and Ian,


Thank you both very much for your suggestions.


@Ian I'll have to spend some time to look though the examples you've sent me and I think this might work for me.


UniCode character sets I'm a bit worried when coding in LV, that is why I ideally would prefer to parse the file externally to labview ( i.e. using a Xerces parser ).

And this work will be for Multi-Language translation purposes so I'll have to deal with many unicode tables.


The other idea I was given by a collegue was:

1) Write a small program that would "fix" the export file and make it a proper XML file.

2) Use an external XML parser ( like Xerces ) to do my find and replace stuff.

3) Reverse the procedure done in point one and make so that LabVIEW can read it back again.


I will analise the options you've sent and I appreciate your reply and help.

I'll post again once I've had some time to play arround with the examples.

0 Kudos
Message 7 of 11

Hi Maciej,


I also thought of finding some way to 'fix' the XML, as you say it would be useful to use an external XML parser, but I couldn't find any existing tools. To make a general one will take some effort! Below is a list of some known issues with the current format compared to XML, it may help you in case you want to make such a tool.


  • Missing root element
    XML dictates exactly one root element per XML file. However during our VI strings export, we create multiple root elements per file. Solutions:
    1. Wrap the individual VI entries into an additional root element
    2. Use one individual XML file per exported VI 
  • Missing quotes around attribute values
    Our VI string export violates the rule that attribute values must be quoted e.g. 
    <CONTROL ID=85 type="VI Refnum" name="StationVIPrototype"> correct would be: 
    <CONTROL ID="85" type="VI Refnum" name="StationVIPrototype">
  • Elements that are not properly closed
    Some of our elements such as <NO_TITLE><CRLF><LF>, etc. are not closed, violating the requirement that all tags must be properly closed. This could easily be fixed by adding the missing forward slash at the end of the tag: <NO_TITLE/>
  • Special case: FONT elements
    FONT elements are used as switches to toggle font properties. E.g. to turn a substring of a text bold, LabVIEW uses two tags, one to switch the bold property on and another one to revert the change. Example: This text is normal, <FONT style='B'>this text is bold<FONT predef=APPFONT> and this text is normal again.
    We can fix this by emitting the proper closing tag where the reverting extra tag used to be:
    This text is normal, <FONT style='B'>this text is bold</FONT> and this text is normal again.
  • Elements with double angle brackets
    Single angle brackets are "escaped" to double angle brackets. E.g. if a VI description text reads x < y it will be converted to x << y. Similarly, our export creates double angle brackets when it encounters <B> or <I> elements.
  • Unescaped entities cause XML parsers to fail, e.g. when it reads X & Y rather than X &amp; Y  -- other examples: less than, greater than, quotes (single, double)

All the best,

Ian S
Applications Engineer CLA
National Instruments UK&Ireland
Message 8 of 11

Hi Ian thanks a lot for that!!! Kudos!

I'm stretched real thin this week and this information really helps me out! 



0 Kudos
Message 9 of 11



I've been working on an app to:

1) Export all string files for a target vis heirarchy

2) Read the files and extract all strings. My rule has been that anything outside a tag, i.e., between ">" and "<" could be a string (also rejecting empty or whitespace characters), Is this assumption valid or is there a better way? 

3) The problem I've run across is a Multicolum List box which contains  "<CELL_FONTS>[-2 -2]<FONT..." so the [-2 -2] is outside the tag and gets translated. 


I'm open to other translation ideas but I have looked at the third party ones (LTK and S.E.A, I think) and the cost doesn't justify the time saving for me.




0 Kudos
Message 10 of 11