parse export strings

[Mac671]

Hi,

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?

[MarcoMauri]

This should be what you are looking for:

Regards,

Marco

[Mac671]

Hi,

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.

Regards,

Maciej

[MarcoMauri]

---

@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

Regards,

Marco

[IanS]

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.

[IanS]

Hi,

I have also found an example of a translator here http://zone.ni.com/devzone/cda/epd/p/id/2906 which parses to an array of data and allows you to translate each element. It may be easier to use.

[Mac671]

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.

[IanS]

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 & Y  -- other examples: less than, greater than, quotes (single, double)

All the best,

[Mac671]

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

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

[MichaelWestwood]

Hi,

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.

Thanks,

Mike