LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

parse export strings

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?


0 Kudos
Message 1 of 11
(4,115 Views)

This should be what you are looking for:

 

 

import.png

 

 

Regards,

Marco

0 Kudos
Message 2 of 11
(4,073 Views)

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


0 Kudos
Message 3 of 11
(4,070 Views)

@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

Message 4 of 11
(4,049 Views)

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
(4,032 Views)

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.

Ian S
Applications Engineer CLA
National Instruments UK&Ireland
Message 6 of 11
(4,025 Views)

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
(4,014 Views)

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
(3,993 Views)

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
(3,990 Views)

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

0 Kudos
Message 10 of 11
(3,660 Views)